roadmap on enhanced civil-military cns interoperability and technology ... · roadmap on enhanced...

Edition 2.0Reference: EUROCONTROL 13/10/17-07

Roadmap on Enhanced Civil-Military CNSInteroperability and Technology Convergence

EUROCONTROL

Roadmap on Enhanced Civil-Military CNS Interoperability and Technology Convergence Edition 2.0 3

ABSTRACT

The present document updates the EUROCONTROL Civil-Military CNS/ATM Interoperability Roadmap (Edition 1.0 dated 3 January 2006). It complements other EUROCONTROL CNS infrastructure roadmaps and guidance documents in line with the latest versions of ICAO technology roadmaps, European ATM Master Plan and the Network Strategic Plan.

The main objective of this Roadmap is to provide technical information to military authorities and ATM planners to determine the most cost-effective and mission efficient technical and system options to be considered during ATM/CNS research, industrialization, planning, procurement and implementation activities as required to enhance civil-military CNS interoperability and technology convergence. It proposes interoperability recommendations, preferably based on perfor-mance targets and on re-utilisation of existing military capabilities to reduce implementation costs.

It does not create or propose new or additional requirements. On the contrary, it revisits existing ATM/CNS plans and trends, indicating performance-based options, interfacing solutions and technical alternatives for compliance that mini-mise the institutional, economic, technical and procurement impacts of ATM improvements. The implementation decisions are to be taken by the States and depend on subsequent cost/benefit analysis and performance evaluations.

This Roadmap is purely of a technical nature and is not suited to supporting strategic discussions. Its contents are there-fore non-binding.

The present document was endorsed at the 13th meetingof the Military ATM Board on 17 October 2013.

4

DOCUMENT CONTROL

© 2014 European Organisation for the Safety of Air Navigation (EUROCONTROL). All rights reserved.This document is published by EUROCONTROL for information purposes. It may be copied in whole or in part, by the Member States of the Organisation, provided that EUROCONTROL is mentioned as the source and it is not used for commercial purposes (i.e. for financial gain). The information in this document may not be modified without prior written permission from EUROCONTROL.

DoCuMENT APPRoVAL

PoSITIoN/Job TITLE NAME SIGNATuRE

Head of DSS/CM/CNS Unit Jorge PEREIRA

Head of DSS/CM Division Michael STEINFURTH

Director Single Sky Luc TYTGAT

Director General Frank BRENNER

EDITIoN HISToRY

EDITIoN EFFECTIVE DATE EDIToR REASoN(S) FoR MoDIFICATIoN

1.01 01/02/2012 J. PEREIRA Document creation

1.02 15/04/2012 J. PEREIRAD. COLIN Initial draft (partial)

1.1 11/05/2012 J. PEREIRA Initial draft

1.2 27/08/2012 J. PEREIRA

M. DE CAT

T. OSTER

D. COLIN

P. BARRET

T. BLUNCK

DSS/CM/CNS Internal review and additional contents

1.3 31/10/2012 Inputs 2nd Military CNS Information Days

1.4 15/01/2013 DSS, DNM, DSR Review

1.5 08/05/2013 Civil-Military CNS Focus Group

1.6 30/08/2013 Internal Review

1.7 02/10/2013 J. PEREIRA MILHAG

STATuS, AuDIENCE AND ACCESSIbILITY

STATuS INTENDED FoR ACCESSIbLE VIA

Working Draft n Restricted n Intranet n

Proposed Issue n Classified n Extranet n

Issued n Public n Project Server n

CoNTACT PoINT

CoNTACT PERSoN TELEPHoNE uNIT

Jorge PEREIRA ++ 32 2 729 5036 DSS/CM/CNS


EXECUTIVE SUMMARY 7

1. INTRODUCTION 101.1 Background 10

1.2 Document Structure 11

1.3 Objective 12

1.4 Intended readership 12

1.5 Scope 12

1.6 Baseline information and assumptions 12

2. ICAO GLOBAL INTEROPERABILITY CONSIDERATIONS 132.1 Chicago Convention 13

2.2 ICAO Aviation System Block Upgrades (ASBU) Initiative 13

3. SINGLE EUROPEAN SKY LEGISLATIVE AND REGULATORY FRAMEWORK 153.1 SES Framework 15

3.2 SES Interoperability 15

3.3 Applicability of EASA Regulations and Specifications 16

3.4 Network Manager 16

4. SINGLE EUROPEAN SKY ATM RESEARCH (SESAR) 174.1 SESAR Target Concept 17

4.2 The European ATM Master Plan 17

5. INFORMATION EXCHANGE REQUIREMENTS (IER) 205.1 The Need for Information Exchange and Common Models 21

6. COMMUNICATIONS INTEROPERABILITY 226.1 Communications Evolutionary Trends 22

6.2 Ground-Ground Communications 22

6.3 Civil-Military Ground-Ground Communications Interoperability 27

6.4 Recommendations 29

6.5 Air-Ground Voice Communications 31

6.6 Air-Ground Data Communications 33

6.7 Other Air-Ground Communications Infrastructure Considerations 37

6.8 Civil Military Air-Ground Data Link Communications Interoperability 39


7. NAVIGATION INTEROPERABILITY 457.1 Navigation Evolutionary Trends 45

7.2 ICAO Performance Based Navigation (PBN) 45

7.3 EUROCONTROL Navigation Roadmap 48

7.4 EUROCONTROL Global Navigation Satellite Service (GNSS) Policy 49

7.5 Navigation Infrastructure Rationalisation 50

7.6 Civil-Military Navigation Interoperability 51


TABLE OF CONTENTS

6

8. SURVEILLANCE INTEROPERABILITY 598.1 Surveillance Evolutionary Trends 59

8.2 Independent / Non-Cooperative Surveillance (Primary Radar) 60

8.3 Independent/Cooperative Surveillance (SSR, Mode S and WAM) 60

8.4 Dependent/Cooperative Surveillance (ADS-B) 61

8.5 Surveillance Data Processing and Sharing 62

8.6 Regulatory Aspects of Performance and Interoperability of Surveillance 63

8.7 Civil-Military Surveillance Interoperability 64

8.8 Other Surveillance Requirements 67


9. STANDARDISATION AND CERTIFICATION 729.1 Background 72

9.2 Scope of Standardisation Activities (in the context of SESAR) 73

9.3 Civil-Military Standardisation 73

9.4 Certification Considerations 74

10. SPECTRUM 7610.1 Background 76

10.2 Principles in Spectrum Activities 76

10.3 Consultation Mechanisms 76

10.4 Spectrum Challenges with Military Impact 77

10.5 Spectrum Bands With Civil-Military Coordination Needs 78

11. PLANNING AND PROCUREMENT 8011.1 Background 80

11.2 Military Planning and Procurement Methodologies 80

11.3 Obsolescence Management 82

12. SECURITY 8312.1 Context 83

12.2 Technical Security Outline 83

Annex A System Wide Information Management (SWIM) 85

Annex B Military Aircraft Fleet and CNS Equipage Considerations 90

Annex C Aircraft System Integration Considerations 91

Annex D Standardisation Organisations and Materials 98

REFERENCES 99

GLOSSARY 101Abbreviations 101

Definitions 106

Caution: While the editors have taken every precaution to avoid any errors or omissions in this document, EUROCONTROL does not accept any liability for the accuracy of the information contained herein. Please refer to

relevant official publications (e.g. national AIPs).


Military aviation activities supporting legitimate national defence and security missions need to take place in a mixed mode environment, an objective which entails the need to enhance the exchange of Air Traffic Management (ATM) information between civil and military parties. Such information exchange requirements will increase as new ATM concepts are introduced, justifying the need for higher levels of interoperability between military systems and the underlying European ATM Network (EATMN).

De-fragmentation, harmonisation and rationalisation of civil and military Communications, Navigation and Surveillance (CNS) infrastructures are crucial to avoid duplication of resources and to reach efficiency and performance targets responding to higher system automation.

Consequently, stable guidance and recommendations on civil-military CNS interoperability are fundamental for military authorities to be able to cope with EATMN infrastructure developments. Military planners should keep sight of emerging concepts, regulatory developments, research and development (R&D) results and ATM deployment plans. Civil stakeholders must take account of specific military requirements.

The present Roadmap proposes technical options to reach the desired minimum levels of civil-military CNS interoperability as dictated by known military requirements and ATM concepts, regulations and infrastructure modernisation trends.

The proposed recommendations promote principles like performance-based compliance (as opposed to equipage-driven recognition), maximum re-utilisation of available capabilities, civil-military standardisation and innovative low-cost technical interfacing solutions that pave the way for rationalisation and cost savings.

The essential CNS interoperability elements covered in this document support or contribute to the key features of ATM in the future, including moving from airspace to trajectory management, traffic synchronisation, network

collaborative management & demand and capacity balancing, System Wide Information Management (SWIM), airport Integration and throughput, conflict management and automation.

Interoperability recommendations focus on the interconnection between unclassified military systems and the ATM network-centric environment; the introduction of modernised ATC systems; advanced 4D trajectory management capabilities for military aircraft; new separation modes; advanced satellite based navigation and air-ground data link. This Roadmap proposes optimisation and rationalised options at lower cost in respect of the following:

n Communications - unclassified military systems interfacing with secure IP ground communications, consideration of new aeronautical message handling systems (AMHS), use of VoIP for ground voice exchanges and, for the air-ground segment, VHF 8.33 kHz expansion (UHF retained), data link deployment, longer-term advent of air-ground digital voice, satellite communications and software defined radios.

n Navigation - migration to satellite-based GNSS with recognition of military precise signals, GNSS augmentations (e.g. SBAS, GBAS), RNAV/RNP environment with the introduction of performance-based navigation (PBN) accommodating lower-capability aircraft, 4D trajectory-based operations and rationalisation of navigation infrastructure with TACAN considered for terrestrial backup.

n Surveillance - retention of primary surveillance radar (PSR) (potential future replacement by multistatic PSR in the long term), equipage with Mode S and ADS-B capabilities, consideration of wide area multilateration (WAM), safety and weather systems and improved surveillance data-sharing.

This document covers additional domains like avionics, standardisation, certification, spectrum, planning/procurement and security.

EXECUTIVE SUMMARY

PART I

INTRODUCTION AND CONTEXT

10

1. INTRODUCTION

1.1 background

1.1.1 The EUROCONTROL Civil-Military CNS/ATM Interoperability Roadmap, Edition 1.0 dated 3 January 2006 [Ref 1], delineated several inte-roperability proposals which were endorsed in due time by the EUROCONTROL Civil-Military Interface Standing Committee (CMIC).

1.1.2 Since its publication, that document has been widely used as a source of civil-military CNS1 technical requirements, including those covered in Single European Sky (SES) interoperability regulations as well as in the European ATM Master Plan. Subsequent ATM developments (ICAO, SES, SESAR R&D and Network Manager) confirmed the need to update the Roadmap, as repeatedly requested by its users.

1.1.3 Civil-military CNS interoperability impacts a wide variety of military systems but primarily applies to military aircraft operating GAT/IFR with aim to objectives like the increase of capacity in congested airspace. From the military perspec-tive, CNS requirements for ATM are always likely to be a subset of the military capability pursuing a number of important objectives:

n Increase information exchange and sharing on the basis of a more cooperative ATM

n Contribute to the de-fragmentation of ATM/CNS infrastructure and introduce economies of scale

n Minimise the use of aircraft equipage exemp-tions and derogations for State aircraft reducing ATC workload and increasing safety levels2

n Enable mixed mode operations in an highly automated environment

n Create the basis for civil and military stan-dardisation and equivalent verification of compliance

n Identify synergies that lead to cost reduction when military capabilities are re-utilised.

1.1.4 Global interoperability is a key driver that requires looking closely at ICAO’s Aviation System Block Upgrade (ASBU) concept. ASBU blocks link also with NEXTGEN, the US ATM modernisation program. Civil-military coordi-nation has received the attention it deserves at the level of ICAO, with the publication of ICAO circular 330 AN/189 on the basis of a heavy European input. Consideration is also given to the European SES initiative, including its techno-logy modernisation component (SESAR).

1.1.5 Important references with an impact on civil-military CNS interoperability include the deployment synchronisation and coordination aspects that derive from the European ATM Master Plan and the Network Strategic Plan (NSP) for the Network Manager as well as plans for the implementation of Functional Airspace blocks (FABs).

1.1.6 European Aviation Safety Agency (EASA) rule-making iIf an increase in GDP produces a smaller increase in demand for air transport than it used to, then the market is becoming mature. There is certainly evidence for this in the data, and it is built into our forecasting models. For this study, we have recalibrated the relationships between GDP and demand based (called ‘elasticities’) on the most recent data. We did not find maturity; the current traffic downturn is driven by econo-mics, not saturation of European air transport. So when business and consumer confidence finally return, when economies finally start growing again – which the economic forecasters say is within the next 18 months – then demand for air transport should also start to grow.

1 CNS is used in this document in the sense of infrastructure supporting ATM.2 Appropriate transition arrangements for the accommodation of legacy military systems have to be retained for longer periods and there is aneed

to recognise the different business models between military operations and those of commercial airliners which will benefit most from SES.


1.2 Document Structure

1.2.1 This document includes an Executive Summary, three Parts and Annexes.

n Part I – Introduction and Context, includes civil-military considerations in respect of the surrounding ATM regulatory and institutional environment.

n Part II – Interoperability, comprises the CNS interoperability elements, with a description of information exchange requirements, technological evolutionary trends and resulting civil-military interoperability recommendations. The timescale charts are to be read as follows:

The implementation timescales comprise baseline, time-based operations (Step 1), trajectory-based operations (Step 2) and performance-based operations (Step 3).

Those deployment steps are now capability-based. From a deployment point of view they are no longer fixed in time. Baseline means that R&D is no longer needed and the validation phase has been completed. Step 1 means end of validation phase (V3) normally by end of 2013 and deployment between 2014 and 2020 or even later. Step 2 implies end of validation phase (V3) normally by end of 2017 and deployment at least 3 years after end of validation. Step 3 means end of validation phase (V3) normally by end of 2020 and deployment at least 3 years after end of validation.

A specific table is included at the end of each roadmap with a list of recommended implementation actions for civil-military CNS interoperability, indicating the performance based opportunities (adaptation, interfacing, enabler re-utilisation, ground support, etc.) that would enable implementation with a reduced impact or at lower cost.

n Part III – Coordination, this part adds cross-domain subjects (spectrum, standardisation/certification, planning, procurement and security) that require civil-military coordination efforts to enable the identified interoperabi-lity targets.

Civil-Military Interoperability Roadmap

Baseline Step 1 Step 2 &3

Requirement

Compliance Option

Decommissioning

Mandatory Recommended Legacy

Notes:1) Requirements can be defined as deployment or decommissioning and can entail a procurement action or just a compliance statement2) Notes may indicate conditional constraints , e.g. availability of a technical standard3) Requirements can entail forward fit , retrofit or adaptation of existing capability or interface

Figure 1. Timescale Table

12

1.3 objective

1.3.1 The main objective of this Roadmap is to provide technical information to military authorities and ATM planners to determine the most cost-effective and mission efficient technical and system options to enhance civil-military CNS interoperability and technology convergence. It proposes interoperability recommendations, preferably based on performance targets and re-utilisation of existing military capabilities to reduce implementation costs.

1.4 Intended readership

1.4.1 This document is devoted to civil and military technical staff involved in ATM/CNS management and operation, regulatory work, planning, architecture, research, and implementation programming. It may also be useful to defence industry stakeholders.

1.5 Scope

1.5.1 This Roadmap covers technical aspects relating to the CNS infrastructure that supports EATMN, describing potential alternatives for achieving a determined level of civil-military system and network interoperability. Services, applications, middleware, information models, and architecture design deserve only a brief mention as supporting information.

1.5.2 It applies mainly to the infrastructure supporting IFR/GAT operations and aerial activities conducted with the status of mission trajectory. Military operations conducted as OAT in segregated environment are not covered by this document and may require a minimum subset of the CNS infrastructure, as mentioned in supplementary guidance [Ref 2].

1.5.3 Safety cases, cost assessments, security policies, risk analysis, data quality levels, standards development, certification, human roles, operating procedures, governance, resource management, monitoring and environmental impacts are aspects not deeply covered in the present document, which require further and significant consideration. These aspects are major topics in determining the feasibility and cost associated with implementing a capability and so have to be addressed when considering compliance. Technology support for UAS/UAV is also a subject not extensively addressed in this document.

1.5.4 It is important to stress that this document acknowledges that some relevant ATM R&D work streams have no validated results as yet. For those, information is included to identify technology trends but no proposals are made for subsequent deployment/implementation or regulatory development. Plans and activities directly related with deployment are outside the scope of this document.

1.6 baseline information and assumptions

1.6.1 The present Roadmap assumes that the level of civil-military integration in each State and local organisation and arrangements, as well as legacy systems in place, may dictate dissimilar interoperability options.

1.6.2 New developments may take full advantage of Commercial Off The Shelf (COTS) components, in order to move away from bespoke CNS solutions for ATM. COTS can be either civil or military equipment. Military COTS tends to be much more expensive than civil but includes additional functionality. Multi-functional military COTS may result in more cost effective options.


2. ICAO GLOBAL INTEROPERABILITY CONSIDERATIONS

2.1 Chicago Convention

2.1.1 The Chicago Convention (ICAO) of 1944 states:

Article 3 Civil and state aircraft (a) This Convention shall be applicable only to

civil aircraft, and shall not be applicable to state aircraft.

(b) Aircraft used in military, customs and police services shall be deemed to be state aircraft.

(c) No state aircraft of a contracting State shall fly over the territory of another State or land thereon without authorization by special agreement or otherwise, and in accordance with the terms thereof.

(d) The contracting States undertake, when issuing regulations for their state aircraft, that they will have due regard for the safety of navigation of civil aircraft.

2.1.2 The annexes to the Chicago Convention, also referred to as standards and recommended practices (SARPs), are in practice widely recognised as technical obligations. Article 33 of the Chicago Convention includes the principle that if an aircraft is certified by the competent services in a country which is signatory to the convention and applies ICAO recommendation for airworthiness standards and procedures, the other ICAO countries should recognise this certification.

2.1.3 From the ICAO point of view, an airworthiness certificate is mandatory for international flights. This does not apply for military aircraft but article 3 d) referenced above, stipulates that the contracting States must respect safety regulations.

2.1.4 It is normally the responsibility of the Ministry of Defence or other designated national authorities (it varies from State to State) to declare their aircraft fleet, qualified to perform aerial operations.

2.2 ICAo Aviation System block upgrades (ASbu) Initiative

2.2.1 Future ATM architectures need to be consistent with the International Civil Aviation Organisation (ICAO) Global Concept (Global Air Navigation Plan - GANP) [Ref 3] for the sake of global interoperability.

2.2.2 In order to define a fully harmonised global air navigation system built on modern performance-based technologies and procedures, ICAO put forward the concept of Aviation System Block Upgrade (ASBU). The Block Upgrades and their capacity modules define a programmatic and flexible global system engineering approach, allowing all States to advance their air navigation capabilities based on their specific operational requirements.

2.2.3 An ASBU designates a set of improvements suitable for global implementation from a defined point in time, to enhance the performance of the ATM system.

2.2.4 ASBU comprises the following block upgrades:

n Block 0: available nown Block 1: available to be deployed globally

from 2018n Block 2: available to be deployed globally

from 2023n Block 3: available to be deployed globally

from 2028 and beyond

2.2.5 The ASBU dates refer to the availability or ability to use the module in an operational manner and generate operational benefits.

2.2.6 Multiple technology roadmaps are submitted to ICAO with the aim of aligning with the ASBU framework. Civil-military CNS interoperability proposals must take into account such roadmaps and be synchronised as far as possible with other overarching plans where they do not constrain military mission effectiveness.

14

2.2.7 At the technical level, this document will maintain some traceability between the identified technical requirements and Annex 10 to the ICAO Convention, in particular the ICAO concept of Aeronautical Telecommunications Network (ATN).

2.2.8 A summary of the enablers identified in the ICAO GANP roadmaps is presented below (particular guidance on the applicability of these global requirements for military implementation will be described throughout this document).

block 0 block 1&2 block 3

CoM• IPDeploymenttomovefromIPv4toIPv6

(including FMTP in Europe)• MigrateInter-CentreATMVoicetoVoIP• AeronauticalMessageHandlingSystem

(AMHS)• Air-GroundCommunicationswithVHF

8.33 kHz Radios• VHFACARSandATNVDL2forconti-

nental and SATCOM ACARS (oceanic)

CoM• SupportDigitalNoTAMandMEToverIP• IntroductionofFIXMasglobalstandard

for flight data• Continuetomigrategroundvoiceto

VoIP• ContinueduseofVHF8.33kHzRadios• VHFACARSPhasedOut• ContinueduseofATN/VDL2• AeroMACSintroducedforairports• HFACARSmovetoATNHF/SATCOMData

Link (oceanic)

CoM• DataLinkbecomesprimarymeansfor

air-ground data exchange• HFmigrationtoSATCOM(oceanic)• FutureCOMInfrastructure(LDACS)• SATCOM

NAV• ContinueduseofConventionalNaviga-

tion Enablers (DME, VOR, NDB, ILS, MLS)• IntroductionofCoreGNSSConstellations

and Augmentations• StartintroducingPerformanceBased

Navigation (PBN)

NAV• ContinueduseofCoreGNSSConstella-

tions and Augmentations• ContinueintroducingPerformance

Based Navigation (PBN)

NAV• ReductionoftheuseofConventional

Navigation (NAV infrastructure rationali-sation)

• ContinueintroducingPerformanceBased Navigation (PBN)

SuR• ContinueduseofPSR• ContinueduseofSSRModeS• DeploymentofCooperativeSURSystems

(ADS-B, WAM, MLAT)• Datafusion(includingADD)• ModeSELSforallaircraft• ModeSEHSandADS-BOutfortransport

type aircraft• SurveillanceDataSharing• ADS-C(oceanic)

SuR• ReductionofPSRandintroductionof

Multistatic PSR• ExpansionofADS-BIn/Out

SuR• LimiteduseofPSR• SWIMpioneerapplicationsoverIPto

share SUR• Cooperativetechniquesdominant

(ADS-B In/Out with more applications)• Increasedsituationalawareness

Table 1. Summary of ICAo block upgrade Technology Roadmaps (Enablers)


3 SINGLE EUROPEAN SKY LEGISLATIVE AND REGULATORY FRAMEWORK

3.1 SES Framework

3.1.1 The Single European Sky (SES) was an initiative launched by the European Commission to reform European Air Transport to meet future capacity and safety needs, organizing airspace and air navigation on a European scale. The initiative relies on a harmonized regulatory framework in which the technical regulation stems from essential requirements and where rules and standards are complementary and consistent. Interoperability deserves great emphasis in SES processes.

3.1.2 The SES basic regulations include:n 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 (‘Framework Regulation’)

n Regulation (EC) No 551/2004 of the European Parliament and of the Council of 10 March 2004 on the organisation and use of the airspace in the single European sky (the airspace Regulation)

n Regulation (EC) No 550/2004 of the European Parliament and of the Council of 10 March 2004 on the provision of air navigation services in the single European sky (the service provision Regulation)

n Regulation (EC) No 552/2004 of the European Parliament and of the Council of 10 March 2004 on the interoperability of the European ATM network (the interoperability Regulation)

n Regulation (EC) No 1070/2009 of the European Parliament and of the Council of 29 October 2009 amending Regulations (EC) No 549/2004, (EC) No 550/2004, (EC) No 551/2004 and (EC) No 552/2004 in order to improve the performance and sustainability of the European aviation system (for SES II)

3.1.3 The SES Framework Regulation, supported by the three other Regulations, was designed to create an European Airspace conceived and managed as a single continuum and to optimise the safety and efficiency of the European ATM Network (EATMN). It contains a military “carve-out” provision in view of the fact that military operations and training are a State responsibility.

3.1.4 The Member States adopted, in parallel with the first SES package, a general statement on military issues related to the Single European Sky. According to this “Common Declaration” statement, included in Regulation (EC) No 549/2004, Member States should, in particular, enhance civil-military cooperation and, to the extent deemed necessary by all Member States concerned, facilitate cooperation between their armed forces in all matters of ATM.

3.1.5 It is assumed that civil-military CNS interoperability developments contribute to the Essential Requirements defined in the SES Intero- perability Regulation [Ref 4] once brought into the appropriate SES regulatory context either as binding implementing rule provisions or as voluntary specifications or guidance material.

3.2 SES Interoperability

3.2.1 Concerning SES interoperability, it is important to highlight that, under the terms of the aforementioned European Commission’s Interoperability Regulation, systems, procedures and constituents which meet a Community Specification are assumed to be compliant with the essential requirements of the regulation and the relevant implementing rules.

3.2.2 It is important to stress that there are evolving aspects that will drive specific regulatory efforts. These comprise the emergence of Functional Airspace Blocks (FABs), the increasing focus on performance, the role of National Supervisory Authorities (NSAs) and EASA, EUROCONTROL’s appointment as Network Manager and the ATM deployment coordination aspects, as delineated in the ATM Master Plan and in the Network Strategic Plan.

3.2.3 The SES regulatory layers comprise:

Implementing Rules (binding):n They are Developed by EUROCONTROL3 or

by EASA in line with a mandate issued by the EC (or within the framework of EASA ).

n They must determine any specific requirement that complements or refines

3 EUROCONTROL is assisting the European Union, contributing to both the regulatory and technological elements of the Single.

16

the Essential Requirements and describe the coordinated introduction of new, agreed and validated concepts of operation or technology.

n Most interoperability IRs include provisions on State aircraft or military-related service provision.

Community Specifications (voluntary):n Possible means of compliance and will be

mandated by the EC in the form either of European standards (drawn up by European Standardisation Organisations – ESOs: ETSI, CEN and CENELEC in cooperation with EUROCAE) or EUROCONTROL specifications.

n Systems, procedures and constituents that meet Community Specifications are presumed to be compliant with mandatory rules.

n Community Specif ications refer to statements in the Official Journal referencing existing or new standards that are voluntary in nature and that provide the technical details supporting either directly the Essential Requirements or IRs.

n Multiple technical standards with relevance to civil-military CNS interoperability are developed by the EUROCONTROL, EUROCAE, RTCA or by EASA, ARINC, SAE, etc.

3.3 Applicability of EASA Regulations and Specifications

3.3.1 Regulations and Specifications developed and published within the context of EASA follow a specific process in line with its regulatory framework. That process should ideally be improved to facilitate the consideration of civil-military coordination requirements but the way to progress that was not yet clearly defined as EASA does not have competence over military organisations.

3.3.2 EASA regulator y mater ials, including specifications, do not apply to State aircraft and military systems due to the provisions set out in the EASA Basic Regulation (216/2008 amended by 1108/2009). This regulation explicitly states

that it does not apply to products, parts, appliances, personnel and organisations carrying out military, customs, police, search and rescue, firefighting, coastguard or similar activities or services.

3.3.3 Nevertheless, the Member States must undertake to ensure that such activities or services have due regard as far as practicable to the objectives of that Regulation (article 1). This means that such EASA requirements have to be considered if a State aircraft operator voluntarily decides to obtain EASA certification or to apply those rules for internal operational approval processes. Annex II of the same Regulation also excludes applicability to aircraft that have been in the service of military forces, unless the aircraft is of a type for which a design standard has been adopted by the Agency.

3.4 Network Manager

3.4.1 Commission Regulation (EU) 0677/2011 lays down detailed rules for the implementation of ATM network functions. This regulation establishes the Network Manager (NM) and defines its tasks including the coordination of scarce resources (coordination of radio frequencies and improvement of transponder code allocation) as well as support to stakeholders in their deployment and implementation plans. The NM will also ensure optimisation, interoperability and interconnectivity within its area of responsibility.

3.4.2 Article 11 of the abovementioned Regulation describes the civil-military coordination aspects in relation to the Network Manager and primarily states that the NM ensure appropriate military representation in planning. The Network Strategic Plan (NSP) details the strategic objectives including the need to make available and share information and data, relevant to network management and operations. System interoperability and the evolution of the network technical infrastructure are important areas in the NSP and the role of the military is well described in the document. The present Roadmap will also contribute to the NSP objectives.


4 SINGLE EUROPEAN SKY ATM RESEARCH (SESAR)

4.1 SESAR Target Concept

4.1.1 SESAR is the technology modernisation component of the SES initiative. The SESAR Target Concept represents a paradigm shift from an airspace-based environment to a trajectory-based environment. Key to the concept is the “Business/Mission Trajectory” principle in which the airspace users and ANSPs define together, through a collaborative process, the optimal flight path. Taking full advantage of existing and newly developed technologies SESAR’s target concept relies on several key features like:

n Airspace configured according to operations – 4 D trajectories

n New separation modesn 4D contractsn Network Centric Operationsn System Wide Information Management

(SWIM)n Integration of airport operationsn Advanced airport toolsn Automated control functionsn Satellite-based navigationn Collaborative planningn Human in the loop.

4.1.2 The research activities, conducted under the SESAR development phase, are aimed at defining and validating technical solutions for subsequent deployment. Decisions for effective implementation will depend on subsequent industrialization, safety case results, performance assessments, cost/benefit analysis, security constraints, institutional considerations, etc.

4.2 The European ATM Master Plan

4.2.1 Edition 2 of the ATM Master Plan (October 2012) includes a deployment view and contains links to ICAO ASBU. It comprises proposals for deployment with essential operational changes including moving from airspace to 4D trajectory management, traffic synchronisation, network cooperative management & dynamic capacity balancing, SWIM, airport integration

and throughput and conflict management and automation deployment. Those proposals are now organised as a deployment baseline, with three steps that are capability-based and no longer fixed in time.

4.2.2 The above-mentioned key features rely on technical enablers described in specific infrastructure roadmaps for communications, navigation and surveillance. The Master Plan includes a specific Military Executive Summary. The table below gives an overview of the ATM Master Plan CNS enablers impacting military organisations.

4.2.3 The next level of technical granularity is constantly being consolidated within the e-Master Plan, on the basis of an integrated roadmap which maps operational improvements (OI) with system enablers (SE).

18

Deployment baseline Step 1 Step 2&3

CoM• Today’srelianceonAFTN/CIDINis

evolving to use Internet Protocol for ground-ground communications

• AeronauticalMessageHandlingSystems(AMHS)

• Air-groundcommunicationswithVHF8.33 kHz Radios

• CPDLCwithATNVDL2DataLinkfortransport-type aircraft

• Migrationofmilitaryaeronauticalinfor-mation to EAD

• FMTP/SYSCOfortransfer

CoM• Interoperabilityandsecurityformilitary

interconnection to IP Networks (e.g. PENS)

• NetworkingofASMSystems• OATflightplanintegrationinIFPS• Initial4DusingATNVDL2DataLinkfor

transport-type aircraft

CoM• SystemWideInformationManagement

(SWIM) SOA • Fullsetofadvancedcontrollertools(ATC

Systems)• DataLinksupportingFull4Dforall

aircraft• FutureCOMInfrastructure(FCI)

NAV• Conventionalnavigation(e.g.B-RNAV)• RVSM(voluntarycompliance)• FMimmunity

NAV• PerformanceBasedNavigation(PBN)

Accommodation of State aircraft (depends on regulatory options but likely to comprise RNP-1 and VNAV as a minimum)

NAV• PerformanceBasedNavigation(PBN)

Accommodation of State aircraft with RTA (likely based on reutilization of capa-bilities)

• UseofFMS/MMSforkey4DFunctions

SuR• ModeSELSforallaircraft• ModeSEHSandADS-BOutfortransport-

type aircraft• Surveillancedatasharing

SuR• ADS-BIn/Outfortransport-typeaircraft

SuR• ADS-BIn/Outfortransport-typeaircraft• Rationalisationofthesurveillanceinfra-

structure• ADS-Boversatellite

Table 2. European ATM Master Plan Enablers Impacting Military


PART II

INTEROPERABILITY

20

5 INFORMATION EXCHANGE REQUIREMENTS (IER)

5.1 The Need for Information Exchange and Common Models

5.1.1 Civil-military co-ordination supporting safety, continuity of service, security and identification of flights as well as air-picture compilation and associated collaborative decision-making (CDM) processes, calls for a permanent exchange of information between civil and military ATM and Air Defence units. Emerging concepts and automation rely very strongly on a real-time information-rich environment where aircraft become nodes of the network-enabled infrastructure (SWIM) supporting EATMN.

5.1.2 IERs derived from operational scenarios reflect the role of military organisations as airspace

user, ATC service provider, airport operator and command and control (C2) entity. Those IERs justify civil-military interoperability measures and contribute to military-military interoperability.

5.1.3 Military ATM/C2 entities need comprehensive, accurate and timely flight/trajectory data on all flights currently within their area of responsibility (AoR). They also need access to aeronautical, meteorological, surveillance, and flow and capacity data, relating to airspace and aerodromes within that AoR. Civil ATM entities need early sharing of planning information, to improve CDM and situational awareness of all military air activity. Access to military surveillance capabilities may be essential in order to maintain coverage of the relevant area of responsibility (AoR).

IER NM Civil ATC Mil ATC Mil C2/AD WOC Civ. a/c Mil a/c

Aeronautical Information X X X X X X X

ASM co-ordination data X X X X X X X

Meteorology data X X X X X X

Initial Flight Plan (GAT) X X X X X

Current Flight Plan (GAT) X X X

Initial Flight Plan (OAT) X X X X X

Flight Data (Inter-Centre Coord.) X X X

Flight Object X X X X

Flow and Capacity Management X X X X X

Primary Radar data X X X

SSR Aircraft Identification X X X X X X

Trajectory data (SBT) X X X X X

Trajectory data (SMT) X X X X X

Trajectory data (RBT/RMT) X X X X X X X

Inter-Centre Voice X X

Air-ground Voice X X X X X X

Air-air Voice X X

Controller-Pilot Data Link X X X

Initial 4D data X X X X X

Full 4D data X X X X X

ACAS and GPWS data X X X X

Emergency data X X X X X

Navigation data X X

Approach and Landing data X X X X

Terrain data X X X X

Safety (STCA) Warnings X X

Table 3. Typical Civil-Military ATM Information Exchange Requirements


5.1.4 EATMN is on its way of migrating to standardised information (digital) formats and models. Emerging global data models comprise standards like the Aeronautical Information Exchange Model (AIXM), Weather Information Exchange Model (WXXM), Flight Information Exchange Model (FIXM) and others defined by EUROCAE. SWIM will introduce harmonised, conceptual and logical ATM data reference models.

22

6 COMMUNICATIONS INTEROPERABILITY

6.1 Communications Evolutionary Trends

6.1.1 The future communications infrastructure supporting EATMN will contribute to a holistic “end-to-end” approach. The main trends associated with the evolution of aeronautical communications are:

n Migration towards ground communication networks based on distributed Internet Protocol technologies to enable network-centric SWIM architectures

n Deployment of Aeronautical Message Handling System (AMHS) to replace/enhance some segments of the ICAO Aeronautical Fixed Telecommunications Network (AFTN)/ Common ICAO Data Interchange Network (CIDIN)

n The greater deployment of voice over IPn Continued use of air-ground voice

(VHF DSB 8.33 kHz), supporting critical communications. Digital voice for air-ground communications may be introduced in the long term

n Widespread implementation of air-ground data link communications which, in the future, will replace air-ground voice (VHF) as the primary means of ATC communications

n Depending of studies and cost benefit analysis, possible introduction of higher-capacity data link technologies in the context of the Future Communications Infrastructure (FCI) initiatives comprising airport, terrestrial and SATCOM data link segments as well as a multilink environment

n Developments leading to the introduction of software defined radio (SDR)

6.1.2 Ground communications evolution is a decisive step towards the implementation of SWIM. This net-centric structure will then contribute to a better integration of air traffic control (ATC), airline operational control and airport systems. It will also pave the way for aircraft to become a node of SWIM.

6.1.3 That infrastructure will facilitate information exchange supporting FUA as well as automation for ATC to ATC coordination, including the

emergence of Flight Object concept [Ref 5] and advanced Flight Data Processing Systems (FDPS). This will be followed by the use of Flight Message Transfer Protocol (FMTP)4 [Ref 6] which entails the adherence to IP, for inter-centre system coordination.

6.1.4 New centralised service approaches like, for example the centralised management of network functionalities or the creation of virtual centres by remotely operating systems will be a reality.

6.1.5 The introduction of air-ground data link capabilities will be vital to enable real-time sharing of 4D trajectory and the availability of ATM information in the cockpit. Advanced concepts, like new separation modes, will be enabled.

6.1.6 Bespoke systems will make way for commercial-off-the-shelf solutions and many non-critical requirements may be sustained by web-based services. Defined performance levels and the quality of aeronautical data5 must be respected.

6.2 Ground-Ground Communications

6.2.1 Aeronautical Fixed Telecommunications Network (AFTN) and Common ICAo Data Interchange Network (CIDIN)

6.2.1.1 Aeronautical Fixed Telecommunication Network (AFTN) is a network introduced in the 1950’s for the provision of Air Traffic Services (ATS)6 organised under the auspices of ICAO Annex 10. There are still multiple AFTN nodes in European countries but the technology used is clearly outdated.

6.2.1.2 A Common ICAO Data Interchange Network (CIDIN), was conceived in the 1980’s to replace the core of the AFTN with higher capacity and better quality of service, such as X.25 and ISO OSI layering. CIDIN technology is also nearing obsolescence: X.25 equipment and protocols upon which CIDIN is based will soon be phased out. Both AFTN and CIDIN need to be replaced; ICAO has specified the ATS Message Handling System (AMHS) to meet this requirement.

4 Commission Regulation (EU) Nr 633/2007 of 07 June 2007 laying down requirements for the application of flight message transfer protocol used for the purpose of notification, coordination and transfer of flights between ATC units

5 Commission Regulation (EU) No 73/2010 of 26 January 2010 laying down requirements on the quality of aeronautical data and aeronautical information for the SES

6 Its use in the context of ATC-ATC coordination including the applicability of system coordination and the use of OLDI messages, emerging protocols and the emergence of Flight Object concept are discussed at the end of this Chapter


6.2.1.3 Military users continue to rely on AFTN/CIDIN to exchange aeronautical information and flight data with other units mainly through ANSP sub-networks.

6.2.2 Aeronautical Messaging Handling System (AMHS)

6.2.2.1 AMHS is a messaging service based on International Standards Organisation (ISO) X.400 standards, overriding size limitations and enabling distribution of more structured information such as Extended Markup Language (XML). In addition to being the replacement for AFTN/CIDIN technology, AMHS is associated to the ICAO Aeronautical Telecommunication Network (ATN) environment for the purpose of exchanging ATS messages in a store-and-forward mode.

6.2.2.2 AMHS provides increased functionalities like the capability to exchange binary data messages, to secure message exchanges by authentication mechanisms or to support more complex data formats like the Flight Object.

6.2.2.3 E u r o p e a n A N S P s a r e a l r e a d y implementing AMHS. Distribution of flight plans, aeronautical information and meteorological data is already moving from AFTN/CIDIN to AMHS. AMHS to AFTN conversion (feature generally provided by the AFTN/AMHS gateway) is a solution to avoid upgrading to legacy systems but can only support traditional ICAO format messages.

6.2.2.4 In 2009, a EUROCONTROL Specification on AMHS was developed and subsequently published in the Official Journal of the European Union (OJEU) as a Community Specification (CS) [Ref 7]. This CS augments existing standards and includes: a basic ATS message handling service (ATSMHS), an extended ATSMHS, including safety, secur ity standards and direc tor y services, the interoperability aspects of communication gateways and proposed tests and verifications.

6.2.2.5 The EUROCONTROL AMHS specification recognises that the provision of AMHS security services is not as advanced as other

elements of the extended ATSMHS. For that reason, security specifications in the AMHS specification are to be considered as advisory indications.

6.2.2.6 AMHS is expected to migrate over IP networks such as the Pan-European Network Service (PENS) in the short term. AMHS extended services, such as Directory Services, may also be enablers of other applications due to its distributed modularity.

6.2.3 Pan European Network Service (PENS)

6.2.3.1 The ground-ground communication infrastructure supporting ATM in Europe is quickly moving away from obsolescent X.25 technology, more and more using Internet Protocol (lP)-based networks. On the 28 October 2009 a Pan-European Network Service (PENS) was launched with the signature of a contract involving a communications service provider.

6.2.3.2 PENS supports IP network services for EUROCONTROL’s Central Flow Management Unit (CFMU) and European Aeronautical Database (EAD) and interconnects ANSP networks. PENS will expand to support, in the medium term, all stakeholders’ ground data distribution requirements, including those emerging from SESAR. PENS Virtual Private Network (VPN) services may comprise:n Messaging (AFTN, AMHS)n Surveillance, Navigation (EGNOS, Radar

Data, SSR Codes)n Management Information Services

(IFPS, ETFMS, EAD/AIS)n Inter-Centre Ground Coordination

(Ground voice, flight data exchange)n Meteorology (Met messages, D Volmet)n Ground segment of Air-Ground Services

(A/G Voice, A/G Data)n New operational concepts (CDM, SWIM)n Security (PENS currently has no security

provisions. This must be addressed for transfer of any sensitive information).

24

6.2.3.3 PENS is the first step of an extensive ground IPv6 environment which is the envisaged target as part of an “all-IP connectivity” where aircraft are to be integrated through mobility IP in compliance with ICAO ATN/IPS architectures. Today, PENS consists of an IPv6 backbone connectivity to a combination of national and regional/local legacy networks still predominantly IPv4 or X.25.

6.2.3.4 A specific requirement mandating the use of lP-based technology in ATM is already in force. European Commission Regulation (EC) No 633/2007 [Ref 6] requires the use of IP for Flight Message Transfer Protocol communications for coordination and transfer between ATS units.

6.2.3.5 To ensure a smooth transition from X.25 to IP, some X.25-IP gateways7 will be used initially (when it is impossible to modify a legacy interface) or legacy X.25-based protocols will run over IP-based protocols (i.e. OLDI transition from FDE ICD Part 1 protocol to FMTP protocol).

6.2.3.6 The compatibility between IPv6 and IPv4 can be ensured using mechanisms like Network Address Translation (NAT), but the preferred interoperability solutions

are based on dual stack approaches8. Other technical aspects that affect IP interoperability are addressing schemes, use of unicast/multicast, quality of service performance targets and security. Technical guidance on those aspects is/will be made available by EUROCONTROL.

6.2.3.7 In summary, PENS is seen as the future backbone of SWIM (even if other alternative communications bearers could be used). It will expand to interconnect a wider range of stakeholders including the military. Implementation of future communications requirements will rely very strongly on adherence to PENS, with IPv6 as the preferred communications protocol.

6.2.4 Flight Data Processing Systems (FDPS)

6.2.4.1 Modern communications infrastructure and “networked” solutions are crucial to support automated ATC services provided for flights transferred from one ATC unit to the next. Availability of IP communications bearers and AMHS messaging are key, as well as gateways to interconnect different stakeholder communities.

Figure 2. Pan European Network Services (PENS)

7 EUROCONTROL Communications Gateway (ECG)8 The dual stack approach is the simplest way to resolve the IPv4 address conflict. It consists in assigning a second simultaneous IP address to

the end-systems for connectivity. In this case, the iPAX-TF recommends assigning a unique IPv6 address to a second physical interface. Major router vendors have integrated translation mechanisms (e.g. RFC2766) to allow IPv4-only end-systems to communicate with IPv6-only end-systems. Each packet between the IPv4 end-system is converted to IPv6 and vice-versa by a router. Dual-stacking end-systems is the preferred option as it will avoid the need for such mechanisms.


6.2.4.2 Where this inter-centre service is carried out by telephone, the transfer of data on individual flights, as part of the coordination process, is a major support task at ATC units, particularly at Area Control Centres (ACCs). Such verbal «estimates» began to be replaced in the 1990s by the use of connections between Flight Data Processing Systems (FDPS) at ACCs, referred to as On-Line Data Interchange (OLDI). This impacts civil and military ACCs as well as Air Defence in some cases.

6.2.4.3 The use of automatic systems for the exchange of flight data for the purpose of notification, co-ordination and transfer of flights between ATC units is covered in Regulation (EC) 1032/2006 [Ref 8] amended by Regulation (EC) 0030/2009 as far as the requirements for automatic systems for the exchange of flight data supporting data link services are concerned.

6.2.4.4 The mandatory use of IP for Flight Message Transfer Protocol (FMTP) communications is regulated as mentioned in 6.2.3.4 [Ref 6]. The EUROCONTROL Standard for OLDI9 [Ref 9] supports the COTR regulation.

6.2.4.5 Flight Data Processing Systems (FDPS) process elements of flight plan information

for various applications, such as flight data strip printing, radar data tag information, billing processes, national defence requirements. The system performs correlation with radar data for presentation to the ATC controllers. FDPS uses this information to probe for potential conflicts.

6.2.4.6 Modern FDPS (in particular where the concept of Flight Object [FO] is used to ensure a consistent view of the flight data across all FDPSs [Ref 5]) can be seen as a fundamental interoperability multiplier. Interconnected FO servers (maintaining the consistency of information in all FDPS) can support complex trajectory management services, including negotiation with downstream units, medium-term conflict detection (MTCD) across system boundaries and distribution of time constraints from arrival manager (AMAN) applications.

6.2.4.7 Envisaged improvements comprise real-time trajectories, continuously updated by flight behaviour determined by radar data and inputs from the controller, availability and dynamic exchange of aeronautical information (to keep the consistency between all FDPSs) and enhanced human-machine interface (HMI) with controllers.

Figure 3. ATC to ATC Data Exchanges

9 OLDI messages are used to exchange data between FDPSs on individual flights as part of the notification, coordination and transfer process.

26

6.2.5 System Wide Information Management (SWIM) backbone

6.2.5.1 System Wide Information Management (SWIM) is outside the scope of this Roadmap as it relates more to the four higher OSI10 layers. Nevertheless, a summary of SWIM concept and some civil-military considerations are included in Annex A. SWIM is a collection of standards, infrastructure and governance, enabling the management of ATM information and its exchange between qualified parties via interoperable services.

6.2.5.2 In essence, SWIM envisages an ‘intranet of the air’ where the ATM information held by different stakeholders in the system is shared over a common platform. SWIM is about building blocks that define middleware solutions and the information models and services to be supported. SWIM follows a number of principles including federated ownership of information, use of open standards to sustain semantic and technical interoperability, reliance on a service-oriented architecture (SOA) and service life cycle governance.

6.2.5.3 In terms of technical infrastructure, multiple stakeholders will be connected to SWIM, respecting specific service profiles and a network centric approach. SWIM has to be backwards interoperable, accommodating legacy systems. PENS will likely provide backbone service to SWIM for the three lower layers of OSI11 but other web-based B2B alternatives may also be considered. Air-ground segments will be crucial to enable aircraft participation to SWIM.

6.2.6 Voice over IP for ATC

6.2.6.1 ATM intra- and inter-centre voice communications include voice exchanges among all types of units and centeres (ATSUs: ACC, APP, TWR, CFMU) and ensure connectivity between the centres and the ground sector of air-ground voice networks.

6.2.6.2 To achieve dynamic sectorisation needed for the functional airspace blocks (FABs), new flexible technical solutions are required. Voice over Internet Protocol (VoIP) for ATM is one solution to facilitate

interoperability, particularly for the ground part of the air-ground component where one ground radio station is to be shared.

6.2.6.3 European telecommunication service providers (PTTs) are phasing out analogue and digital 64 kbps circuits that support the infrastructure on which today’s ATM voice services are based. In addition, inter-centre voice communications still rely on legacy analogue ATS-R2 and digital ATS-QSIG protocols. The main reason for VoIP to be introduced was the lack of common standard for the point-to-point ground component of air-ground communications.

6.2.6.4 Hence, a common standard was urgently needed at European level. VoIP for ATM is able to provide the right convergence target. EUROCAE WG-67, with cooperation from EUROCONTROL, European industry, and ANSPs, developed the first VoIP in ATM standard (ED136-138).

6.2.6.5 This EUROC AE standard de f ine s the operational voice concept, the interoperability solutions and network-associated requirements. It encompasses technical requirements and interfaces for all involved systems: VCS, radios, network, recording system, monitoring/net management system. ICAO finalised the inclusion of VoIP requirements into ICAO DOC 9896 by referring to the EUROCAE standard.

6.2.6.6 Based on those emerging standards it is expected that operational ground-ground ATC VoIP communications (namely for ground voice coordination between ATC centres) will start to be deployed shortly. PENS will be used in many cases as a backbone infrastructure.

6.2.7 Web-based b2b Services and use of Public Internet

6.2.7.1 In some States, for non-critical ATM data exchanges web-based business-to-business (B2B) services can be seen as an alternative to PENS. Such B2B services will rely on open standards and mainstream Internet technologies (web services) and are normally fully SOA compliant. These alternative connectivity options through internet should expedite the deployment of SWIM.

10 International Standards Organisation (ISO) Open Systems Interconnection 7 layer reference model11 OSI layers 1 (physical) to 3 (network) is allocated to the SWIM infrastructure layer (provided by PENS). OSI layer 7 represents the SWIM ap-

plication layer and the other OSI layers inbetween are allocated to the SWIM middleware


6.2.7.2 Nevertheless, ICAO document 9855 contains “Guidelines for the Use of Public Internet for Aeronautical Applications”. It states that when time-critical operational decisions must rely on aeronautical information it must not be provided via public Internet.

6.2.8 Surveillance Data Sharing

6.2.8.1 Surveillance data processing and sharing is an important subject that entails significant communications support with a clear impact on military users. The main technical and interoperability implications are addressed later in the Surveillance chapter.

6.3 Civil-Military Ground-Ground Communications Interoperability

6.3.1 AFTN/CIDIN Transition and AMHS Interoperability

6.3.1.1 Today, most military units rely on AFTN/CIDIN terminals to receive aeronautical information, NOTAMS, meteorological data, etc. Military access to the new ATM messaging (AMHS) structures will become a civil-military interoperability requirement as soon as AFTN is replaced by AMHS. AMHS is needed where Flight Object concept is to be enabled. Gradual transition and backwards interoperability have to be ensured.

6.3.1.2 Solutions for military access to AMHS may comprise the retention of AFTN remote tails, AFTN-AMHS gateways or interconnection with military networks on the basis of the X.40012-based Military Message Handling System (MMHS). The latter approach might pose significant challenges in terms of security and directory services compatibility. Past discussions indicated that the likely option for initial military access to AMHS is to rely on systems operated by civil ANSPs considering local AFTN/AMHS gateways or replacing AFTN terminals with ATS Message User Agents.

6.3.1.3 NATO STANAG 4406 (MMHS) defines an X.400 based MHS with extensions for military use, including a possible interface to civilian MHS via a trusted gateway. The MMHS Elements of Service and protocol are defined as a Military Messaging (MM) content type, identified as the P772 protocol. Several of the Business Class attributes, as defined for the Extended ATSMHS (e.g. precedence, originators-reference), can translate easily to P772 equivalents.

6.3.1.4 In any case, AFTN/CIDIN will remain during a transitional period and civil ANSPs may facilitate interfacing options. Local service-level agreements and security assessment cases will need to be performed prior to implementation initiatives leading to military systems interoperability with AMHS context. The technical basis for such interoperability deployment actions will be ICAO references and the EUROCONTROL Specification on AMHS [Ref 7].

6.3.2 Military Systems Access to PENS

6.3.2.1 Information exchange requirements described above justify the need for military access to PENS. Seamless interoperability between military systems and PENS structures or sub-networks will respond to the decommissioning of X.25 circuits, FMTP regulatory requirements, the need to introduce more advanced services, (e.g. AMHS, VoIP) and initial steps to migrate to network centric SWIM structures. The ultimate goal is compliance with ICAO Aeronautical Telecommunications Network (ATN) concept [Ref 10]. Military use of PENS will depend of adequate security provisions expected to be introduced in the future in PENS.

6.3.2.2 PENS can play a prominent role in civil-military radar/surveillance data sharing, to rationalise the surveillance infrastructure. PENS may be used to interconnect military sensors with regional networks or to enable clustering with civil sensors. PENS can interconnect Airspace Management (ASM) systems in a distributed environment to enable a common picture of airspace status. Connectivity between ATM context and military wing operation centres (WOC) can also be enabled via PENS.

12 X.400 is a suite of ITU-T Recommendations, developed in cooperation with the International Standards Organisation (ISO), which define standards for Data Communication Networks for Message Handling Systems (MHS). At one time X.400 was expected to be the predominant form of email, but this role has been taken by the SMTP-based Internet e-mail. Despite this, it has been widely used within organisations and variants continue to be important in military and aviation contexts.

28

6.3.2.3 Joining PENS, the military would benefit from bandwidth sufficient for higher data volumes and enhanced EATMN automation associated with real time coordination tasks, collaborative decision-making, implementation of voice over IP, ground support of air-ground data exchanges, increased surveillance data sharing and higher integration of ATC, airport and aircraft operations. In many States these tasks are supported through civil ANSPs.

6.3.2.4 Although military ground communications are quickly evolving towards the use of distributed LANs/WANs commercial off-the-shelf (COTS) technologies, including IP protocols, the direct interconnection of civil and military networks used in the ATM context will not be straightforward and immediate. Factors that hinder such connection can be institutional but also technical interoperability (e.g. protocol mismatch, addressing scheme incompatibilities, port allocation problems, high rate of packet loss, etc.), performance constraints and security requirements applicable to sensitive military information13.

6.3.2.5 Access to PENS VPN can be provided either via the ANSP network or by a dedicated router. The impact of interconnecting military systems with PENS can be minimised in many locations through reliance on ANSP networks to grant military systems access to PENS. Compliance of military-specific data formats defined in military standards will require interfacing/encapsulation solutions.

6.3.2.6 The technical requirements described above call for appropriate harmonised interoperability, interfacing and security solutions to be defined. When deployment decisions entail military participation in PENS the following interoperability aspects will need to be addressed using relevant technical ICD specifications and guidance [Ref 11].n Addressing schemes defining the

processes for the management of a data base with the allocated IP addresses/port numbers

n Dual-stack alternatives to ensure full flexibility of communications over IPv6 and IPv4 so that backbone and local networks can easily co-exist

n The use of multicast or unicast address structures depending on network configurations

n The performance QoS in line with operational usage in a networking environment consistent to those applicable to flight data and other applications as defined in [Ref 6] and other applicable specifications

n Security requirements as applicable.6.3.2.7 The required performance/QoS levels

must be validated. Applications like FMTP, AMHS, LARA, Radar and VoIP determine the required performance requirements and therefore dictate how the network should be deployed. Such applications depend on various parameters like Unicast and Multicast, IPv4 and IPv6 reachability, Port Connectivity, NTP Synchronization, Real Time performance, TCP and UDP Joint Performance, etc. The obtained results in terms of Average Delay (ms), Jitter (ms), Average bitrate (Kbps), Packets dropped (%) shall be used to compare with defined requirements for the specific application considered.

6.3.2.8 Any interoperability actions will be progressed with due regard to PENS institutional environment, governance considerations and financial constraints. T h e m i l i t a r y a u t h o r i t i e s s h o u l d cooperate locally with civil ANSPs and communications ser vice providers’ deployment actions to seek the conditions necessary to ensure the continued provision of current and future services. An interface between PENS and military systems will have to be specified.

6.3.3 FDPS Interoperability

6.3.3.1 Regulation (EC) No 1032/2006 on coordination and transfer (COTR) states: “timely exchange of flight data between ATS units and controlling military units should rely on the progressive implementation of automated processes” and “if they (military controlling units) choose to apply additional automated processes, the need for interoperability of the EATMN means that they must apply harmonised requirements”. This applies to ‘controlled airspace’ e.g. enroute type operations.

13 It is assumed that ATM information is unclassified by nature (although it can be declared sensitive) and that the protection of classified military information will not be addressed in the civil ATM context as that category of information is not to be shared with civil ATM.


6.3.3.2 The introduction of networked flight object (FO) servers (as defined in EUROCAE ED 133) and FDPS technology evolution and harmonisation (including new data formats) offer opportunities to comply with regulatory obligations and to enhance interoperability and benefit from up-to-date and consistent view of ATC-to-ATC flight data. Civil-military flight data exchange and airspace crossing are dynamic system components as they both require a dialogue between civil and military units.

6.3.3.3 FO is a concept which will contribute to mission trajectory in step 2 to enable specific trajectory management functionalities. For mission trajectory in step 1, only the availability of information for awareness should be envisaged. For that military-military and civil-military requirements still have to be integrated into the FO concept.

6.3.3.4 It is highly recommended that civil-military FDPS interoperability is promoted. However, due to cost and technical considerations it is expected that backwards compatibility will be maintained and that compliance

is sought through local arrangements not excluding remote operation. Some functionalities may be provided at the level of centralised services.

6.3.4 Military adoption of Voice over IP

6.3.4.1 In relation to the wide introduction of operational improvements associated with the support of ground ATC voice requirements applicable to civil ATS (inter-ATC Centers and units, tower, etc.) they should be adopted, as a minimum, where military inter-centre connectivity with civil centres or units is established. The EUROCAE standard on VoIP for ATM is the ideal solution to provide interoperability but transitional use of local solutions relying on legacy protocols may be pursued.

6.4 Recommendations

The following table summarises the Recommended Actions and Performance Based Opportunities. The subsequent figure shows the civil-military ground communications interoperability roadmap:

Recommended Actions Ground Communications opportunities to reuse capabilities/ lower costs

1 Monitor AFTN/CIDIN evolution towards AMHS and ensure, through local ANSPs, the improvement steps to maintain ground COM interoperability between military users and local networks.

Continue to use AFTN/CIDIN during a transi-tion and use gateways to ensure a smooth transition to AMHS. Consider synergies with MMHS.Coordinate with local ANSP.

2 Where justified by local requirements, implement FMTP for inter-centre coordination and transfer (at least for links with civil ATC centres supporting civil-military coordina-tion). Migrate from X.25 to IP in line with civil actions.

Use gateways to ensure a smooth transition.Coordinate with local ANSP.

3 Define technical interfacing solutions (PENS-Military gateway) to enable the intercon-nection of military systems to PENS (or its sub-networks). Specify such gateway so that ATM and C2 requirements are covered. Address security aspects

Define and validate a suitable gateway considering the characteristics of available military networks and systems to be interconnected.Coordinate with local ANSP.

4 Implement connectivity with PENS (or its sub-networks or other alternative means including web-based B2B) as justified by information exchange requirements.

Consider interconnection with military networks already using IP and/or the use of the gateway defined in 3.Coordinate with local ANSP.

5 Define solutions for the participation of military units and systems in SWIM and adhere to service oriented architectures. Address security aspects.

Build upon existing connectivity taking advantage of SOA.Coordinate with local ANSP.

6 Monitor developments in the area of Flight Object and FDPS interoperability aiming at benefits from the interoperability opportunities offered by these emerging concepts (only for awareness in step 1 and some integration in step 2/3).

Remote use of civil facilities.Coordinate with local ANSP.

7 Where justified by local requirements, implement VoIP for inter-centre voice coordina-tion (at least for links with civil ATC centres where applicable).

No.Coordinate with local ANSP.

Table 4. Recommended Ground Communications Implementation Actions

30

Civil-Military Ground COM Interoperability Roadmap



Notes:1) Depending on local arrangements 2) Evolving to VPNs and IPv6 backbone for additional stakeholders. Military gateway to be defined3) In replacement of AFTN/CIDIN (through ANSPs in most cases). Community Specification available4) Passive reception for awareness in step 1 and possible local implementations in step 2

Legacy X.25

IPv4 local bilateral networks 1)

Flight Message Transfer Protocol (FMTP)

IPv6 Pan European Network Services (PENS) 2)

SWIM participation (SOA) 2)

AFTN/CIDIN 1)

Aeronautical Messaging (AMHS) 3)

FDPS4) 4)

MFRCR2, ATS/QSIG Voice

Inter-centre VoIP

Figure 4. Ground Communications Roadmap


6.5 Air-Ground Voice Communications

6.5.1 VHF 8.33 kHz Expansion

6.5.1.1 Air-ground ATC communications in the context of GAT rely traditionally on instantaneous voice communications between pilots and controllers using an ANSP infrastructure based on VHF DSB AM line-of-sight.

6.5.1.2 VHF spectrum band 118-137 MHz is used to support such voice exchanges and also some air-ground data link allocations (ACARS, VHF Data Link (VDL) Mode 2, VDL Mode 4). In order to support the demand for additional voice channels and avoid frequency congestion, 8.33 kHz channel spacing has been implemented replacing 25 kHz channels.

6.5.1.3 Since 1999,the introduction of VHF 8.33 kHz channel spacing radio communication equipment has been taking place in the European area for GAT/IFR operations.

6.5.1.4 Regulation 1265/2007 [Ref 12] on air-ground voice channel spacing (AGVCS) turned the 8.33 kHz requirement into binding legislation, mandating the carriage of 8.33 kHz radios for GAT/IFR operations above Flight Level (FL) 195 and the provision of ground services by ANSPs. Subsequently, SES Regulation No 1079/2012, also on AGVCS, [Ref 13] repealed the first AGVCS regulation and expanded the 8.33 kHz requirement into the lower airspace.

6.5.1.5 The way air-ground voice is used will change in the medium/long term when air-ground data link becomes the primary enabler of routine air-ground ATC communications. By then, analogue VHF voice is expected to remain in service only to sustain safety-critical communications until alternative digital voice solutions become available (not before 2035+).

6.5.1.6 For air-ground voice communications in oceanic and remote areas, civil evolution will be to migrate from High Frequency (HF) to SATCOM voice (INMARSAT and/or IRIDIUM) with HF voice retained as backup. This will provide increased throughput and transmission quality.

6.5.2 VHF 8.33 kHz and State aircraft

6.5.2.1 Newer military radios have VHF 8.33kHz as a basic capability. Mid-life upgrades of radios are likely to be automatically compliant.

6.5.2.2 The abovementioned SES AGVCS Regulation [Ref 13] includes specific provisions for State aircraft 8.33 kHz mandatory equipage (see 6.5.2.4) when conducting IFR/GAT flights in the ICAO EUR Region. In parallel, the flights of remaining non-8.33 kHz equipped State aircraft, which cannot be retrofitted for a justified compelling reason, are accommodated by the civil ANSPs on UHF or 25 kHz VHF assignments provided that they can be safely handled within the capacity limits of the ATM system.

6.5.2.3 This regulatory provision on 8.33 kHz mandatory equipage is similar to those applicable to «civil» aircraft (e.g. forward fit followed by retrofit) but takes into account the specific constraints applicable to State aircraft (e.g. large fleets, long procurement cycles, etc). The regulatory text identifies particular situations when the equipage of State aircraft with 8.33 kHz capable radios cannot take place within the required timeframes, requiring the Member States to provide relevant information to the European Commission for these cases. However, these aircraft must be retrofitted by a given deadline. A generic exemption is provided for State aircraft that will be withdrawn from operational service by a defined date.

6.5.2.4 Equipage for civil aircraft means two independent sets of 8.33 kHz VHF radios as mandated by JAR-OPS, JAA TGL7 for civil aircraft. ICAO provisions are in Annex 10 and EUROCAE Minimum Operational Performance Specification (MOPS) for Airborne VHF Receiver-Transmitter operating in the frequency range 117,975-137,000 MHz in document ED-23B. There is no specific equipage definition for military aircraft. The regulation encourages implementation fo ED-23C standard if possible which has improved performance over ED-23B. Subsequent national regulatory developments may lead in the future to consideration for compliance of aircraft equipped with one VHF 8.33 radio plus one V/UHF transceiver.

32

6.5.2.5 Article 9 of AGVCS Regulation [Ref 13] contains the equipage dates for State aircraft conducting GAT/IFR operations as follows:n For above FL 195, State aircraft are

to equip by 31 December 2012 (transport-type) or 31 December 2015 (non-transport-type) when previously justified by procurement constraints

n Forward fit all State aircraft entering into service (or undergoing major mid-life upgrades) after 1 January 2014

n Retrofit all State aircraft by 31 December 2018

n Transitional arrangements are possible due to technical, budgetary or procurement constraints, subject to communication to the Commission by 30 June 2018 and equipage by 31 December 2020 at the latest

n Exempted: All State aircraft that go out of service by 31 December 2025

n ATS providers are to accommodate non-equipped State aircraft on UHF or VHF 25 kHz, provided safety is ensured. The publication in national aeronautical information publications (AIP) of applicable procedures is also required.

6.5.2.6 In the last decade military authorities have made very significant efforts to migrate towards VHF 8.33 kHz channel spacing. Over the last 10 years more than 1000 aircraft became equipped, with equipage rates reaching by 2014 around 80% for transport-type State aircraft and 60% for other aircraft types.

6.5.2.7 Th is regul at io n a l s o int ro duced requirements impacting the ground infrastructure, by defining the ratio of conversions to be achieved, and obligations to the radio manufacturers, by mandating exclusively 8.33 kHz radios to be put on the market from 17 November 2013.

6.5.3 use of ultra High Frequency (uHF) for ATC

6.5.3.1 Military Command and Control (C2) requirements rely heavily on the use of the UHF harmonised military band (225 MHz-400 MHz), historically known as the “NATO UHF Band”. UHF frequencies are used by military ATC and Air Defence to control aircraft flying Operational Air

Traffic (OAT) respectively outside or inside segregated airspace and when performing military air operations (e.g. air policing, air interception).

6.5.3.2 VHF 25 kHz channels in the military band 138-144 MHz are also available for off-route OAT operations and to support military aerodrome services in most NATO States and additionally in the band 145-156 MHz in some Eastern European States.

6.5.3.3 For GAT/IFR operations, the current practice, consistent with the AGVCS Regulation and the majority of national AIPs, is that State aircraft that are not equipped with an 8.33 kHz capable radio, are allowed to operate in the airspace designated for 8.33 kHz channel spacing operations, provided that they are UHF equipped and there is adequate coverage by ground stations. Note: It is considered important that these aircraft are also be VHF 25 kHz equipped in addition to UHF.

6.5.3.4 In general, non-8.33 kHz equipped State aircraft flying GAT/IFR are handled on UHF frequencies operated by civil ANSPs. However, some States have chosen to retain some VHF 25 kHz channels for air-ground communications. The handling of non-8.33 kHz equipped State aircraft is summarised in the individual State AIP and may be further detailed in other local documents. It is important to highlight that when civil and military ATC organisations are integrated the UHF service may be provided by civil ANSPs to also handle OAT traffic. In some locations, the UHF coverage tends to be less comprehensive than the VHF coverage. Consequently the use of UHF for ATC may not be viable without safety implications.

6.5.3.5 Coordination of UHF frequency allocations is facilitated by the NATO Spectrum and Capability Branch or by National Military Authorities/Frequency Managers, who coordinate UHF allocations to civil ANSPs.

6.5.3.6 The use of UHF for ATC must be compliant with a relevant ETSI technical specification respecting the operating procedures published in a relevant EUROCONTROL guideline [Ref 14]. The ICAO Frequency Management Manual [Ref 15] describes the procedures for obtaining UHF frequency allocations for ATC.


6.5.4 Air-Ground Digital Voice Communications

6.5.4.1 The advent of digital voice communications technologies, replacing analogue VHF 8.33 kHz in the future, is still a very speculative subject. The introduction of digital voice for air-ground ATC communications is not expected to happen before 2035.

6.6 Air-Ground Data Communications

6.6.1 ICAo Aeronautical Telecommunications Network (ATN)

6.6.1.1 Aeronautical telecommunication requirements are described in Annex 10 to the ICAO Convention. This annex includes the ICAO Aeronautical Telecommunications Network (ATN) concept14, comprising application entities and communication services which allow ground, air-ground and avionics data sub-networks to interoperate by adopting common interface services and protocols based on the International Standards Organisation (ISO) open systems interconnection (OSI) reference model.

6.6.1.2 ATN provides data communications services to ATS providers and aircraft operators and should be used as a key reference to determine any requirements in terms of end-to-end data communications supporting ATS, aeronautical operational communications (AOC), aeronautical administrat ive control (AAC ) and aeronautical passenger communications (APC).

6.6.1.3 Enhancements to the ATN internet service will allow the ground IP network to be used as a ground-ground ATN sub-network and it will contribute to the creation of an end-to-end all-IP environment with aircraft accommodated through its IP address. This will facilitate wider connectivity, including geographically disseminated military networks.

6.6.2 Controller Pilot Data link Communications and Initial 4D

6.6.2.1 ICAO ATN includes Controller-Pilot Data Link Communications (CPDLC) services (ICAO document 9880) as a supplementary means of ATC communications for routine air-ground exchanges (handovers and ATC clearances/requests) during en-route GAT/IFR operations in the upper airspace of the continental European region. As stated before, data communications will evolve to become the primary means of air-ground communications, with air-ground voice retained only for non-routine and emergency communications.

6.6.2.2 CPDLC is being introduced on the basis of the OSI protocol stack referred to as ATN B1. The current EUROCAE/RTCA standardised ATN B1 CPDLC application15 contains a subset of the ICAO message set and is not suitable for supporting ‘4D’ clearances. ATN B1-based CPDLC does not require the functional integration of CPDLC with the aircraft’s avionics (autoload capability in the FMS of complex route clearances). Also, ATN B1 does not support more advanced CPDLC and continental initial 4D trajectory management, relying on Automatic Dependent Surveillance–Contract (ADS-C) applications. These will be supported by ATN B2 standards (to be developed).

14 Detailed ATN technical provisions are described in the ICAO document 970515 It is of utmost importance not to mix the ATC applications and messages (normally standardised at EUROCAE/RTCA level), further described

later in this chapter, with the data link technology infrastructure that supports information exchange

AOC – Airline Operational CommunicationsAPC – Aeronautical Passenger CommunicationsFOC – Flight Operations CentreWOC – Wing Operations Centre/Military Centre

Figure 5. baseline Air-Ground Communications Configuration

34

6.6.2.3 CPDLC can be supported by various technical enablers. FANS 1/A16 capability over Aircraft Communications and Reporting System (ACARS) or ATN VHF Data Link (VDL) Mode 2 are technologies in the VHF band that can initially be used to support CPDLC. The latter is the choice for deployment in Europe and was the subject of the SES regulatory measures described later in this chapter. ACARS (used also for AOC communications and in oceanic and remote areas) was accepted as a means of compliance, at least during a transition phase, to cope with a large number of U.S. aircraft (including some military transport-type) (see Figure 5). More details on data link technologies are available in [Ref 16].

6.6.2.4 CPDLC implementation brings substantial benefits for ATM in terms of capacity and safety enhancements. It limits the need to introduce new sectors, reduces controller workload per aircraft, avoids misspelling and induces efficiency gains, which could translate into lower unit rates. If 75% of the flights are ATN-B1 equipped, estimations indicate an overall capacity increase of 11%. It was assumed that benefits would occur with around 15% of the aircraft fleet not equipped (including the military).

6.6.3 Data Link Services Regulation

6.6.3.1 Regulation (EC) No 0029/2009 on Data Link Services (DLS) [Ref 17] mandates DLS equipage based on ATN B1 for civil aircraft (newly produced and retrofit) from defined dates. It declares that State aircraft are exempt. Nevertheless, it stipulates that Member States which decide to equip new transport-type State aircraft, entering into service from 01 January 2014 onwards, with a data link capability relying upon standards that are not specific to military operational requirements, shall ensure that those aircraft have the capability to operate the data link CPDLC services defined in the Regulation.

6.6.3.2 In parallel to the provisions relating to aircraft equipage, the DLS Regulation will also apply to ATS providers which are required to ensure that (ground-based) ATS Units have the capability to provide and operate the defined data link services. ATS providers in the core region are expected to implement the ground infrastructure

from 7 February 2013 and those of the whole EU region from 5 February 2015. This is valid for GAT/IFR within the airspace above FL285 in the European Union flight information regions (FIRs) identified in the Regulation.

6.6.3.3 The EUROCAE/RTCA-standardised supplementary CPDLC services/applications mandated by the SES DLS regulation include:n Data Link Communications Initiation

Capability (DLIC); used to uniquely identify an aircraft (unambiguous association of flight data from the aircraft with the flight plan data used by the ATS unit) and to provide version and address information for all data communications services.

n ATC Communications Management (ACM); for automated assistance to the flight crew and controllers to conduct transfer of voice and data communications.

n ATC Clearances and Information Service (ACL), provides clearances and requests, exchanged between flight crews and controllers.

n ATC Microphone Check Service (AMC); provides controllers with the capability to uplink an instruction to an aircraft in order for the flight crew to check that the aircraft is not blocking a given voice channel.

6.6.3.4 The data link technology mandated by the DLS Regulation comprises ATN/OSI VDL Mode 2 (VDL2) as the validated means of compliance. VDL2 ground radio infrastructure is operated by several communication service providers (SITA, ARINC and also some European ANSPs). Subject to a positive business-case, the ANSPs may also provide CPDLC services to FANS 1/A aircraft. The same technology is expected to support the shorter-term initial 4D trajectory management requirements.

16 See definition of FANS in the glossary. FANS 1/A use for oceanic/remote communications is described later. Interoperability between FANS 1/A and ATN B1 is addressed in document EUROCAE ED-154A.


6.6.4 Automatic Dependent Surveillance – Contract (ADS-C)

6.6.4.1 ADS-C can be defined as the means by which the terms of an ATC-related “agree-ment” is exchanged between the ground system and the aircraft, via a point-to-point data link, specifying under what conditions ADS-C reports would be initiated, and what data would be contained in the reports. The abbreviated term “ADS contract” is commonly used to refer to an ADS event contract, ADS demand contract, ADS periodic contract or an emergency mode.

6.6.4.2 In the Oceanic and remote environment, ADS-C is associated with FANS 1/A techno-logy and relies on HF or SATCOM data links to transmit reports. For the continental airspace, with the introduction of 4D trajec-tory operations, ADS-C was designated as the technology to be used, over ATN/VDL2 data link communications, to carry initial 4D trajectory management (i4D) appli-cations (e.g. 4DTRAD) as well as airport services, including D-OTIS, DCL and D-TAXI as defined by EUROCAE WG78.

6.6.4.3 Initial 4D operations can be broken down in two steps; the first is the synchronisa-tion between air and ground of the flight plan or Reference Business Trajectory. The second step is imposing a time constraint and allowing the aircraft to fly its profile in the most optimal way to meet that constraint. The ATM system relies on all actors having the same view; it is therefore essential that the trajectory in the Flight Management System (FMS) is synchronised with that held on the ground in the Flight Data Processing Systems (FDPS) and the wider network systems. ADS-C is a funda-mental enabler to achieve that objective.

6.6.4.4 The avionics function, Required Time of Arrival (RTA), can be exploited by both en-route and TMA controllers for demand/capacity balancing, metering of flows and for sequencing for arrival management. By preparing the metering of aircraft at an earlier stage of the flight, the impact of constraints is minimised. This allows ATC to make optimum use of capacity at the right time, minimising risks through complexity reduction. This process enhances aircraft profile optimisation, flight predictability and allows improvements in the stability and reliability of the sequence built by ATC.

6.6.4.5 Initial 4D will require a more sophisti-cated message set and ADS-C reports for the exchange of the aircraft’s intended 4D trajectory together with the required func-tional integration of CPDLC and ADS-C with the aircraft’s avionics. The new EUROCAE/RTCA standard, containing the new CPDLC, ADS-C and D-FIS applications/services, is referred to as ATN B2. It is envisaged that ATN will use the Internet Protocol Suite (IPS) as described in ICAO document 9896 [Ref 10].

6.6.5 ADS-b Data Link

6.6.5.1 To support surveillance applications where transmission delay (latency) is more stringent, there is also a requirement for the introduction of broadcast data links to sustain the Automatic Dependent Surveillance–Broadcast (ADS-B) tech-nique. The selected broadcast datalink for ADS-B in Europe is the Mode S 1090 MHz Extended Squitter, as discussed in the surveillance section. In U.S. ADS-B will be supported by a combination of Mode S 1090 MHz Extended Squitter (global system for ADS-B) and Universal Assynchronous Transceiver (UAT ) (US domestic aircraft).

6.6.6 Future Communications Infrastructure (Future CoM)

6.6.6.1 Future COM Infrastructure initiatives, subsequent to activities conducted jointly by EUROCONTROL/FAA and ICAO, will introduce next-generation data link tech-nologies supporting new applications and overcoming performance limitations of VDL2 and other legacy data links. It will also deliver a new multilink infrastruc-ture. Future air-ground data links will rely on a combination of new terrestrial L-band (960-1215 MHz) data link, satel-lite-based (SATCOM) and airport data link technologies.

6.6.6.2 Such combinations of systems (terrestrial + satellite) have the advantage to offer complementarities in terms of technology, spectrum diversity, and coverage. The definition and validation of a SATCOM solu-tion is expected to result from synergies between the European Space Agency (ESA) and ATM workstreams.

36

6.6.6.3 Services to be supported by Future COM comprise, inter alia, full 4D trajectory management and air-ground exchanges associated with new separation modes, as well as uplink of aeronautical informa-tion and meteorological data. Future COM will also support airport communications services.

6.6.6.4 The terrestrial component of Future COM candidate solutions (L-Band Digital ATM Communications System - LDACS) is not yet fully defined and validated by the SESAR work programme. It will rely on narrow-band and wide-band solutions in the L Band (the only available spectrum out of VHF band) in order to come to the best compromise, taking into account aircraft avionics integration and spectrum constraints.

6.6.6.5 For the airport environment, the new airport surface data link, based on IEEE 802.16 WIMAX (AeroMACS) technology, will be introduced, supporting both ATS and AOC data exchanges. It will support surface routing and guidance functions as part of an overall A-SMGCS17, as well as the transmission of 4D trajectory data for the ground airport segment.

6.6.6.6 R&D efforts are expected to validate solu-tions for aircraft integration in the underlying SWIM environment. Aircraft will become a node of SWIM, being connected to the IP ground network-centric infrastructure through appropriate interfaces. Mobility IP must be progressed on the basis of ATN/IPS principles defined in ICAO document 9896.

6.6.6.7 Future COM will also propose a multi-link concept to ensure the co-existence of present and future technologies reco-gnising that global operation will require multiple technologies for operation in different parts of the world.

6.6.7 Air-Ground Data Link Applications

6.6.7.1 EUROCAE WG78/RTCA SC214 committees have been established to develop safety, performance and interoperability standards to support harmonisation of the next-generation ATS data link services in both continental, Oceanic and remote regions. These standards enable convergent deploy-ment and will be the basis for any required future evolution of data link services in the long term, extending the number of CPDLC services and introducing Initial 4D applica-tions based on ADS-C.

6.6.7.2 ATN-B1 supports today’s initial set of CPDLC applications while ATN-B2 will be the enabler to support the additional sets of CPDLC applications, i4D/ADS-C and D-FIS applications/services. These new applica-tions/services will entail more demanding performance levels to meet the availability, continuity and integrity requirements.

6.6.7.3 ATM applications that describe such ATS services are also referenced, in generic terms, in the EUROCONTROL/FAA Action Plan 17 Communications Operating Concept and Requirements (COCR) for the Future Radio System, Version 2.0 [Ref 18, 19].

6.6.7.4 Any possible implementation of ATM applications for military platforms and ground interfaces may imply more than the basic availability of any self-contained data link capability in the lower OSI layers as it may require software adaptations as well as leveraging with other avionics as sources for additional aircraft parameters. The detailed discussion of ATM applica-tions aspects is outside the scope of this Roadmap as it focuses more on the infor-mation exchange technology/bearer.

17 Advanced Surface Movement Guidance and Control System


Figure 6. Future CoM Data Link Configuration


6.7 other Air-Ground Communications Infrastructure Considerations

6.7.1 Air-Air Voice Communications

6.7.1.1 In current operations, pilots routinely monitor air-ground voice communica-tions between ATC and other aircraft (party line) but air-air voice communi-cations (between two aircraft) are only used today in rare circumstances such as Traffic Information Broadcasts by Aircraft (TIBA) procedures over remote areas with limited ATC support. Development and deployment for the future have never been progressed.

6.7.1.2 With the introduction of future concepts of operations, the only potential ATM-related air-air voice requirements could be linked to providing a back-up capability to the potential air-air data link exchanges. However, such an approach is far from mature and it seems unrealistic to expect a full back-up capability as many of the exchanges would entail the transmission of too much information (e.g. trajectory intent) for a voice back-up. Air-air voice communications would therefore presu-mably address only a subset of the air-air data link capabilities.

6.7.1.3 For specific military purposes, air-air voice contacts could enhance safety when used during air defence interception of civil aircraft. This is not yet a validated requirement.

6.7.2 Air-Air Data Communications

6.7.2.1 The use of air-air point-to-point data links is not presently envisaged for ATM. Nevertheless, it could be considered in the future, if broadcast data link becomes spec-trally insufficient to maintain synchronisation of trajectory data (technical acknowledge-ment and/or confirmation), to automatically disseminate information such as wake vortex separation minima or encountered weather hazards to following aircraft.

6.7.2.2 On the contrary, broadcast air-air data link is important. A capability for air-air broad-cast data link to support advanced ASAS applications is introduced in new concepts as a fundamental enabler of new separa-tion modes through the use of the ADS-B IN technique supported by Mode S 1090 MHz Extended Squitter data link. This subject is extensively discussed in the surveillance chapter.

6.7.3 Satellite Communications (SATCoM) for oceanic, Remote and Continental Areas

6.7.3.1 For Oceanic and remote areas, High Frequency (HF) voice remains the primary means of direct pilot-controller voice communications. However, HF band used for long-range communications (beyond visual / radio-horizon range) evidence poor link quality and there is limited reuse of the frequency channel. Consequently, voice communications via SATCOM, such as INMARSAT or MTSAT, started to be used in Oceanic and remote airspace, providing increased throughput and transmission quality. High Frequency (HF) voice remains as backup.

6.7.3.2 ATS data link communications in Oceanic and remote airspace are provided using FANS-1/A (ACARS) systems to support AOC applications and to achieve a number of ATS operational benefits such as separation assurance at 30/30 NM (RNP4) lateral/longi-tudinal, route and flight level conformance monitoring, facilitation of in-flight rerou-ting and weather avoidance and tailored arrival procedures. Such data communi-cations can be carried over HF data link (HFDL) or SATCOM.

6.7.3.3 Satellite data communications can use SATCOM Data 2, an ACARS packet-based sub-network. It uses the INMARSAT Aero-H Data 2 services compliant with available aircraft equipage (ACARS/FANS) and also with the ACARS AOA18 derivative. The ATN-compliant evolution is SATCOM Data 3, a bit-oriented sub-network. It uses the INMARSAT Aero-H Data 3 services.

6.7.3.4 En-Route reporting services are provided either through ADS-C or procedurally. ADS-C is used to supply surveillance

18 The ATC community defined the ICAO VDL standard to transport ATN air-ground communications but ACARS communications can also use the VDL link. Following discussion of the options for ACARS use of VDL, the AEEC Data Link Users Forum in January 1999 adopted as the standard interim architecture “ACARS over AVLC (Aviation Link Control)” (AOA). In the VDL AOA architecture, aircraft use the AEEC 618 protocol over the ICAO VDL standard AVLC link providing 31.5 Kbps capacity. Aircraft using VDL AOA obtain increased capacity over the VHF link but can only exchange messages in the same ACARS AEEC 618 formats used over the existing VHF analogue link.

38

information over the Oceanic region via satellite data link. In most cases, ADS-C and CPDLC are implemented simultaneously with FANS 1/A. In the North Atlantic Region (NAT) there are plans to implement CPDLC services.

6.7.3.5 The use of ADS-C technique is based on a negotiated one-to-one peer relationship between aircraft providing automatic dependant surveillance information and a ground facility requiring receipt of ADS messages. During flights over areas without radar coverage, reports can be periodically sent by an aircraft to the controlling air traffic region.

6.7.3.6 There are HF transceivers on board which have to be shared between voice and data. Voice communications have precedence over data link, which limits the HFDL availability. If HFDL was a useful medium an additional transceiver could be installed. However HFDL has a low data rate hence SATCOM is better solution.

6.7.3.7 Satel l i te broadband ser vices are a key building block of today ’s telecommunications hybrid networks which may offer services, including communications to improve air–ground exchanges.

6.7.3.8 A satellite-based system providing the required capacity and quality of service is needed not only to serve Oceanic airspace but also to complement the ground-based continental data link, improving total availability. In fact, the fundamental role of data link in continental airspace has been recognised by ICAO and is identified by the European ATM Master Plan as a crucial enabler for advanced concepts like 4D trajectory management (Initial and Full 4D) and new separation modes.

6.7.3.9 The type of satellite constellation (dedicated or commercial) to be used in the context of air transport still needs further research. INMARSAT has launched a new service called SwiftBroadband (SBB) using a new (4th) generation of satellites. Investment is being made in SBB to enable it to have the appropriate performance to support ATM communications.

6.7.3.10 In the US, IRIDIUM Communications Inc. started to plan a second-generation satellite constellation called IRIDIUM NEXT

in 2007. With launches expected to begin in 2015, IRIDIUM NEXT will offer higher data speeds, flexible bandwidth allocation, and IP-based routing. In the meantime, the US military have found innovative ways to use IRIDIUM services, making IRIDIUM NEXT a privately-held but significant space resource for future military operations in the US. Work has been completed at ICAO to develop provisions to allow IRIDIUM to offer ATM satellite communications.

6.7.3.11 European initiatives in the domain of SATCOM may also lead to the definition of solutions tailored to European requirements.

6.7.3.12 A significant effort in the area of SATCOM standardisation (update of ICAO SARPs19) is ongoing. The standardisation results will have a decisive impact on subsequent industrialisation stages and will contribute to avoiding the proliferation of technologies.

6.7.4 Software Defined Radio technologies

6.7.4.1 During Step 3, significant developments in the aeronautical data communications domain may include the advent of software defined radio (SDR) technologies enabled by the use of advanced techniques, e.g. real-time digital signal processing and adaptive filtering. Technical communications waveforms may be accommodated in multimode transceivers if feasible technology becomes available.

6.7.4.2 In a SDR system, components that have been typically implemented in hardware (e.g. mixers, filters, amplifiers, modulators/demodulators, detectors, etc.) are instead implemented by means of software. While the concept of SDR is not new, the rapidly evolving capabilities of digital electronics render practical many processes which used to be only theoretically possible. Such a design produces a radio which can receive and transmit widely different radio protocols (sometimes referred to as waveforms), based solely on the software used.

6.7.4.3 Full capabilities of SDR technology are still years away from deployment but today’s SDR systems already meet basic definition. There are some ongoing programmes in the US and Europe that are expected

19 SARPs - Standards and Recommended Practices


to pave the way for a new generation of radios that can emulate any waveform by simply changing software. A key feature of this technology is the software communications architecture (SCA) which became a real definition reference in this domain. SDR can also contribute to achieving interoperability through a common set of shared open system standards and applications.

6.7.4.4 SDR solutions could bring benefits n the ATM domain because multimode avionics are a key facilitator for interoperability including the integration of military systems. The integration of a huge number of civil capabilities in the limited cockpit space of military fighters and its co-existence with other military capabilities can be better achieved if SDR technology is introduced.

6.7.4.5 Co-existence between civil and military ATM/CNS functionalities and the need for technical solutions to overcome cockpit integration limitations will be present in future SDR initiatives still to be the subject of additional R&D efforts. Replacement of multiple hardware components by waveforms, supported by a common multimode avionics component, may be (depending on R&D results and deployment decisions) the preferred way to introduce in military tactical aircraft capabilities like Future COM, digital voice, advanced navigation and surveillance applications, etc.

6.7.5 Communications Requirements of Remote Piloted Aerial Systems (RPAS)

6.7.5.1 Although not only applicable to military RPAS, some communications requirements started to be defined by EUROCAE (WG 73). From a communication architecture point of view, RPAS operations support is divided into radio line of sight and beyond radio line of sight (BRLOS) operations.

6.7.5.2 Those terms are not yet officially defined but, together, they cover all possible connections between the remote piloted aircraft (RPA) and the remote pilot station (RPS) for command and control (C2) and ATM communications. As for now, it is widely agreed that SATCOM will

significantly contribute to support BRLOS communications.

6.7.5.3 The performance of the data link supporting those communications needs is one of the key elements that will determine the safe integration of RPAS in current aviation traffic and also safe flight over surface population and critical infrastructure.

6.7.5.4 Required Communications Performance (RCP) will have to be specified for both needs. It is already specified for ATM communications. In the same way, because they are directly related to safe traffic separation, C2 communications will have to meet specific RCP (C2-RCP). The C2-RCP concept will have to be developed at ICAO level.

6.8 Civil Military Air-Ground Data Link Communications Interoperability

6.8.1 Impact of Data Link Services on State Aircraft

6.8.1.1 The DLS Regulation [Ref. 17] states that State aircraft are exempt from CPDLC mandatory equipage requirements. Nevertheless, it stipulates the need to forward fit for Member States that decide to equip their new transport-type State aircraft entering into service from 1 January 2014, with data link capability relying upon standards which are not specific to military operational requirements. In that case, States shall ensure that transport-type State aircraft entering into service (new aircraft or aircraft suffering major mid-life upgrades) have the capability to operate the data link services defined in the regulation.

6.8.1.2 T h e D L S r u l e d e s c r i b e s C P D LC requirements which, together with i4D requirements associated with SESAR concepts, can be considered as the means to include State aircraft in air-ground data exchange implementation plans. That will impact, in Step 1, transport-type State aircraft flights being regularly conducted as GAT/IFR or under Business/Mission Trajectory status.

40

6.8.1.3 Other State aircraft types flying occasionally as GAT/IFR and flights conducted as OAT in segregated environment are not impacted by any ATM-related data link requirement.

6.8.1.4 The DLS regulatory provision means that DLS capabilities for Step 1 will rely mainly on the equipage of transport-type State aircraft with ATN/VDL2 technology (or “other communications protocol” e.g. FANS) in parallel with the gradual growth of ground CPDLC services provided by ANSPs all over Europe as planned in the regulation.

6.8.1.5 Today, only a reduced number of military aircraft evidence civil data link capability (few ATN/VDL-2 equipped and some FANS/ACARS capable especially from U.S.). FANS/ACARS State aircraft will also be accommodated in European airspace during a certain transition period. It is important to highlight that FANS/ACARS also handles ATS and AOC communications in Oceanic and remote areas, as described above.

6.8.1.6 Data link is a capability which is critical to the attainment of the performance targets and improvements foreseen in the context of future trajectory-based operations (including business/mission trajectory). State aircraft compliant with CPDLC and Initial 4D capabilities will be ready to support initial services and will have baseline provisions for subsequent enhancements. Potential benefits are related with seamless integration in a mixed mode environment together with capacity gains, ATC workload reduction and increased safety levels.

6.8.1.7 Concerning CPDLC, non-equipped State aircraft may continue to be handled through air-ground voice fall-back support. That reversion option may not be possible for i4D as it entails computer-to-computer exchanges between FMS and trajectory predictors.

6.8.1.8 NATO reference [Ref 20] : AC/92-D ( 2 0 1 1 ) 0 0 0 3 : N ATO Po s i t i o n o n Controller-Pilot Data Link Communications, 11 April 2011.

6.8.2 Military Data Link Accommodation

6.8.2.1 Fighter aircraft and rotary wing aircraft were left outside DLS regulatory provisions, as the introduction of civil data link technology is consider infeasible, due to the lack of cockpit space, technical integration constraints and prohibitive retrofit costs.

6.8.2.2 Depending on the results of R&D projects, military aircraft (e.g. fighters) could benefit from secure ground information exchange gateways installed within military centres to enable a seamless point-to-point service. Adequate interaction with military ground infrastructure may offer alternative means of compliance with ATM requirements, avoiding the need to retrofit any military avionics and taking advantage of their own capabilities while respecting all security, spectrum and technical constraints.

6.8.2.3 Technical solutions for military data link accommodation have not yet been fully demonstrated and validated and significant institutional uncertainties surround its possible consideration as a valid option which is not unanimously supported. Relevant constraints also exist in the area of security and spectrum impact on the civil L-band systems (e.g. DME, LDACS). Therefore, the ongoing R&D efforts in that domain are not stable and will be offered to the national military authorities for their own planning and deployment decisions as appropriate.

6.8.2.4 NATO reference [Ref 21]: AC/92-(EAPC)D(2013)0002: NATO Position on Using Tactical Data Links to interface with Civil Data Link Requirements, 14 January 2013.

6.8.3 Civil-Military Data Link Convergence

6.8.3.1 Trajectory concepts have an impact on commercial airlines, regional and State aircraft alike. For medium/longer term, modern data links could facilitate transport-type State aircraft operations in a seamless mixed mode environment to exchange data not only related to trajectory negotiation/revision but also other air-ground data link services (addressed and broadcast) such as information exchanges supporting new separation modes, traffic and terrain awareness, meteo and aeronautical information exchanges.


6.8.3.2 A defined level of capabilities will have to be introduced on State aircraft, including key 4D functions relying on system-to-system data exchanges (way points, time constraints, etc.) between trajectory predictors and onboard Flight Management Systems (FMS) or Military Mission Systems (MMS).

6.8.3.3 Step 2 & 3 requirements comprising full 4D functions and more advanced air-ground communications applications will impact all State aircraft types that need to conduct operations under the status of business/mission trajectory. ATM exchanges with those military aircraft may rely on their equipage with civil solutions or on the basis of forwarding data to military infrastructures, through secure ground interfaces (provided and controlled by the military), so that relay to military aircraft is possible20.

6.8.3.4 Future ATM data link requirements will require the migration from the baseline ATN/VDL2 capability to Future COM infrastructure (FCI) technologies described above. FCI high capacity data links should be seen as the longer-term goal for civil-military technology convergence in this domain.

6.8.3.5 The validation of FCI technology solutions will take full account of civil-military interoperability requirements. In due time, emerging enablers (e.g. LDACS, SATCOM, AeroMACS) will have to be evaluated as options for deployment. Consequently, any forward fit plans for State aircraft will need to take stock of this natural evolution from ATN/VDL2 to FCI and ultimately as a waveform in software defined dual-mode avionics.

6.8.3.6 Integration with the ground infrastructure will be fundamental. State aircraft supporting FCI data link capability will need to be cooperative with EATMN through air-ground SWIM Service Oriented Architecture (SOA) environment having access to the full range of advanced ATM applications. A multilink environment will enable a transition (with backwards compatibility) with legacy technologies; military aircraft may also be connected through own national military C2 systems and interfaces.

6.8.3.7 Military aircraft forward fit with FCI capability should address airborne integration concerns. Studies and further research are needed to identify technical alternatives to cope with HMI issues, including the use of multi-mode displays, bus/busbar availability and FMS coupling and hybridisation, co-site interference with other military avionics in respect of both space envelopes and electro-magnetic compatibility, antennae integration and multi-mode architecture considerations.

6.8.3.8 SDR or other multi-mode avionics approaches should offer the capability to operate in a re-configurable way by means of software-programmable instructions, without the need to introduce hardware changes. The future aircraft communication systems must be capable of selecting any of the “new” data-links to be used, depending on flight phase, required services, QoS, etc.

20 Feasibility not yet demonstrated, R&D work being progressed in SESAR Development Phase


Figure 7. Civil-Military Data Link Configuration

42

6.8.4 Civil-Military SATCoM Interoperability

6.8.4.1 HF communications and SATCOM are a recurrent requirement for military aircraft as they need to operate out-of-area21. Military HF and SATCOM resources are used but the support of common infrastructure enablers becomes essential when ATS services are provided by civil ANSPs to State aircraft operating GAT either in Oceanic/remote or in continental airspace.

6.8.4.2 Civil-military interoperability opportunities offered by SATCOM data link developments remain to be fully investigated. Synergy of SATCOM resources used in Oceanic/remote environments with those for continental operations is an obvious move. To join efforts between civil and military users seems another positive step to rationalising the infrastructure, offering benefit of resource pooling. The following civil-military considerations on SATCOM interoperability are seen as relevant: n The potential use of military UHF

SATCOM to support ATS requirements would present a number of complex problems to be overcome. To be approved as an ATS capability, the military SATCOM would have to meet the service and performance requirements in the ICAO SARPS and serious technical limitations would need to be overcome, such as aircraft integration, antennae, ATS data exchange priority, etc.

n This would imply, in part, that UHF SATCOM would have to meet delay recovery time requirements (90 seconds after satellite failure). The demand–assigned multiple access (DAMA) protocols would need to allocate ATS data a higher priority. The UHF SATCOM avionics equipment would need to provide an input to the CMF and would have to be modified to implement current CMF protocols. The effect of added ATS traffic on the UHF SATCOM data link may result in poor performance for both military and ATS data when using this approach. ATS applications would also need to be implemented in avionics systems. A ground entry point into ATN would

need to be implemented in UHF SATCOM ground terminals

n Aiming at future systems, synergies between civil and military SATCOM Programmes could offer significant technology enhancements and low-cost solutions for all users, if civil and military requirements could be considered during all development and standardisation steps. The bottom line is that synergies between civil and military SATCOM programmes remain unexplored, with a some potential for interoperability gains and economies of scale. Nevertheless, it is unlikely that the capacity available and the performance of any military SATCOM system could match that required for ATM. Operated in different radio bands is also a limitation.

n Such serious constraints seem to point to other alternatives for civil-military SATCOM interoperability taking advantage of European SATCOM Programmes promising technology enhancements and low cost solutions.

6.8.4.3 The following recommendations seem appropriate for civi l-mil itar y CNS interoperability initiatives in the area of SATCOM research and/or deployment:n the operation of State aircraft

conducting out-of-area operations (GAT ) in the Oceanic/remote and continental environment require SATCOM communications tailored to sustain voice and data (AOC-alike, CPDLC and ADS-C);

n military UHF SATCOM will not be seen as suitable to sustain ATS provision; and

n future European SATCOM programmes must benefit from technology synergies with military SATCOM programmes.

21 NATO Alliance operations and non-NATO coalition operations in which the United States and other NATO allies participate and that occur outside or on the periphery of Alliance territory.


6.9 Recommendations

The following table summarises the Recommended Implementation Actions and Performance Based Opportunities. The subsequent figure shows the civil-military air/ground communications interoperability roadmap:

Recommended Implementation ActionsAir-Ground Communications

opportunities to reuse capabilities/ lower costs

1 Continue to equip State aircraft with VHF 8.33 kHz radios in line with SES regulations. No, but non-equipped aircraft are accom-modated during a transition period using UHF or 25 kHz

2 Promote retention of UHF provision for ATC. Yes (equipage available)

3 Monitor developments in the area of air-ground digital voice. No (unless available as software defined waveform)

4 Promote accommodation of FANS/ACARS aircraft for CPDLC for an extended period. Yes (equipage available)

5 Equip transport-type State aircraft with ATN/VDL-2 in line with SES regulations. No (new aircraft only)

6 Decide on potential use of ground interfaces to relay ATM information to military contexts, depending on the results of R&D.

Yes (mitigating capability mismatch through ground interface)

7 Plan technology convergence to Future COM solutions (including multilink). No (unless available as software defined waveform)

8 Investigate SATCOM interoperability. Yes (existing equipage)

9 Monitor software-defined radio developments. Yes (synergies with military programmes)

Table 5. Recommended Air-Ground Communications Implementation Actions

44

Civil-Military Ground COM Interoperability Roadmap



Notes:1) EC AGVCS regulations. With transition arrangements and UHF support2) Provided by civil ANSPs for handling non 8.33 State aircraft3) EC DLS Regulation. Transport-type aircraft only. Supported by ATN/OSI with evolution to ATN/IPS4) Depends on R&D results and deployment decisions. Mainly for fighters5) Depends on R&D results. Different approaches for SATCOM, Terrestrial (LDACS) and Airport data link (Wimax). Possible migration to software defined radio.6) Including oceanic/remote communications

Flight Message Transfer Protocol (FMTP)

MFRCR2, ATS/QSIG Voice

UHF for ATC 2)

FANS/ACARS

Future COM Terrestrial 5) (LDACS)

ATN/VDL2 3)

Software Defined Radios

Digital Voice

VHF8.33 kHz 1)

HF Data Link and Current SATCOM 6)

Ground Interfaces for Military Aircraft Accommodation 4)

Future COM Satellite 6) (SATCOM)

Future COM Airport 5) (AeroMACS 802.16)

Figure 8. Air-Ground Communications Roadmap


7 NAVIGATION INTEROPERABILITY

7.1 Navigation Evolutionary Trends

7.1.1 ICAO Global Air Navigation Plan (Document 9750) and Global ATM Operational Concept (Document 9854) [Ref 3] provide the overar-ching framework guiding navigation evolution for civil aviation.

7.1.2 The main trends associated with the evolution of aeronautical navigation are:

n Migration towards satellite-based navigation (and associated multi-constellation, multi-frequency augmentation systems)

n A total RNAV/RNP environment based on the introduction of ICAO Performance Based Navigation (PBN)

n Advent of Trajectory Based Operationsn Evolution of the Navigation Infrastructure

towards a terrestrial PBN support network

7.1.3 Global Navigation Satellite System (GNSS) technology will continue to evidence some vulnerabilities, justifying transitional retention of ground-based terrestrial navigation aids for fallback/backup purposes. For the longer-term future, technology alternatives might have to be considered in accordance with rationalisa-tion plans and the emergence of Alternative Positioning Navigation and Timing (A-PNT).

7.1.4 A SES regulation on PBN will mandate compliance with navigation applications and specifications already defined by ICAO [Ref 22]. These are, to a large extent, equipment-independent and comprise functionality sets and infrastructure enablers that will have to be selected in accordance with local conditions. The impact of such PBN regulation on the mili-tary has yet to be fully determined.

7.2 ICAo Performance based Navigation (PbN)

7.2.1 PbN Concept

7.2.1.1 ICAO’s Performance-based Navigation (PBN) Concept has replaced the RNP Concept; it was introduced through publi-cation of the ICAO PBN Manual (Doc 9613) in 2008. The PBN Concept is geared to respond to airspace requirements. To these ends, ICAO’s PBN concept iden-tifies three components: the NAVAID Infrastructure, Navigation Specification and the Navigation Application.

7.2.1.2 The NAVAID Infrastructure refers to ground- and space-based navigation aids (VOR, NDB, DME, TACAN, ILS, MLS and GNSS).

7.2.1.3 The Navigation Specification is a tech-nical and operational specification that identifies the required functionality of the area navigation equipment and associated aircraft avionics. It also iden-tifies the navigation sensors required to operate using the NAVAID Infrastructure to meet the operational needs identified in the Airspace Concept. The Navigation Specification provides material which States can use as a basis for develo-ping their certification and operational approval documentation.

7.2.1.4 Historically, aircraft navigation specifica-tions have been designed directly in terms of sensors. A navigation specification that includes an additional requirement for on-board navigation performance monito-ring and alerting is referred to as a required navigation performance (RNP) specifi-cation. One not having such additional requirements is referred to as an area navi-gation (RNAV) specification.

46

7.2.1.5 The PBN Manual contains eleven navigation specifications: four of these are RNAV specifications and seven of these are RNP specifications.

7.2.1.6 Advanced RNP and RNP APPCH are specifications created by ICAO that are the subject of the PBN regulatory efforts in Europe. More details can be found in the Glossary – Definitions.

7.2.1.7 The Navigation Application is the use of the NAVAID Infrastructure and Navigation Specification for the design of ATS routes as well as Instrument Approach Procedures.

7.2.1.8 The ICAO Resolution at the 36th Assembly reflects international concordance as to highlevel goals and ambitions for global uptake of PBN. It states that where RNAV operations are required, enroute (oceanic and continental) and terminal ATS routes should be implemented according to PBN and that all instrument runway ends should have an approach procedure with vertical guidance (APV), either as the primary approach or as a back-up for precision approaches.

7.2.1.9 The PBN concept itself specifies that aircraft RNAV and RNP system performance requirements be defined in terms of the accuracy, integrity, continuity and

functionality, which are needed for the proposed operations in the context of a particular airspace concept.

7.2.1.10 The PBN concept represents a shift from sensor-based to performance-based navigation. Performance requirements are identified in the before mentioned navigation specifications, which also identify the choice of navigation sensors and equipment that may be used to meet the performance requirements. These navigation specifications are defined at a sufficient level of detail to facilitate global harmonization by providing specific implementation guidance for States and operators.

7.2.1.11 PBN requirements also depend on what reversionary, conventional navigation techniques are available and what degree of redundancy is required to ensure adequate continuity of functions.

7.2.1.12 It is to be noted that PBN Concept doesn’t cover the precision approach and landing operations. In fact, precision approach and landing systems such as the Instrument Landing System (ILS), Microwave Landing System (MLS) and GNSS Landing System (GLS) form part of the navigation suite, but are not included within the concept of PBN. They differ from PBN applications because they are not based on area navigation techniques.

7.2.1.13 As part of the future work of ICAO, it is anticipated that other means for meeting the requirements of the navigation specifications will be evaluated and may be included in navigation specifications, as appropriate.

7.2.1.14 The PBN concept offers unique grounds for civil-military navigation interoperability. Military-specific NAV system configurations will have to be seen from a performance based perspective and fully taken onboard in future navigation specifications. In summary, the future work of ICAO is expected to take due account of particular military requirements but the military are expected to fully adhere to PBN requirements, where possible with sufficient lead times to enable the transition of legacy fleets.

NavigationApplication

NavigationSpecification

NAVAIDInfrastructure

RNAV RNP

Figure 9. PbN Concept


7.2.2 PbN Regulation

7.2.2.1 A SES regulatory mandate was issued for EUROCONTROL to assist the European Commission in the development of an implementing rule on PBN. This rule addresses ICAO Resolution A37-11, identifies safety areas where EASA support is needed and defines PBN navigation requirements, identifying the functionalities required in en-route and terminal airspace, including arrival, departure, and approach phases of flight. Take-off and landing is outside the scope of PBN.

7.2.2.2 The main objective of the rule on PBN is to ensure that navigation capability improvements are introduced in EATMN in an optimal and coherent way, through d e f i n e d n av i g a t i o n p e r fo r m a n ce requirements and functionalities with a view to meeting European network performance targets and optimising other operational, environmental and implementation factors, whilst ensuring global interoperability. The following specific objectives have been considered for the development of the draft PBN IR:n Ensure optimal use of airspace through

the improved design of the ATS route structure based on common navigation performance requirements and functionalities in en-route airspace by 2020;

n Increase access to airports through the introduction of arrival and departure routes and approach procedures based on common navigation performance requirements and functionalities in terminal airspace by 2020;

n Reduce CFIT by the full deployment of approaches with vertical guidance;

n Maximise the use of RNAV approaches in terrain-rich environments as well as in noise-sensitive areas across Europe;

n Maximise horizontal and vertical flight efficiency across Europe;

n Enable initial decommissioning or non-replacement of conventional navigation aids;

n Introduce new requirements in a manner which minimises operators’ certification and approval costs;

n Facilitate the transition to the SESAR TBO concept through the introduction of functional requirements and procedures by 2025;

n Ensure harmonised PBN operations in en-route airspace and in TMAs.

7.2.2.3 The PBN IR will identify the navigation performance and functionality22 requirements that apply to onboard systems, the requirements applying to the ground/space based navigation systems and to ATM systems components to support PBN implementation (not decided at time of drafting). It defines airspace applicability, applicability dates for implementation and transitional arrangements for legacy equipment. Safety requirements and conformity assessment will be established subsequently, through the EASA regulatory structure.

7.2.2.4 The PBN IR will mandate performance based navigation capabilities selected from the ICAO document 9613 (PBN Manual), Volume II – Implementing RNAV and RNP Operations. Different sets of capabilities/functionalities (e.g. advanced RNP, RNP-1, RNP APPCH operations down to LNAV and LNAV/VNAV minima or to LP and LPV minima, Radius To Fix – RF, Path Terminator, Barometric VNAV (BARO-VNAV), RNAV Holding, Fixed Radius Transition - FRT) will be mandated for commercial and non-commercial air transport and for terminal/approach and en-route operations. One specific article will be included in the IR with provisions on State aircraft.

7.2.3 Airborne Equipage Impact

7.2.3.1 The airborne equipment for civil aircraft must comply with European Standards, (where no European standards exist, RTCA standards may be used) as follows: The PBN navigation functional requirements have to be demonstrated against ED-75B/DO-236B, Minimum Aviation System Performance S t a n d a r d s : R e q u i r e d N a v i g a t i o n Performance for Area Navigation.

7.2.3.2 Furthermore, VNAV capability will have to be demonstrated against the following standards:

22 Such functionalities identified in the Advanced RNP and RNP APCH packages may comprise, inter alia, scalable required navigation perfor-mance (RNP), radius to fix (RF), fixed radius transition (FRT), airspace holding, required time of arrival (RTA), vertical navigation path (VNAV Path), tactical parallel offset, GNSS positioning inherent in RNP APCH, Vertical Navigation (VNAV) using either Barometric altimetry or SBAS aiding of GNSS, etc.

48

n FAA TSO-C106 (Air Data Computer);n Air Data System (see references in PBN

Manual);n Barometric altimeter system (see

references in PBN Manual);n Type certified integrated systems

providing an Air Data System capability.7.2.3.3 For the GPS equipment, Acceptable Means

of Compliance (AMC) are provided by ETSO-C129 Airborne Supplemental Navigation Equipment Using Global Positioning System (GPS), requiring compliance with ED-72A - MOPS for Airborne GPS Receiving Equipment used for Supplemental Means of Navigation. ED-72A specifies the equipment performance and the test methods used for verifying performance in simulated operating conditions, in environmental conditions, and after installation in an aircraft. The GPS receiver can be used either as stand-alone equipment or as a sensor input to an area navigation (RNAV) system.

7.2.3.4 For SBAS equipment, compliance is determined against:n ETSO-C145c Airborne Navigation

Sensors Using the Global Positioning System Augmented by the Satellite Based Augmentation System; or

n ETSO-C146c Stand Alone Airborne Navigation Equipment Using the Global Positioning System Augmented by the Satellite Based Augmentation System.

Both ETSOs are requiring compliance with RTCA DO229 D.

7.2.3.5 As PBN operations rely on Navigation Data Base information, the following technical standards apply:n E D -76/DO -200A S tan dards for

Processing Aeronautical Data;n E D -77/DO -201A S tan dards for

Aeronautical Information;n ARINC 424 Navigation System Data

Base;n RTCA DO-200A/EUROCAE document

ED 76, Standards for Processing Aeronautical Data.

7.2.3.6 The above-mentioned aircraft equipage technical requirements as stipulated without prejudice to alternative equipment enablers capable of offering equivalent performance levels23 when State aircraft compliance is sought.

7.3 EuRoCoNTRoL Navigation Roadmap

7.3.1 The EUROCONTROL Navigation Roadmap24 recognises the emergence of satellite technology in the global navigation environment. However, the rate of technological development and available aircraft equipage dictates the need for a complementary ground-based back-up infrastructure (eg DME/DME plus TACAN for the military).

7.3.2 The baseline situation in the short term and its expected evolution comprises:

7.3.2.1 En-route operations - the carriage of B-RNAV (RNAV 5 equivalent) was introduced above FL 9525 for en-route IFR operations in ECAC airspace for civil aircraft operators. State aircraft are exempt in accordance with ICAO document 7030.

B-RNAV applications will be maintained until the Navaid infrastructure and aircraft capabilities can enable implementation of PBN’s Advanced RNP (A-RNP).

7.3.2.2 Terminal operations - P-RNAV (RNAV 1 equivalent) was implemented in some ECAC TMAs to support arrival and departure operations. P-RNAV applications replace existing conventional and B-RNAV procedures until the navigation infrastructure and aircraft capabilities can enable implementation of A-RNP applications.

7.3.2.3 Approach Operations - Conventional Non-Precision Approaches (NPA) are available at most airports in the ECAC area and are still the main backup for

23 RNP 1 operations require aircraft conformance to a track-keeping accuracy of +/- 1NM for at least 95% of flight time, together with monitor-ing and alerting functionality and high integrity navigation databases. For RNP APCH, as defined in the EASA AMC 20-27, the Lateral and Longitudinal Total System Error (TSE) of the onboard navigation system must be equal to or better than: a) ±1 NM for 95% of the flight time for the initial and intermediate approach segments and for the RNAV missed approach; b) ±0.3 NM for 95% of the flight time for the final approach segment.

RNP 1 as well as RNP APCH capability require inputs from GNSS. Many existing aircraft can achieve P-RNP 1 capability without additional on-board equipment. Vertical navigation in support of APV can be provided by GNSS SBAS or by barometric altitude sensors.

24 Once endorsed by the EUROCONTROL Navigation Steering group (NSG), consult also the EUROCONTROL Navigation Strategy and PBN Action Plan

25 In lower airspace, national authorities may designate domestic ATS routes which can be used by aircraft that are not B-RNAV capable


ILS Precision Approaches. Some RNP Approaches (LNAV and LNAV/VNAV) have already been implemented at several airports and more implementations are in progress.

RNP Approaches based on the use of GPS/GNSS will be gradually implemented to replace existing conventional NPA or provide IFR approach procedures at airports where the ground infrastructure does not support conventional NPA procedures.

APV approaches26 are procedures designed to make use of both lateral and vertical guidance, to provide better access to airports, increased safety and better route design. APV operations can be based on Barometric VNAV (Baro-VNAV) or Space-Based Augmentation System (SBAS) (enabled in Europe by EGNOS).

GBAS standards and systems can also offer APV service levels, even if currently not used in civil applications.

7.3.2.4 Precision Approach and Landing Operations - ILS systems provide a very efficient service for precision approach and landing operations. However, ILS systems can only support straight-in approaches, limit the traffic handling capacity of runways under low visibility conditions due to sensitive protection areas and are facing problems in terms of multi-path effects and radio spectrum constraints.

MLS systems have a limited deployment but offer a number of operational and technical advantages over ILS, including much better radio interference immunity, and much smaller sensitive areas. MLS is still seen as an alternative solution where ILS Cat III level of service cannot be achieved or maintained.

Some Ground-Based Augmentation System (GBAS) CAT I ground stations have already been installed in ECAC countries. New civil aircraft from Airbus and Boeing are currently being are currently being fitted with GBAS capability (no regional aircraft manufacturers are offering this capability - first systems are in development).

GBAS has the capability to provide increased capacity by supporting more advanced operations such as seamless flexible and high-performance RNP approaches, multiple approaches to a single runway, closely spaced parallel approach, flexibility of airport runways by enabling precision approach at all runway ends simultaneously and airport throughput during low visibility operations.

The implementation of GBAS will not see a rapid replacement of ILS. The EUROCONTROL policy on GBAS is to support a progressive, harmonised and cost-effective transition towards GBAS across ECAC by supporting the development of the abovementioned enablers.

GBAS Cat I stations are considered to be an interim step towards the development of GBAS Cat II/III stations. Current developments at technical and standardisation level are aimed at achieving Cat II/III capabilities based on GPS with only one frequency (L1). Operational approval for CAT III GBAS depends on subsequent rulemaking.

7.4 EuRoCoNTRoL Global Navigation Satellite Service (GNSS) Policy

7.4.1 The EUROCONTROL Policy on GNSS [Ref 23]27 is based on a gradual increase in reliance on satellite navigation. User receivers will be able to process signals from different GNSS constellations in combination with augmentations (e.g. ABAS28, GBAS or SBAS depending on individual business cases and the phase of flight).

7.4.2 Today, GPS offers a very efficient service and, with adequate augmentation, it is being used as a positioning source for B-RNAV, NPAs and RNAV approaches. Around 70 % of the flights within ECAC are conducted by aircraft equipped with GPS.

7.4.3 However, GPS has some vulnerabilities limiting its exclusive use in aviation (e.g.

26 The Implementing Rule for Performance Based Navigation will also cover the requirement for all instrument runway ends to have an ap-proach procedure with vertical guidance (APV), either as the primary approach or as a back-up for precision approaches. There is a need to envisage particular provisions to cope with a longer transitional accommodation of State aircraft with a capability mismatch.

27 Once endorsed by the EUROCONTROL Navigation Steering group (NSG), consult also the EUROCONTROL Navigation Strategy and PBN Action Plan

28 Aircraft-Based Augmentation System (ABAS). An augmentation system that augments and/or integrates the information obtained from the other GNSS elements with information available on board the aircraft. Note. - The most common form of ABAS is receiver autonomous integrity monitoring (RAIM)

50

radio interference and space weather). The expected GNSS developments (e.g. more constellations like GLONASS or GALILEO and more powerful signals in more frequency bands) will overcome most of the current GNSS vulnerabilities, enabling the provision of enhanced positioning services for all phases of flight, for ground movements at airports and for ADS-B applications. There is no GNSS solution that fits all users and all ANSPs. Each aviation stakeholder will choose the GNSS solution that meets operational and safety requirements in the most cost-effective way.

7.4.4 The EUROCONTROL GNSS policy envisages, for en-route and terminal areas, a total PBN environment based on a GNSS service enhanced at aircraft level (i.e. ABAS based on inertial coupling and/or RAIM alerting functionality). Individual business cases will determine the most adequate solution for each stakeholder. A reversion based on an optimised terrestrial navigation network will be needed to overcome the remaining GNSS vulnerabilities, even in the long term.

7.4.5 Once enhanced GPS and GALILEO become available, GBAS will increasingly support CAT II/III operations where economically beneficial. Even if ILS remains the primary source of guidance for CAT I/II/III operations in major airports, it is assumed that all GBAS for CAT I stations will be upgraded to CATII/III stations.

7.4.6 The European Geostationary Navigation Overlay System (EGNOS) will enable SBAS and is expected to provide operational benefits to different categories of airspace users (e.g. general aviation, helicopters, business jets, regional airlines, the military) offering a cost-effective option to meet some of the PBN requirements and supporting LPV operations at runways not equipped with ILS.

7.4.7 EGNOS has a higher capability to reduce minima than BaroVNAV. EGNOS is expected to provide 250 ft minima and an ILS look-alike approach capability on most European runways. In a second step it is expected to evolve toward a Cat I capability (200 ft minima). Individual business cases will determine the suitability of EGNOS for each aviation stakeholder.

7.4.8 As a function of GALILEO’s availability, aviation will use its signals in combination with other constellations like GPS, and augmentations as appropriate. However, standardisation fora (e.g. ICAO, EUROCAE) have, however, indicated that

combined constellation receivers should avoid unnecessary complexity, which would increase costs in avionics design, testing and installation. In this respect, it is assumed that at least the first generation of combined constellation receivers will be limited to dual constellation receivers (e.g. GPS and GALILEO).

7.5 Navigation Infrastructure Rationalisation29

7.5.1 The evolution described above will lead to a rationalisation of the navigation infrastructure to include:

n A GNSS service provided by enhanced GPS, GALILEO30 and GLONASS in accordance with availability of constellations.

n A terrestrial back-up, to cater for GNSS signal vulnerabilities, based mainly on DME (TACAN for the military) and ILS (MLS where feasible) until beyond 2020; Alternative Positioning Navigation and Timing (A-PNT) may be introduced later. An initial proposal is under discussion to introduce a new SSR/Mode N system to provide navigation service by replacing DME and TACAN.

n European SBAS system (EGNOS), available today, with performance level to allow for LPV operations.

n The implementation of new RNAV applications and a progressive reduction of conventional routes and procedures will enable a gradual removal of some NDB and VOR systems so that redundancies are eliminated. Nevertheless, a residual number of VORs will be retained for a longer period, to cope with local requirements of General Aviation (GA) and military in smaller aerodromes.

n A reduction of the ILS Cat I infrastructure may occur, especially for ILS at the end of operational life in airports with low levels of traffic (replacement by APV). For major airports, ILS Cat II/III is expected to remain the main precision approach and landing system over the next 20 years.

For Cat II/III operations, MLS may be introduced at certain runway ends, when an alternative option to ILS is required.

GBAS Cat I and SBAS/EGNOS operations will be implemented at an increasing number of

29 Once endorsed by the EUROCONTROL Navigation Steering group (NSG), consult also the EUROCONTROL Strategic Guidance on Evolution of Conventional Navigation Aids

30 GALILEO and GPS L5 signals are to become operational before 2020.


airports during Step 1, as an alternative to ILS Cat I.

GBAS Cat II/III will become available in the medium term, but widespread deployment is beyond the Step 1 timeframe.

7.6 Civil-Military Navigation Interoperability

7.6.1 baseline Situation

7.6.1.1 The current civil navigation arrangements for the handling of State aircraft operating as GAT can be summarised as follows:n State aircraft are exempted from

B-RNAV (RNAV-5) requirement [Ref. 24]. For en-route GAT, State aircraft should be routed via VOR/DME-defined ATS routes or via conventional navigation aids (national AIPs). Within TMAs, non B-RNAV State aircraft should be routed via non-RNAV-based SIDs and STARs.

n For terminal operations State aircraft that are not approved for P-RNAV (RNAV-1) operations may continue to make use of conventional procedures, as stated in national AIPs.

n State aircraft without the required vertical navigation capability (SBAS, LNAV and LNAV/VNAV) to perform RNAV approaches based on the use of GPS/GNSS, will continue to use existing conventional non-precision approaches.

n Concerning precision approach and landing operations, in parallel with the introduction of GBAS, State aircraft with lower NAV capability will continue to be accommodated on the basis of conventional means and/or special handling procedures. Until at least 2020 and beyond, military operations will rely on the use of ILS, MLS and Differential GPS31 systems available in Multi Mode Receivers (MMR).

n It is assumed that the minimum Precision Approach and Landing System (PALS) requirement for military operations is Cat I. Therefore, Cat II/III should be seen as recommended/optional for transport type State aircraft, not being critical in terms

of airport access (depending on the airfields into which they operate).

7.6.2 overall Impact from Navigation Improvements

7.6.2.1 Starting from the baseline described above, subsequent navigation developments, plans and policies (predominantly civil) will increase the complexity of mixed-mode operations, triggering the need for additional civil-military navigation interoperability efforts.

7.6.2.2 Those efforts will be particularly important to continue to accommodate legacy State aircraft evidencing limited equipage levels. A very complex and difficult challenge will be to determine processes and solutions leading to some State aircraft capabilities being declared as equivalent to the functionalities envisaged in advanced navigation applications as an option to overcome military equipage mismatches.

7.6.3 Performance-based Navigation (PbN) Impact on Military operators

7.6.3.1 When considering the specifications introduced by PBN the vast majority of State aircraft evidence technical shortcomings and certification issues that can be summarised as follows:n The PBN Manual limits the eligible

sensors to those mainly used by civil aviation

n On many military aircraft the absence of navigation database (ARINC 424) is identified as the first major difficulty

n Compliance of military navigation computers with ARINC 424 path terminators and flight plan management are a problem

n There are l imitat ions due to old-generation cockpit display systems.

n The functions required by future A-RNP like VNAV and RTA are a concern.

7.6.3.2 The PBN Regulation will impact the military in many ways depending on the regulatory provisions finally agreed. In the framework of Phase I of the regulatory mandate on PBN, EUROCONTROL has developed a “Preliminary Impact Assessment on Civil-Military Organisation”, coordinated with

31 Differential GPS is based on STANAG 4550 which is consistent with the ICAO document defining GBAS. There are some inconsistencies of antenna polarization (elliptical vs. horizontal) but we expect that JPALS concept can take GBAS onboard on the basis of DGPS already avail-able in MMRs

52

the States represented, which identifies the following aspects that have to be considered to limit military impact:n There is a need to avoid regulatory

measures that are too prescriptive for State aircraft

n There is a need to acknowledge that many legacy State aircraft will never be PBN compliant

n Transitional arrangements are required to handle non-equipped or lower capability aircraft

n Performance-driven compliance using equivalent capability is a key approach for State aircraft and shall be applicable to all aircraft types

n There is a trend for the military to apply a “Minimum Regulatory Coverage”,option, due to increasing budgetary constraints.

7.6.3.3 The PBN regulatory provisions were not available at time of drafting but they will likely impact only new transport-type State aircraft (entering into service or suffering major mid-life overhauls) which may be the subject of forward fit actions to acquire RNP-1 and vertical navigation capabilities (VNAV, APV and LNAV). The specific PBN IR article on State aircraft is expected to include a similar approach as in the DLS regulation 29/2009.

7.6.3.4 Aspects under consideration are the need for the IR to comprise 1) forward fit provisions for new transport-type State aircraft operating as GAT/IFR, allowing sufficient transitional lead times to equip (at least 5 years more than for civil aircraft) 2) reversionary arrangements ensured by ATS providers to accommodate non-equipped aircraft and 3) opportunities for performance based utilization of military navigation capabilities as equivalent means of compliance (including for non-transport military aircraft), to be validated through national certification processes.

7.6.3.5 In particular States, depending of local plans, ICAO PBN has the potential to impact various fleets (fighter, transport type and helicopter). Fighter aircraft would require an extended navigation database and a GNSS approach capability (APV) if required to land on civil airports. This approach capability does not exist at the moment for GPS PPS equipped aircraft. A potentially

costly research and development phase would have to be launched. Transport-type State aircraft (even if exempted from PBN functionalities) will also need an extended database and a GNSS approach capability (APV). For those aircraft, COTS solutions exist. New transport-type State aircraft whose initial contract will be passed after a due date will have to be equipped with some of the functionalities mandated for commercial aircraft. The «do nothing scenario» seems not appropriate as at a minimum, an extended database will be required for all aircraft to fly between geodesic waypoints when VOR and NDB will be decommissioned. GNSS approaches will also be needed for most of the fleets to access civilian airfields where ILS cat I will be removed. As stated before, note that non-area navigation concepts like ILS are outside the scope of PBN as defined by ICAO.

7.6.3.6 More demanding PBN regulatory options will not be applicable to State aircraft even when introducing other functionalities that are key to enable more advanced 4D concepts, as it is the case with the ability to meet time constraints (RTA). Those capabilities should not be mandated for State aircraft and can remain only as a voluntary option.

7.6.3.7 It is expected that PBN deployment will bring a greater focus on processes for verification of compliance for State aircraft and military authorisations. The bottom line will be that the majority of State aircraft will remain in operation without the required PBN capabilities and will still need to be handled on the basis of conventional support for a certain transition period. This does not apply to a smaller number of forward fit actions for transport-type aircraft entering into service or undergoing major mid-life upgrades for compliance with certain basic PBN functionalities.

7.6.4 State Aircraft Airborne Equipage Considerations for PbN

7.6.4.1 Without prejudice to per formance equivalence, as described above, equipage decisions for State aircraft operating GAT in the en-route and terminal approach continental environment must base PBN


aircraft and system requirements on the ICAO PBN Manual for the relevant application.

7.6.4.2 PBN equipage for transport-type State aircraft will be selected depending on the applications required32 and are recommended to comprise, as a minimum: RNP-1 for Advanced-RNP (plus selected functionalities), eligible sensors (DME/DME, VOR/DME, GNSS (part of MMR), SBAS receiver, INS), RNAV Computer with RAIM connected to FMS/MMS and displays, Air Data Computer (with GNSS updates), Data Base ARINC 424 Path Terminators, APV with barometric VNAV with FMS/MMS, or LPV using SBAS/EGNOS receiver, connection to flight guidance, flight control, autothrottle/pilot/flight director and Multi Function Control Displays.

7.6.5 GNSS Policy Impact on Military operators

7.6.5.1 As described above, the civil strategies and plans for the evolution of navigation structures assume that, alongside GPS, GALILEO will become available. Considering that a majority of State aircraft are already using the GPS Precise Positioning Service (PPS), it seems appropriate that such already available restricted signals capability should be evaluated as a candidate means of compliance for operations in a mixed-mode environment. In addition, military authorities will discuss whether the GALILEO Public Regulated Service (PRS) can be considered as a complementary capability for the European military community33.

7.6.5.2 The emerging GNSS governmental services (GPS M-Code and GALILEO PRS) offer a real opportunity to lay new foundations for GNSS use by State aircraft, providing full interoperability with civil aviation. This opportunity lies in the assumption that military restricted signals will be demonstrated34 as capable of offering an equivalent level of performance when compared with civil counterparts.

7.6.5.3 Processing the GPS PPS (and/or GALILEO PRS) signals, as well as standard signals, through a combined receiver would ensure

the consistency of State aircraft equipage, facilitating the airworthiness certification process and avionics integration. This scheme would reduce costs drastically and would alleviate concerns related to the lack of cockpit space and retrofit constraints. Additionally, this avionics architecture would be an important step towards a multimode GNSS receiver able to meet certification requirements from both civil and military bodies.

7.6.5.4 The long-term goal is to reach a high level of convergence between civil and military aeronautical navigation solutions. Although military operational requirements with regard to positioning, navigation and timing have been already met, the increasing influence of civil navigation requirements need to be taken into account when State aircraft fly GAT/IFR in controlled airspace.

7.6.6 Navigation Infrastructure Rationalisation Impact on Military organisations

7.6.6.1 Military aircraft in any kind of operation must be able to operate in all-weather conditions, day or night. This capability must be effective when flying at low level, with or without the support of ground-based navigation aids, within civil-controlled airspace, at civil airfields and even when conducting military training in parallel with civil traffic.

7.6.6.2 Taking due account of known military plans, the navigation infrastructure evolution is expected to take place as follows:

NDb/VoRn NDBs and VORs will be gradually

removed, from circa 2015, in line with civil plans

n A residual number of VORs will be retained to support local operations in the vicinity of military aerodromes and to cope with limited airborne equipage.

TACANn TACAN will be required until at least

2025 even if a gradual introduction of GNSS/INS alternatives starts earlier. Retention of TACAN for en-route navigation by military aircraft should

32 For any particular PBN operation, it is possible that a sequence of RNAV and RNP applications is used. A flight may commence in an airspace using a Basic RNP 1 SID, transit through En Route then Oceanic airspace requiring RNAV 2 and RNP 4, respectively, and culminate with Ter-minal and Approach operations requiring Advanced RNP 1 and RNP AR APCH.

33 Significant work is still needed at national level to define the required processes. More R&D may also be needed.34 Through national processes

54

continue to be supported on the basis of economic, spectrum and equipage risks presented by alternative technologies. Unti l a l ternative consolidated navigational equipment is in place, a minimum TACAN route structure is expected to be retained.

n In the context of ATM, TACAN (for the military) should be used during transition, as a GNSS backup, when/if offering similar function as DME offers for civil airspace users.

n TACAN is often colocated with civil VOR stations (VORTAC facilities). At VORTAC facilities, the DME portion of the TACAN is available for civil use.

n The DME component of TACAN (range) offers value and compatibility for civilian aircraft operations. There may be a civil requirement for the use of DME components of TACAN as contingency for rationalisation of civilian ground-based navigation facilities. TACAN may also supplement civil DME coverage, if ICAO compliance is demonstrated and synergies are created. Some ANSPs have already considered this option.

n The NATO Position on Future Use of TACAN its described in document AC/92-D(2011)0005, 23 June 2011 [Ref. 25].

PARn At most military airfields, approach and

landing operations are supported by a Ground Controlled Approach (GCA)/Precision Approach Radar (PAR). PAR works independent of aircraft avionics and is human-operated. In some states, PAR installations are reaching end-of-life and a replacement needs to be considered in due course.

n PAR capability needs to be sustained until at least the arrival of an alternative concept after the PALS35 transition (around 2020). In this period, Multi Mode Receiver integration in some military aircraft will still be ongoing in order to fulfil interoperability requirements.

n There are some national military plans to modernise PARs or to replace them by ILS or even MLS; implementation decisions will be taken by individual

States. The options that will best converge with civil trends would be GPS Landing Systems, ICAO Ground–Based Augmentation Systems (GBAS) or aircraft-based means (e.g. EGNOS/SBAS).

ILS/MLSn ILS (and MLS in some locations) will be

retained beyond 2020 as it serves as a reversionary support/back up to GBAS

n Military requirements will be supported by the introduction of a JPALS/PALS concept, considering the availability of Multi-Mode Receiver (MMR), which includes ILS, MLS and DGPS capabilities. The main driver of future (military) PALS will be the need for commonality with a civil satellite-based GNSS infrastructure. There is an expectation that the foreseeable evolution in the civil aviation community towards GNSS and augmentations will influence the technology selected for PALS.

n As ILS starts to be replaced by GBAS at certain major civil airports, it is expected that military PALS will take due account of the fact that GBAS, as defined by ICAO, will become the main technical solution for precision landing. Nevertheless, military operations require the retention of ILS capability even for the very long term and civil planners must be encouraged to continue to offer fall-back alternatives until complete convergence is met. It may happen that some particular States take different decisions and decide to be more restrictive. For those cases, an adequate level of civil-military coordination is essential.

n Standardisation developments might be required to ensure compatibility between military GPS (DGPS) receivers defined in NATO STANAG 4550 and civil GBAS. It is important to note that DGPS may not be useable in aerodromes where APV/LPV is required.

n Ideally the airborne self-contained NAV avionics will evolve to sustain landing requirements of military aircraft. These avionics might typically include Inertial Navigation System (INS) with GPS (later GNSS) updates to support pilots with

35 Refers to the “Military Operational Requirement on Future NATO Precision Approach and Landing Systems (PALS)” and NATO STANAG 4533 “PALS Transition Strategy” where compatibility of PALS will be decided to allow civil aircraft to land at military airfields and military aircraft to land at civil airfields. Concept also described as JPALS (Joint).


positioning and bearing information as well as for approach and landing. SBAS is expected to be useable for Cat I in the medium term.

7.6.7 Navigation Interoperability opportunities

7.6.7.1 The future evolution of navigation technologies will likely emerge from cross-fertilisation and progressive integration with communications and surveillance enablers. One domain which may offer significant opportunities is the use of data link technologies to support navigation applications, as is currently the case with relative navigation function using a geodetic grid included in military data link terminals.

7.6.7.2 Another domain which may be of crucial importance for military aircraft showing integration constraints is the emergence of low-cost inertial technologies and its gradual integration into lighter and more portable configurations (e.g. MEMS).

7.6.7.3 The utilisation of SBAS (EGNOS/WAAS) is also an open door to offer performance levels to military aircraft to sustain required vertical guidance. The emergence of a military JPALS concept will be a cornerstone to define the approach and landing requirements for State aircraft.

7.6.7.4 In terms of terrestrial infrastructure, consideration of TACAN as an important contributor to the rationalisation plans complementing the coverage of available DMEs is an important subject to be further progressed. Another important area is the evaluations to be made of Alternative Positioning Navigation and Timing (A-PNT) technical options to mitigate the lack of DME coverage and deconflict with other systems to be operated in the same spectrum band (960-1215 MHz).

7.6.7.5 It is important to assess State aircraft compliance with RNP requirements, where applicable, with a thorough assessment of the associated alerting/containment integrity requirements. This normally entails a RAIM (Receiver Autonomous Integrity Monitoring) capability which may be available in multiple military aircraft but not properly harmonised in line with adequate specifications.

7.6.8 Navigation Support to 4D Trajectory Management

7.6.8.1 In the light of trajectory management aspects resulting from SESAR advanced concepts, one aspect of utmost importance is linking navigation capabilities and performance with 4D trajectory concepts. In this area it is important to discuss not only the vertical, horizontal and longitudinal performances and containment functions but also time management in relation to flight guidance/control capabilities and the reliance on data bases and flight management system automation. The business/mission trajectories will be described as well as executed with the required precision in all 4 dimensions.

7.6.8.2 Trajectory management functions entail the understanding that navigation functions have to be seen from a holistic perspective and considered as a merging of multiple performance components, in space and in time, and involve an assembly of applications, sensors, airborne computers and data bases, together with data link interactions.

7.6.8.3 Trajectory-related applications should be sensor-independent and some tailored requirements or alternative mitigation of missing capabilities might be necessary due to certain on-board capability constraints. The usual limitation on military aircraft is the mismatch of navigation data bases, which may require translation using a ground-based mission support system as well as difficulties associated with supporting ARINC 424 formats, vertical navigation and RTA capability.

7.6.8.4 The use of Military Mission Systems (MMS) /Mission Computers to emulate FMS functions is still dependent on the results of ongoing SESAR R&D efforts. Hence, the options for acquiring onboard automated trajectory management functions in military aircraft remain uncertain. Aircraft system aspects relating to 4D trajectory requirements are further expanded in [Ref. 37, 38].

56

7.7 Recommendations

The following table summarises European-orientated Recommended Implementation Actions and Performance Based Opportunities. The subsequent figure shows the civil-military navigation interoperability roadmap:

Recommended Implementation ActionsNavigation


1 Consider the use of TACAN, during a transition, as a GNSS backup when matching airborne fitting in the same way as DME does for civil airspace users. Consider TACAN in navigation infrastructure rationalisation actions.

Yes (synergies with military programmes

2 Consider for new transport-type State aircraft the RNP-1 and VNAV capabilities in line with SES regulation (PBN). Select technical requirements from the ICAO PBN manual (doc 9613).

No

3 Promote accommodation of other types of State aircraft on the basis that it has been demonstrated that available military systems can cope with required performance levels meeting PBN requirements.

Yes (reutilization of TACAN, GPS/PPS, INS and other military enablers)

4 Promote retention of conventional navigation support for non-equipped State aircraft as needed.

Yes (Infrastructure and equipage in place)

5 Seek compatibility between military JPALS and civil GBAS standards. Not applicable

6 Equip State aircraft with solutions for approach and landing compatible with GBAS Cat I when possible. (When this is found premature or too difficult, investigate other alternatives for Cat I, potentially SBAS)

Yes (reutilising DGPS)

7 Plan the voluntary introduction of 4D Trajectory capabilities (RTA, FMS, Data Bases, etc.).

Yes (reutilising MMS/Mission Computers)

8 Promote the recognition of GPS Precise Positioning Service (PPS) and GALILEO Public regulated Service (PRS) as means of compliance for GNSS navigation.

Yes (existing GPS equipage)

9 Consider voluntary equipage of transport type State aircraft with more recent ACAS/TCAS versions

No

Table 6. Recommended Navigation Implementation Actions


Civil-Military Navigation Interoperability Roadmap - Applications



Notes:1) In accordance with the PBN Regulation and using the A-RNP functionalities selected to be subject of regulatory coverage. This will likely include functionalities like RNP-1, and Vertical Navigation (VNAV). Alternative performance equivalence accepted2) In accordance with the PBN Regulation with LNAV kept as a backup of APV. Lower minima may be considered. Alternative performance equivalence accepted.3) GBAS also sometimes referred to as GPS Landing System (GLS).4) Not a civil-military interoperability requirement as Cat I suffices. It may be voluntarily adopted for transport-type aircraft that need to operate in major civil airports.

GBAS (Cat II/III) GPS 4)

Conventional: En-Route, Terminal Ops and Non Precision Approaches ((VOR/NDB)

B-RNAV for En-Route and Terminal

P-RNAV for En-Route and Terminal

Advanced RNP 1)

ILS/MLS (All Categories)

GBAS (Cat I)

RNAV NPA (LNAV)

RNP APPCH (LNAV +APV Baro or APV SBAS) 1) 2)

GBAS (Cat II/III) GNSS 4)

Figure 10. Civil-Military Navigation Interoperability Roadmap - Applications

58

Civil-Military Navigation Interoperability Roadmap - Infrastructure



Notes:1) Residual number of VOR retained to cope with local military aerodrome operations and aircraft with limited equipage.2) Depending on military TACAN plans. Used to complement DME coverage and required to mitigate non-availability of DME/DME capability. Supporting additional military requirements (OAT).3) And possibly WAAS.4) In compliance with airborne Multi Mode Receivers (MMR) and JPALS concept.5) Dependent on R&D

B-RNAV for En-Route and Terminal

P-RNAV for En-Route and Terminal

Advanced RNP 1)

MLS 4)

ILS 4)

GPS/GBAS 4)

NDB

VOR 1)

DMETACAN (for the Military) 2)

GPS/SBAS (EGNOS) 3)

GPS and GLONASS

Trajectory Functions (FMS/MMSwith data base) 5)

Use of GPS/PPS

GALILEO Use of GALILEO/PRS

GBAS Multiconstellation

Figure 11. Civil-Military Navigation Interoperability Roadmap - Infrastructure


8 SURVEILLANCE INTEROPERABILITY

8.1 Surveillance Evolutionary Trends

8.1.1 The EATMN surveillance system must provide updated aircraft identification, position and other information in order to enable safe and efficient ATM network. The surveillance system should support users in selecting the preferred en-route flight path allowing appropriate separation in a defined volume of airspace.

8.1.2 Sur vei l lance provision comprises the availability of ground sensors and surveillance data processing and distribution systems, which support 3-mile and 5-mile separation requirements. Future airborne surveillance requirements will essentially be linked with the ability to extract the avionics parameters required to support applications36, normally standardised by EUROCAE/RTCA, and to broadcast and receive such information. Surveillance fusion and sharing is increasingly being developed and is used almost everywhere.

8.1.3 The current surveillance infrastructure is mainly composed of Secondary Surveillance Radar (SSR), Mono-pulse Secondary Surveillance Radar (MSSR), MSSR Mode-S and Primary Surveillance Radar (PSR). Recent technological developments such as the emergence of Automatic Dependent Surveillance–Broadcast (ADS-B) and Wide-Area Multilateration (WAM) have reached maturity and are being deployed in many parts of the world including Europe. EATMN will be supported by a mix of surveillance techniques.

8.1.4 Surveillance systems are expected to make possible a more aircraft-centric and collaborative ATM network in the future, combining a layer of ADS-B with a layer of secondary surveillance (provided SSR/MSSR, MSSR Mode S or WAM). Primary radar coverage will also be available, where required (e.g. for safety and/or security reasons), possibly in the form of MultiStatic PSR (MSPSR) which, besides PSR, will be the only independent/non-cooperative surveillance technology available in the future.

8.1.5 In addition to ground-based surveillance, ADS-B will also enable the development of new airborne surveillance operational services, including Air Traffic Situational AWareness (ATSAW), and Airborne Separation Assurance Services (ASAS) like sequencing & merging and

self-separation. Future airborne applications will require changes in the avionics (ADS-B Out and ADS-B In) to process and display the air situation picture to the pilot.

8.1.6 For airports, a locally optimised mix of the available technologies, i .e. airport Multilateration, Surface Movement Radars and ADS-B, will enable Advanced Surface Movement Guidance and Control Systems (A-SMGCS) and integrated airport operations. This includes the availability of Surveillance information on a moving map, using a Human-Machine Interface (HMI) in the cockpit and in surface vehicles.

8.1.7 A rationalised (i.e. cost-efficient and spectrum efficient) ground surveillance infrastructure can be foreseen to be gradually deployed, using the opportunities offered by new technologies. Surveillance data sharing will also contribute to reduce the number of infrastructure elements (e.g radars) as the information (e.g. radar data) can be made available through ground communications networks.

8.1.8 The interrelation of surveillance techniques with communications and navigation will become a reality. The avionics carried on board an aircraft must become a fully integrated element of the surveillance infrastructure. The scope of surveillance systems will extend to embrace an increasingly diverse range of avionic components, such as GNSS, traffic computers and cockpit display systems, as well as transponders.

36 Some are referred to as Aircraft Separation Assistance System (ASAS) applications

Transponder

Figure 12. Surveillance Techniques

60

8.1.9 Surveillance provision is regulated in the SES Implementing Rules on Performance and Interoperability of Surveillance and Aircraft identification. [Ref 26, 27].

8.2 Independent/ Non-Cooperative Surveillance (Primary Radar)

8.2.1 Mono-static primary radars are currently the only existing independent/non-cooperative surveillance systems. They include Primary Surveillance Radar (PSR) and Surface Movement Radar (SMR).

8.2.2 PSR used for ATC is mostly dedicated to Terminal Approach Control. In some areas, long-range PSR has been implemented for ATC en-route purposes, based on local safety and security requirements. PSR detects and measures the position (range and bearing) of aircraft. The majority of PSR for terminal manoeuvring areas (TMA) operate in the S-Band, whilst long-range radars operate mainly in the L Band37.

8.2.3 In terms of operational use, primary radar is widely recognized by the civil ATC community to complement secondary radar information. It contributes to ATC safety while providing the capability to detect any aircraft, including those not carrying transponders or with faulty or intentionally switched-off transponders. Another form of PSR such as Surface Movement Radars is used in higher frequency bands (X-band, Ku-band) for airport ground surveillance.

8.2.4 The technology that will likely replace PSR in the medium to long term is MSPSR, a new type of independent/non-cooperative surveillance system currently under development. MSPSR technology consists of several transmitters and receivers used in a multi-static mode to detect aircraft. The transmitters used are, in general, part of the MSPSR system. Another application uses ‘transmitters of opportunity’ i.e. transmitters used for other purposes such as broadcasting DVB-T (Digital Video Broadcasting -Terrestrial) signals. However, it must be noted that these transmitters are not controlled by

the MSPSR operator, leading to safety and/or security risks. Furthermore, the coverage would be limited to lower flight levels due to limited DVB-T transmission range.

8.3 Independent/Cooperative Surveillance (SSR, Mode S and WAM)

8.3.1 SSR detects and measures not only the position of aircraft but also requests additional parametric information from the aircraft itself, such as its identity and altitude. It relies on active answer signals generated by the transponders carried by the aircraft. The transponder is a radio transceiver that receives the signal generated by the SSR on one frequency (1030 MHz) and transmits on another (1090 MHz).

8.3.2 SSR Mode A/C is mature, however there are only 4096 identification codes available and the altitude resolution is limited to 100 feet. There is also uncertainty as to whether this technology has sufficient capacity and accuracy to support new concepts. SSR Mode A/C (sliding window and mono-pulse variants) is to be reduced as soon as operationally viable. Reasons for phasing it out include its RF inefficiency and poor performance in high traffic density airspace. Traditional SSR is not compatible with Aircraft Identification (ACID) regulatory requirements [Ref 26].

8.3.3 Some legacy SSR transponders may evidence anomalies which are detrimental to the RF environment. Mode 3/A code shortages are addressed by the ACID strategy which hopes to be fully reliant on Mode S downlinked aircraft identification.

8.3.4 SSR Mode S38 (or Mode Select) has overcome classical SSR Mode A/C. This mode of interrogation uniquely identifies each aircraft using a worldwide unique 24 bit aircraft address, and allows selective interrogations of unique aircraft. It reduces asynchronous replies (FRUIT) and overlapping replies (GARBLING). Mode S also allows downlinking additional airborne data for enhanced surveillance.

37 S-Band: 1.55-4.2 GHz, L Band: 390-1550 MHz, X-Band: 5.75-10.9 GHz, K-Band: 10.9-3.6 GHz38 ED-73E represents the current desired compliance standard for Mode S transponders. The upcoming release of ETSO-C112d will cause

ETSO-C112c and its reference to ED-73C to be obsolete. TSO-C112d already calls out the technical equivalent document DO-181E. Therefore, ED-73E represents the appropriate Minimum Operational Performance Standard for Mode S transponder compliance.


8.3.5 Mode S provides aircraft-derived data (ELS & EHS) and superior performance compared with SSR Mode A/C. Wide deployment is ongoing in compliance with the SES regulation on the performance and interoperability of surveillance [Ref 27].

8.3.6 Wide Area Multilateration ( WAM) is an independent/cooperative surveillance system that employs a number of ground stations placed in strategic locations to cover an airport or a wider area. These units listen for “replies” transmitted from aircraft (e.g. Mode A/C/S, ADS-B).

8.3.7 Since individual aircraft are at different distances from each of the ground stations, their replies are received by each station at different times. Using computer processing techniques, these differences at time of arrival (ToA) make it possible to calculate the aircraft’s position. WAM is an alternative solution to complement SSR and could provide a higher accuracy and refresh rate (1 second compared to the 4 to 12 seconds of radar refresh rates).

8.3.8 WAM involves the use of relatively small ground-based antennae, compared to heavy rotating equipment. As a consequence, there are potentially significant cost efficiencies as Wide Area Multilateration provides aircraft derived data (ELS & EHS) and superior performance compared against SSR Mode A/C. Both passive and active WAM configurations are available, with increasing deployment in the short term. Combined ADS-B and WAM deployments exploit synergies between the two techniques.

8.3.9 There is concern that in the medium term the 1030 MHz and 1090 MHz frequencies will become severely impacted by RF pollution and therefore become unsafe. This problem is known for more than two decades but there was no significant progress yet. SSR and TCAS take up a significant proportion of the 1090 MHz bandwidth. A number of proposals have been made to reduce the problem (such as TCAS hybrid surveillance). In addition, the problem can be alleviated if SSR interrogations are reduced by scaling down SSR infrastructure, and information-sharing becomes a culture between users.

8.4 Dependent/Cooperative Surveillance (ADS-b)

8.4.1 Dependent/Cooperative Surveillance is based on aircraft providing their position, altitude, identity and other parameters by means of a broadcast data link. It is therefore fully dependent on aircraft systems. It is also a solution for non-radar areas or a complement to independent surveillance.

8.4.2 ADS-B reports include data derived from on-board systems and are transmitted periodically at a fixed rate. By providing more accurate and comprehensive data, ADS-B is one of the options to enable ground and airborne surveillance applications supporting current and future ATM concepts/tools such as continuous descent arrivals arrival/departure management, collaborative decision making, conflict detection, runway incursion, new separation modes and 4D contracts.

8.4.3 ADS-B Out38 refers to a unit (e.g. aircraft ground vehicle) broadcasting onboard data such as identity, position, velocity, etc. ADS-B In refers to ADS-B Out which is received by another unit. The positions of the received units are displayed to aircrews and/or ground vehicle drivers for traffic situation awareness.

8.4.4 ADS-B In enables Airborne Surveillance Applications (ASA) (or Airborne Separation Assistance System – ASAS), for ATSAW, Spacing or Separation purposes.

8.4.5 There are currently three ADS-B data link technologies: Universal Access Transceiver (UAT), 1090MHz Extended Squitter (1090ES) and VHF Digital Link Mode 4 (VDL-4). Future high-capacity data links might also be capable of supporting ADS-B. The predominant technology being used in Europe and the U.S. for ADS-B is 1090MHz Extended Squitter (1090ES). Many existing Mode-S aircraft transponders provide the ADS-B Out 1090ES functionality that will need to be certified in order to be used operationally.

39 Automatic Dependent Surveillance Broadcast 1090 Extended Squitter transmission capability (ADS-B OUT) based on EUROCAE ED 102A/ RTCA DO 260B

62

8.4.6 1090 MHz extended squitter was adopted as the basis for ADS-B data link interoperability and became the «de facto» civil standard worldwide. The other data link technologies such as VDL Mode 4 UAT may be implemented locally but global solutions are clearly preferred, to ensure interoperability and limit costs.

8.4.7 ADS-B functionalities depend essentially on the applications considered. These are standardised by EUROCAE WG 51 (and RTCA SC186). Depending on the operational goal, the following application categories can be distinguished:

n Air Traffic Situational Awareness (ATSAW): aimed at enhancing the flight crew’s knowledge of the surrounding traffic situation both in the air and on the airport surface.

n Airborne Spacing (ASPA) applications: for flight crew to achieve and maintain a given spacing from a designated aircraft, as specified in a new ATC instruction.

n Airborne Separation (ASEP) applications: the controller delegates separation responsibility and transfers the corresponding separation tasks to the flight crew, who ensure that the applicable airborne separation minima are met. The separation responsibility delegated to the flight crew is limited to designated aircraft, specified by a new clearance, and is limited in time, space, and scope.

n Self-separation (SSEP) applications: These applications require flight crew to separate their flight from all surrounding traffic, in accordance with the applicable airborne separation minima and rules of flight.

8.4.8 Satellite ADS-B systems could be an alternative means of providing surveillance cover in Oceanic or low density regions. Longer term technical improvements may allow such an approach to be used in airspace with greater traffic densities. Satellite ADS-B is planned to be available by 2020 and is therefore assumed to be a surveillance technique for later deployment. No feasibility studies have been published yet.

8.5 Surveillance Data Processing and Sharing

8.5.1 Surveillance is provided using a mix of different surveillance techniques. This requires an appropriate function to provide a seamless interface between the surveillance system and the end user (controller and tools). Current mechanisms such as data fusion or multi-sensor trackers will need to be adapted.

8.5.2 Once the surveillance data from various sources has been merged, ATC will generally be unaware of the source of the surveillance data. The data presented should be considered by ATC to be fit-for-purpose with the systems integrity monitoring being used to filter out erroneous data.

8.5.3 Surveillance Data Processing and Distribution Systems (SDPDS) based on server technology are widely implemented in ECAC. The SDPDS is capable of using multi-sensor position information from SSR (Mode-S) and ADS-B. Where required, the SDPDS uses Airborne Derived Data/Downlink Aircraft Parameters (ADD/DAP) to improve track quality and also distributes ADD with the track message. Surveillance data is used to support ATM applications, including operational tools like ground-based safety nets, automatic flight conformance monitoring, continuous descent approach and continuous climb departure.

8.5.4 Multiple ATC systems rely on surveillance information provided by the different surveillance sources and provide a picture

Figure 13. Automatic Dependant Surveillance – broadcast (ADS-b) Context


of the actual traffic situation. Surveillance data processing, distribution and sharing encompasses the following functions:

n Multi Sensor Tracking (including air track and weather data)n Generating and keeping correlated tracks

up-to-date by merging surveillance sensors (SSR, PSR, ADS/B, Multi Lateration).

n Providing ATS units with a real-time air traffic situation picture resulting from the system tracks.

n Distributing air surveillance data to external clients such as Air Defence organisations.

8.5.5 Communication networks such as RADNET/SURNET and the Surveillance Data Distribution System (SDDS) are enablers supporting surveillance data sharing. The introduction of a Centralised Service to implement a European Tracker Service (ETKR) will enable the creation of a Europe-wide consistent, high-quality picture of the air situation, processing and unifying all the data sent by numerous surveillance sensors.

8.5.6 Surveillance Data Distribution System (SDDS)

8.5.6.1 RADNET (recently renamed SURNET) is an IP-based network (with some X-25 protocol implementations remaining) for the distribution of surveillance data (sensor or track server data) and radar monitoring/control data. RADNET/SURNET comprises several dozen nodes and has been operational since 1993. Communications support of such networks is due to evolve to take advantage of IP infrastructure (e.g. PENS). This evolution will take place in the context of the Surveillance Data Distribution System (SDDS) initiative.

8.5.6.2 RADNET/SURNET comprises users from Germany, Luxembourg, Belgium and The Netherlands but there are similar networks in other states throughout Europe like UK (UK-RADNET), Spain (CEDAN) and France (RENAR).

8.5.6.3 ADS-B and Mode S ground surveillance infrastructures may be connected to this type of network. In addition to the dissemination of SUR data through RADNET/SURNET, another use has

become increasingly important. This is the placement of large central servers in the network and its remote access in a WAN client/server topology. This enables the network to support centralised multi-radar tracking for adjacent countries. On account of the large number of radars available in the network, a high-quality air situation picture is computed and described by a specific ASTERIX category for processed radar data.

8.5.6.4 SDDS will replace the RMCDE (Radar Message Conversion and Distribution Equipment), used by many military organisations, which facilitates optimum use and sharing of available surveillance information. SDDS will serve as gateway to allow the simultaneous use of a wide variety of communication protocols and ASTERIX data format conversion.

8.5.6.5 SDDS interoperability is flexible and will cope with other technologies (e.g. ADS-B, Multilateration) to be introduced later, without having to update end systems at the same time. SDDS supports all common IPv4 and IPv6 protocols and can even act as a gateway between various protocols. Integrating the SDDS with PENS will be as simple as just connecting it. In the near future, the layered design of the SDDS will facilitate its transformation into a «real» SWIM solution; this will be done as soon as SWIM’s requirements are mature.

8.6 Regulatory Aspects of Performance and Interoperability of Surveillance

8.6.1 Commission Regulation (EU) No 1207/2011 lays down requirements for the performance and the interoperability of surveillance for the Single European Sky (SPI) [Ref 27].

8.6.2 The Regulation includes requirements on the systems contributing to the provision of surveillance data, their constituents and associated procedures, in order to ensure the harmonisation of performance, the interoperability and the efficiency of these systems to support EATMN and for the purpose of civil-military coordination.

64

8.6.3 It applies to the surveillance chain made up of airborne and ground-based surveillance systems, surveillance data processing systems, ground-to-ground communications systems used for the distribution of surveillance data, as well as to their constituents and associated procedures. In practice, it mandates the implementation of Mode S (ELS and EHS), ADS-B Out and related ground surveillance components.

8.6.4 The detailed technical requirements suppor-ting the SPI regulation can be found in the EUROCONTROL Specification for ATM Surveillance Systems (ESSAP), volumes 1 and 2.

8.7 Civil-Military Surveillance Interoperability

8.7.1 Military Requirement for Primary Surveillance

8.7.1.1 There is a strict military requirement to ensure the identification of flights entering a State’s national territory. Air Defence organisations have to be provided with all the ATM information required for their task. Primary surveillance information is fundamental for Recognised Air Picture (RAP) compilation for both ATM and command and control purposes. Consequently, maintaining primary radar coverage and radar data exchange between civil and military ATC centres should be promoted.

8.7.1.2 There are security and safety imperatives justifying the retention of PSR (or any other form of independent non-cooperative surveillance). Transponder in failure or intentionally switched off are situations that call for the availability of primary information. For that purpose, PSR is expected to be maintained where operationally essential.

8.7.1.3 Military PSR coverage is extensive. This also holds true for civil coverage in some countries. Civil and military primary coverage often complement/duplicate each other to a lesser or greater extent, offering the possibility of rationalisation of surveillance infrastructures.

8.7.1.4 There is a civil pressure for PSR to be phased out due to emerging alternative detection means at lower cost, spectrum charging,

and operational needs (more aircraft equipped with transponders/avionics) etc.

8.7.1.5 The results of initial feasibility studies into MSPSR techniques point to significant saving opportunities in terms of spectrum usage in comparison to today’s civil PSR systems, which seems relevant due to the introduction of spectrum charging mechanisms. Subject to operational requirements, the MSPSR technique could also provide an indication of the 3D height of a non-cooperative aircraft. In addition, it could provide a cost-efficient means of reducing the negative effect of clutter resulting, for example, from wind farms. More R&D is required in this domain.

8.7.2 Civil-Military Surveillance Data Sharing

8.7.2.1 Surveillance data sharing between civil and military organisations and internationally across borders using communications and specific surveillance networks is expected to grow widely to ensure that all information exchange requirements can be satisfied with rationalised infrastructures. The emergence of distributed IP networks and concepts like SDDS and SDPDS will facilitate enhanced data distribution.

8.7.2.2 Military adherence to data-sharing networks varies considerably depending on the State considered. Local bilateral connectivity installations will remain in some places, to cope with specific requirements but it is crucial to cope with the applicable QoS requirements and regulatory provisions on data quality levels (comprising availability, integrity and security considerations).

8.7.3 Mode S applicability to State aircraft in an Aircraft Identification Context

8.7.3.1 Mode S is a recognised requirement for State aircraft, influencing the interoperability of State aircraft aiming to fly in a Mode S-based aircraft identification environment.

8.7.3.2 The conditions prescribing the mandatory carriage and operation of Mode S by State aircraft are set out in Commission Regulation (EU) Nr 1207/2011 laying down requirements for the performance and the interoperability of surveillance for the Single European Sky [Ref 27].


8.7.3.3 Article 8 (“State Aircraft”) lays down regulatory measures for State aircraft operators, ATS providers and Member States. Besides detailed equipage requirements for Mode S ELS, EHS, ADS-B OUT and related deadlines, it acknowledges the fact that not all State aircraft can or will be equipped. Therefore, it describes transitional arrangements for non-Mode-S equipped State aircraft.

8.7.3.4 A summary of the content of Article 8 is listed below (however, it has to be stressed that the only legally binding text is the text of the Regulation itself ).n All State aircraft flying IFR/GAT have to

be Mode S ELS capable by 7 December 2017.

n All transport-type (fixed wing) State aircraft with a certified take-off mass exceeding 5700 kg or with a true cruising airspeed capability greater than 250 knots have to be EHS and ADS-B Out capable by 1 January 2019.

n Member States shall communicate and justify to the European Commission before 1 July 2016 a list of State aircraft that cannot be equipped with ELS in due time. The equivalent deadline for the communication of a list and justification of transport-type State aircraft that cannot be equipped in due time with EHS and ADS-B Out is 1 July 2018.

n Acceptable justification include compel l ing technica l reasons, procurement constraints and State aircraft going out of service before 1 January 2020.

n ATS providers must ensure that non-Mode-S equipped State aircraft are accommodated, provided that they can be safely handled within the capacity of the ATM system.

n Member States have to publish the procedures related to the handling of non-equipped State aircraft in national AIPs.

n On an annual basis ATS providers have to communicate to the Member State that has designated them, their plans for the handling of non-equipped State aircraft. These plans shall take into account associated capacity limits of the ATM system.

8.7.3.5 Some States (e.g. Belgium, France, Germany, the Netherlands, Switzerland and the United Kingdom) have planned (and some already enforced) earlier implementation of surveillance capabilities for State aircraft. That is coordinated on a national basis and should be taken into account when military organisations plan their deployment efforts and operations. Flights in those states conducted by State aircraft may require case-by-case waivers.

8.7.3.6 Mode S equipage is also satisfying the Aircraft Identification (ACID) requirements stipulated in Regulation 1206/2011 [Ref 26], laying down the requirements on aircraft identification for surveillance in order to ensure the unambiguous and continuous individual identification of aircraft within EATMN. Mode S transponders also give a fundamental basis for subsequent ADS

8.7.4 Mode S transponders must comply with the provisions of ICAO Annex 10, SARPs. It must be an approved Mode S Level 2 transponder, as a minimum (ED-73E represents the current desired compliance standard for Mode S transponders. The upcoming release of ETSO-C112d will cause ETSO-C112c and its reference to ED-73C to be obsolete. TSO-C112d already calls out the technical equivalent document DO-181E. Therefore, ED-73E represents the appropriate Minimum Operational Performance Standard for Mode S transponder compliance). It also includes aircraft identification. The transponders need to support Surveillance Identifier Codes. Only II/SI compliant Level 2 transponders are accepted by the SES SPI Regulation; the use of Mode II/IS as a fall-back mitigation must be seen as non-recommended and transitional due to its negative RF impact.

8.7.5 The Mode S Updated NATO Military Position on Mode S can be found in the document MCM-197-04, 7 October 2004, distributed under AC/92(CNS)N(2004)0006, 21 October 2004 [Ref. 28].

8.7.6 ADS-b IN and ouT for State aircraft

8.7.6.1 ADS-B Out for transport-type State aircraft is also covered in EC Regulation 1207/2011 [Ref 27] as described above. It is a baseline requirement, seen initially as a follow on of Mode S EHS capability through the addition of supplementary applications,

66

with due regard to relevant safety cases and adequate certification practices.

8.7.6.2 Additional ADS-B applications for State aircraft that require ADS-B In were not regulated. ADS-B In implementation for transport-type State aircraft will depend on receiver capability (normally relying on the Mode S squitter receiver component also used for TCAS) and will entail a wiring retrofit (mainly to enable GNSS sources). For non transport-type State aircraft (e.g. fighters, light aircraft) solutions will depend on ongoing R&D investigations, to determine the feasibility of enabling the receiver function of ADS-B In, through the adaptation of the interrogator element present in military transponders.

8.7.6.3 Mode S and ADS-B implementation for military aircraft must be adequately coordinated with the equipage efforts in relation to IFF Mode 5 in accordance with NATO recommendations on the subject. If platform integration of positioning (PNT) data to support ADS-B implementation also fulfils the hardware requirements for implementing IFF Mode 5 Level 2 report capability on upgradeable Mode 5 Level 1 equipped platforms, states are encouraged to consider both integrations at the same time.

8.7.6.4 The airborne surveillance requirements regarding the new separation modes, defined in SESAR for military aircraft operating in a mixed mode environment, will be required to sustain both business and mission trajectory for all aircraft types in accordance with agreed concepts. No distinction has been made regarding the applications to be considered for the various military aircraft types. Applications have not yet been standardised for that purpose.

8.7.6.5 The ATM concepts also addresses advanced capabilities that potentially offer the means of achieving demanding performance requirements, in particular the very high-end capacity target through more precise longitudinal navigation performance, 4D contracts as well as separation and self separation functions supported by ASAS applications. These requirements rely on ADS-B but have a much longer R&D cycle and/or a limited initial deployment. The timeframe for

initial availability and progressive State aircraft equipage with such advanced functionalities will not take place before 2020.

8.7.6.6 In the context of airport operations, it is important to highlight that the future will bring a mixed airport operational environment with military aerodromes open to civil traffic and main civil airports accommodating regular military movements. Airport services will require a number of surveillance-related capabilities like surface movement radar and airport multilateration. Some ADS-B applications are also applicable for airport surface surveillance. The applications for airport operations have different levels of impact on the ability of certain types of military aircraft to access civil hubs.

8.7.6.7 Transpor t-type State a ircraf t are encouraged to be equipped for airport surveillance services relying on ADS-B technology. For other aircraft types this may be a “recommended” capability only where such services constrain airport access.

8.7.6.8 The criteria for selecting the applicability of each ADS-B application for the different types of State aircraft are based on the following elements:n Transport-type aircraft should have the

same capabilities as civil commercial airline aircraft. This type of aircraft should also have the surveillance capabilities required for airport access.

n Fighters should have the trajectory management and new separation modes minimum capabilities as required to benefit from full and unrestricted access to designated airspace and to safely conduct operations in mixed mode.

n Training aircraft and helicopters need to have the capabilities applicable to the airspace where they plan to operate.

8.7.7 The NATO Position on Automatic Surveillance-Broadcast (ADS-B) can be found in Document AC/92- D(2011)0002, 11 April 2011 [Ref. 29].


8.8 other Surveillance Requirements

8.8.1 Safety Nets, Weather & Hazards Detection

8.8.1.1 Airborne Collision Avoidance System (ACAS)

8.8.1.1.1 ACAS II (TCAS Version 7.0 or above) is designed to improve air safety by acting as a «last-resort» method of preventing mid-air collisions or near collisions between aircraft.

8.8.1.1.2 By utilising secondary surveillance radar (SSR) technology, ACAS equipment operates independently of ground-based aids and ATC. Aircraft equipped with ACAS have the ability to monitor other aircraft in the vicinity and assess the risk of collision by interrogating airborne transponders. Non-transponding aircraft are not detected.

8.8.1.1.3 TCAS II, version 7.0 was mandated from 1 January 2000 and 1 January 2005 for civil aircraft, depending on their MTOM and number of passenger seats.

8.8.1.1.4 The ACAS mandate was only applicable to civil aircraft. A voluntary installation programme on military transport-type aircraft by 1 January 2005 was agreed by States. One exception is Germany, where the January 2005 mandate includes “military transport aircraft”40 but German authorities put in place transitional arrangements and an exemption process.

8.8.1.1.5 A recent development, in the sequence of updated EUROCAE standards that solve some deficiencies of the system, is an EASA opinion which originated Commission Regulation (EU) No 1332/2011. This regulation foresees the need to introduce a new software version of the airborne collision avoidance system (ACAS II) to avoid mid-air collisions. It mandates the carriage of updated TCAS version 7.1 but makes refence to the EASA Basic Regulation to define the aircraft communities impacted (The military understands State aircraft to be excluded but some believe this still to be open to debate).

8.8.1.1.6 Nevertheless, the voluntary update of transport-type State aircraft TCAS software to version 7.1 is strongly

recommended, on account of important safety arguments. This holds true even if mandatory applicability to State aircraft has never been discussed or decided. As stated before, the Military believes that EASA regulatory materials, including specifications, do not apply to State aircraft or military systems due to the provisions set out in the EASA Basic Regulation.

8.8.1.2 Wake Vortex Detection & Prediction8.8.1.2.1 Wake vortex detection and prediction may

rely on ground-based sensors located at an airport as well as wake predictor tools, or on airborne means which provide an all-round hazard detection and alerting capability in all flight phases.

8.8.1.2.2 A better ability to predict and detect wake vortex formation and decay conditions is clearly one of the enablers for improving airport throughput and safety. Current separation minima on approach and departure could potentially be reduced if prediction and measurement of the formation and dissipation of wake vortices could be improved. It also allows for a reduction of in-trail separation distances.

8.8.1.2.3 From a ground surveillance technology perspective, the technical enablers identified are Ground Doppler Radar and Ground Doppler Pulsed Lidar. The airborne candidate technologies are Wake Vortex Detection - IR Lidar, Airborne Weather Radar, and an appropriate Air-Ground Data Link for providing data for accurate and reliable wake vortex identification.

8.8.1.2.4 This requirement is not regulated, and applicability to State aircraft is not defined.

8.8.1.3 Weather Hazard Detection8.8.1.3.1 Airborne weather hazard detection

capabilities are aimed at providing short and medium-term information based on airborne sensors. This information can be combined with external sources such as voice or data link information provided by ground sources or by a preceding aircraft, to provide a more complete picture to aircrews. One candidate technology has been identified: Airborne Weather Radar (X Band WXR Radar technology).

8.8.1.3.2 This requirement is not regulated and applicability to State aircraft is not defined.

40 GE AIC IFR 8 23 December 2004

68

8.8.1.4 Enhanced Ground Proximity Warning System (EGPWS)/Terrain Awareness Warning System (TAWS)

8.8.1.4.1 The EGPWS provides a real-time situational awareness of surrounding terrain and obstacles in relation to the aircraft’s altitude and flight path. The system is designed to visually and aurally alert the flight crew of potential trouble ahead.

8.8.1.4.2 EGPWS includes a built-in terrain and obstacle database designed to provide situational awareness and help avoid Controlled Flight Into Terrain (CFIT) accidents. The terrain and obstacle information can be displayed in the cockpit on a variety of compatible

displays (EFIS or weather radar) so that a pilot can immediately determine whether the surrounding terrain or obstacles are above or below the aircraft’s altitude and pose a potential threat.

8.8.1.4.3 There is an ICAO worldwide mandate on EGPWS (ICAO Annex 6 part 1) but applicability to State aircraft is not defined.

8.9 Recommendations

The following table summarises the Recommended Implementation Actions and Performance Based Opportunities. The subsequent figure shows the civil-military surveillance interoperability roadmap:

Recommended Implementation ActionsSurveillance


1 Promote the retention of independent non-cooperative surveillance (Primary Radar) to sustain security and safety requirements.

Yes (Infrastructure in place)

2 Promote enhanced surveillance data sharing using appropriate interfaces. Monitor ETKR and SDDS developments and consider opportunities for surveillance data sharing enhancement where needed.

Yes (Contributes to infrastructure rationali-sation)

3 Equip State aircraft with Mode S ELS in line with SES regulations. No (adoption of the full set of civil require-ments)

4 Equip transport-type State aircraft with Mode S EHS and ADS-B Out in line with SES regulations.

Yes (ADS-B builds upon existing IFF/Mode S capability)

5 Monitor wide area multilateration developments and consider as alternative, depending on local conditions.

No

6 Monitor MSPSR developments. No (depending on military requirements being considered in the initial design phase)

7 Plan the introduction of ADS-B In/Out for all types of State aircraft, taking into account EUROCAE/RTCA standardised applications.

Yes (reutilization of available Mode S and synergies with IFF)

8 Consider voluntary equipage for transport-type State aircraft with safety systems, weather and hazard detection (ACAS, Wake Vortex, EGPWS/TAWS, etc.).

No

9 Ensure coordination and synergies between Mode S and IFF Mode 5 implementations. Yes (avoiding duplications)

Table 7. Recommended Surveillance Implementation Actions


Civil-Military Surveillance Interoperability Roadmap



Notes:1) EC SPI regulation. Transport-type State aircraft only. With transitional arrangements.2) Local implementations as required.3) Depends on R&D results and deployment decisions. All military aircraft types.4) Replacing PSR.

Monopulse Secondary Surveillance Radar

Primary Surveillance Radar for En-Route and TMA

Mode S ELS

Mode S EHS and ADS-B Out 1)

WAM 2)

ADS-B IN/OUT 3)

for Military AircraftS 4)

Surveillance Data Sharing

MSPSR 4)

Safety nets, Weather, Hazard Detection (ACAS, Wake Vortex, Weather, EGPWS/TAWS)

Figure 14. Civil-Military Surveillance Interoperability Roadmap


PART III

COORDINATION

72

9 STANDARDISATION AND CERTIFICATION

9.1 background

9.1.1 Interoperability applies to both ground and airborne systems. The SES Interoperability Regulation [Ref 4] uses conformity assessment processes for ground systems. Airborne systems are handled in a different way for historical reasons and on account of the strong link with the already implemented airworthiness processes.

9.1.2 The ICAO Chicago Convention does not consider certification of civil or military aircraft – just interoperability. In most cases, States pass the responsibility to a national military authority, to certify military systems, often against civil requirements. As such, the military authorities can be held liable by their State authorities for compliance of their systems with civil aviation standards. Nevertheless, the evolution of EATMN leads to more and more stringent performance requirements for the navigation systems on board military aircraft.

9.1.3 Military certification systems are similar to but distinct from their civil counterparts. Because of conflicting civil and military requirements, lengthy procurement cycles, large fleets and budget constraints, many military aircraft do not strictly comply with the civil airworthiness or equipage requirements, as defined by ICAO, EUROCAE, RTCA or EASA who set the requirements to fly as GAT. In addition, the military certification system, although guaranteeing safety and airworthiness, struggles to be recognised as equivalent with respect to such compliance.

9.1.4 Ground systems must be interoperable. Some military systems are used in the context of civil ATC and may be subject to conformity assessments, depending on whether or not they are used for GAT operations.

9.1.5 At a national level, some States develop specific military standards/specifications, which aim to support interoperability requirements. International military organisations develop standardisation agreements to support their own needs. National or international military standards are generally not recognised by the civil aviation certification mechanisms and the

civil specifications and standards do not address the specifics of military systems.

9.1.6 Standardisation supports both interoperability and certification. Standardisation helps the industry in designing systems that will fit interoperability requirements. In addition, interoperability is acknowledged only through the certification of these systems according to the SES Interoperability Regulation. Standardisation eases certification by providing sound and common elements to certify against.

9.1.7 Standards are expensive but ensure interoperability. Standardisation should be considered as an investment activity rather than a source of additional spending. The money is better invested when a standard can be used by the largest number of users. The scope and regularity of the missions of military aircraft flying in European airspace (and worldwide) is significantly wider than that of civil commercial aviation. This leads to additional requirements and the need for common standards encompassing all airspace users, regardless of their origin, must be acknowledged in future aviation standards and cooperation between civilians and the military must be renewed face up this challenge.

9.1.8 SES interoperability targets are achieved when systems are compliant with essential requirements. For the military, interoperability is defined by NATO as the ability of systems to act together coherently, effectively and efficiently to achieve Allied tactical, operational and strategic objectives, with no mention of any certification process.

9.1.9 To reconcile each view, the interoperability of ATM/CNS systems must be addressed, taking into account the specificities of air-ground or ground-ground segments. Ultimately, military certificates will be recognised only when a common understanding of these specificities has been acknowledged by both civil and military authorities. This can be best achieved by putting military requirements into the standardisation process at the earliest stage.


9.2 Scope of Standardisation Activities (in the context of SESAR)

9.2.1 Standardisation activity focuses on a set of two deliverables, to facilitate standards drafting: the “standards development plan” and the “standardisation roadmap”. These living documents will evolve along with technical and operational project maturity.

Standards Development Plan

9.2.2 The exact contents and structure of the SESAR Standards Development Plan will be identified during the development of the standardisation process.

9.2.3 It is expected that the development of the first full-scope Standards Development Plan will initially be drawn up from the original List of Proposed Standardisation Activities followed by Standardisation Cases and subsequent consultation and approval.

Standardisation Roadmap (institutional roadmap)

9.2.4 The SESAR Standardisation Roadmap covers the improvements as regards standardisation to support the implementation of the SESAR ATM target concept. In order to ensure global interoperability, European standards will be prepared in cooperation with programmes from other regions of the world (such as NextGen in the USA). It also supports the development of standards taking into account military requirements.

9.2.5 The first Standardisation Roadmap will take into account the outcome of the priority task described above, i.e. the short-term ‘baseline’ activities, and will then be developed to address the full life-cycle. The timing of the input to the roadmap will depend on the ATM Master Plan update cycle which is yet to be identified.

9.2.6 The structure and contents of the Standardisation Roadmap will take into account the most recent version of the European ATM Master Plan.

9.2.7 The development of the Standardisation Roadmap is expected to follow an approach where activities are captured and validated through standardisation cases. Each identified standardisation activity will be described in a List of Proposed Standardisation Activities which will contain all of the information necessary to provide the content of the Standardisation Roadmap.

9.3 Civil-Military Standardisation

9.3.1 For civil aviation, the standardisation requirements associated with future ATM concepts will be handled within existing s tan dardi s at i on p roce s s e s. European standardisation organisations such as ETSI, CEN and CENELEC are given a focal role in the SES regulatory framework. Nonetheless, in aviation, other standardisation bodies like EUROCAE and RTCA have been working with industry for decades and provide a significant amount of aviation standards. EUROCAE is recognised by the EC as the competent body to develop aeronautical standards. Many other specialised sources provide widely used standards for aviation (e.g. ARINC) However, despite the feeling of abundance that may arise from the previous list, resources are scarce, considering the large number of standards likely to be developed.

9.3.2 Similarly to civil standardisation under the context of ICAO, military standardisation is an old activity in which NATO has a significant role of coordination for NATO Allies. Military standardisation encompasses all aspects of military interoperability: land, sea and air as well as logistics, medical, operations, command and control, and procedures.

9.3.3 The STANAG41 “system” is central for the national procurement agencies in meeting the operational needs of forces and the NATO Standardisation Agency (NSA) is working closely with the national standardisation agencies. The NSA organises the production and maintenance of STANAGs and takes initiatives towards more common civil-military standards or use civil standards that suit military needs.

41 STANAG stands for « Standardisation agreement ». STANAGs documents explicit the commitment of the nations volunteering to fulfil the common requirements proposed to improve interoperability between military forces.

74

9.3.4 Unfortunately civil standards are unlikely to include military specifics, if the military is not providing input to the standardisation drafting groups, with a negative impact on civil-military interoperability. Consequently, the military should be a partner in the civil aviation standardisation activities; cooperation between NSA and EUROCONTROL could help address this gap.

9.3.5 The challenges for the military in SES standardisation activities are:

n to be able to interface with the European civil standardisation bodies to efficiently include consistent and comprehensive military inputs in future SES standards, to support the SES civil-military interoperability at optimum cost;

n to adequately publicise SES standardisation activities within their own standardisation structures;

n to gather all the available military expertise to provide the appropriate inputs to the standardisation drafting groups;

n to maintain a proper balance between transatlantic interoperability and European civil-military interoperability.

9.4 Certification Considerations

Military Certification from a Civil Requirement Perspective

9.4.1 Certification is one of the processes to manage and ensure common and harmonised safety levels in aviation. In the SES regulatory framework, systems have to be certified to be deemed interoperable.

9.4.2 Flights conducted by State aircraft for military operations and training are out of scope of the ICAO Chicago Convention42 and, in the European Union, out of the scope of SES provisions including EASA43. Most European States normally grant to their military organisations the legal right to certify their own systems in their own certification environment. The military certification processes are mostly unknown to the wider international ATM community, so they suffer from a lack of consistency/harmonisation

between various national military authorities, as documentation is often of a restricted nature.

9.4.3 Military aircraft are not designed with regard to civil airworthiness codes44, certification specifications or standards. Nevertheless, military aviation acknowledges the importance of certification activities and has built and refined national and/or common processes in order to prove, to their national authorities and to the whole aviation community, that their flying activity is safe.

9.4.4 Regulating access to airspace indirectly impacts military flights even when not applicable to military operations and training: ICAO and SES regulations do not apply to military aircraft but some aspects of a civil regulation cannot be overlooked without putting at risk the overall safety targets. As a consequence, military aircraft certification processes should take into account all relevant requirements, to provide the same level of confidence as the civil system, even if entirely handled at a national level.

9.4.5 Recognising that State aircraft certification originates from a competent military authority is in the spirit of the international recognition system promoted by ICAO, based on national and mutually agreed responsibility45. EASA is providing a comprehensive and common certification regulatory framework for civil registered aircraft in Europe. For State aircraft, the certification environments remain national.

9.4.6 It should be noted that the EASA Basic Regulation46 shall not apply to products, parts, appliances, personnel and organisations while carrying out military, customs, police, search and rescue, firefighting, coastguard or similar activities or services.

9.4.7 The need to ensure military certification processes are recognised by civil regulators calls for the application of performance-based certification.

Performance-based Certification

9.4.8 Performance-based certification needs to be fully defined as a process which is alternative to the existing comprehensive, legal and trustworthy certification environment. It

42 Article 3 therein.43 Article 1.2 of EC Regulation 216/2008 lastly amended by Regulation 1108/2009.44 Unless they are based on commercial derivatives. If minimal design changes are made then credit may be able to be taken for civil certification.45 It might imply to be part of the ICAO universal safety oversight audit programme (USOAP)46 Basic Regulation. Regulation (EC) No 216/2008 of 20/02/2008 on common rules in the field of civil aviation and establishing a European Aviation

Safety Agency


consists of verifying that a system meets the performance requirements derived from a regulation, with the possibility to meet some of those requirements using alternative means of compliance, whilst ensuring that the safety levels are at least equal to, or better than, the original safety objective. The set of requirements that the system is certified against and the mitigation measures taken should be made explicit.

9.4.9 The main challenge with this performance-based approach is first to precisely define “equivalence” and secondly, to be able to demonstrate it. The performance requirements used as the basis to certify and the means to demonstrate compliance must be extensively documented. That includes all technical, procedural and operational information.

9.4.10 Performance based certification is designed to be an alternative certification process in cases when “traditional” certification cannot be achieved or there is an advantage in not using it. Some conditions need to be met to ensure that the labels and certificates granted by the certification authority have at least the same level of confidence as their civil equivalents.

9.4.11 Equivalence of performance includes the measurable (e.g. metrics from regulations and standards) and non-measurable requirements (e.g. procedures or technical architecture).

Certification of Military ATS Providers

9.4.12 The above considerations are mainly applicable to military aircraft systems. The certification of ground systems normally follows different criteria. States retain the right to decide when a military ATS provider must be certified, on the basis of requirements applicable to GAT operations. Such a decision may be regulated and normally depends of the level of services provided to civil traffic operating as GAT or in a military aerodrome open to civil aviation.

76

10 SPECTRUM

10.1 background

10.1.1 An inherent characteristic of radio spectrum is the scarcity of available frequencies. Frequency congestion in some bands has increased dramatically due to the rapid evolution of telecommunications technologies. Its important role in the development of economies led States to classify the spectrum as a resource under strict national sovereign control. Nevertheless, as radio waves do not respect national borders and services are of a global nature, all nations recognise that international co-ordination and harmonisation on spectrum use and allocation has become fundamental to ensure an interference-free environment.

10.1.2 The success of most military missions depends on adequate access to spectrum resources, particularly to ensure mobility and interoperability of forces. Military utilization of spectrum bands must be safeguarded and the mitigation of harmful impact into the civil infrastructure ensured through a comprehensive civil-military coordination effort.

10.1.3 Military authorities have always been committed to using the frequency spectrum in accordance with the provisions set out by International Telecommunications Union (ITU) including its Convention and the Radio Regulations. Nevertheless, it is of utmost importance to push forward adequate military positions to ITU World Radiocommunication Conferences (WRC) consolidated with the global civil aviation positions. The integration of civil-military aspects into aeronautical spectrum strategies is fundamental to facilitating the co-existence of civil and military requirements.

10.2 Principles in Spectrum Activities

10.2.1 A set of strategic principles has been identified in order to achieve the key spectrum protection objectives:

n demonstrate that the usage of the allocated spectrum is efficient,

n further improve participation in the activities of spectrum-related institutions,

n identify aeronautical spectrum requirements

and conditions of use for new or modified CNS systems at the very beginning of system design,

n define comprehensive spectrum-sharing criteria within the CNS domains and with non-aeronautical services,

n establish a comprehensive awareness of the future development of the global spectrum usage,

n ensure the monitoring of actual spectrum utilization,

n reduce the susceptibility of aeronautical systems to harmful interference,

n identify and manage transition issues related to the introduction of new services and the decommissioning of old services or systems,

n identify and review national and regional efforts to introduce charges on the use of aeronautical spectrum (spectrum pricing),

n ensure that the ground-based CNS infrastructure is optimised as much as practicable with the future satellite based systems,

n ensure that the appropriate spectrum is in place to support the technology used in the various SESAR deployment phases.

n ensure civil-military spectrum coordination.

10.3 Consultation Mechanisms

10.3.1 Further to a decision taken by the European Civil Aviation Conference (ECAC) Ministers of Transport (MoT), at their MATSE/6 (Meeting of ECAC Transport Ministers on the Air Traffic System in Europe) meeting in January 2000, the independent Aeronautical Spectrum Frequency Consultation Group (ASFCG) was established by EUROCONTROL, ICAO and the States. Membership of the ASFCG includes Member States, European Commission, ICAO, the EUROCONTROL Agency, IATA, NATO, air navigation service providers, and other stakeholders. In parallel with other activities, the ASFCG develops the European Aeronautical Spectrum Strategy and the European Aeronautical Common Position to ITU World Radiocommunication Conferences where it is of utmost importance to reflect relevant civil-military coordination aspects.

10.3.2 EUROCONTROL’s main role as regards spectrum management is to participate in and provide support to the preparation, approval and


promotion of the aviation positions for the ECAC States, and ensure that these are recognised for the ITU WRC. Considering that only the ITU Member States, normally represented at ITU through their telecommunication administrations, are authorized to submit proposals and to vote at a WRC, EUROCONTROL seeks assurances that aviation positions are recognised in the CEPT47 positions for the ITU WRC, to the maximum extent possible.

10.3.3 EUROCONTROL also has a leading role in the activities to meet the spectrum-related deliverables for the SESAR work programme. Civil-military working arrangements are available at EUROCONTROL to facilitate civil-military coordination on spectrum matters. In addition, the recently designated Network Manager, in line with EC Regulation No 677/2011 of 07 July 2011, comprises a Radio Frequency Function (RFF), which also requires civil-military coordination efforts.

10.3.4 NATO is one of the prominent participants of ASFCG and shares a common interest with civil aviation in aircraft operations and the associated use of the aeronautical spectrum. The NATO Civil/Military Spectrum Capability Panel (CaP 3), reporting (through the Consultation, Command and Control (C3) Board (C3B)) to the North Atlantic Council (NAC), acts as the focal point and the sole competent source of advice and decisions on the management of radio-frequency spectrum within the Alliance.

10.4 Spectrum Challenges with Military Impact

10.4.1 Spectrum challenges with potential military impact comprise:

10.4.1.1 Future ATM Infrastructure - The viability of implementing a future ATM infrastructure is totally dependent on the timely availability of sufficient radio frequency spectrum to support the necessary CNS elements. It is extremely difficult to identify new spectrum to accommodate additional CNS systems. Consequently, current plans are aimed at introducing these CNS systems in frequency bands already allocated for use by aviation, in particular through the shared use of

frequency bands by navigation and air/ground communication systems.

10.4.1.2 Pressure from non-aeronautical users to share spectrum currently allocated for aeronautical purposes will continue. In some cases such sharing may be technically feasible and acceptable. Sharing of spectrum with non-aeronautical services should give priority to aviation safety of life services when accommodating new requirements or protecting existing ones.

10.4.1.3 Spectrum Release - Some governments may announce intentions to release/free up public sector spectrum for commercial users, mainly for mobile communications use.

10.4.1.4 New systems and services supporting the European ATM Master Plan - New systems and services which are essential to the European ATM Master Plan are to be implemented. Some of these systems extend their current use, such as the increasing number of applications relying on SSR Mode S extended squitter (ADS-B), the potential performance capabilities of non-cooperative surveillance through the use of MSPSR technology, the increased reliance on GNSS signals and the ever increasing need for air/ground VHF voice channels.

10.4.1.5 New systems are to satisfy new air/ground data l ink requirements primarily in frequency bands that are already intensively used by aviation for radionavigation and spectrum for aeronautical satellite communications needs to be released. To ensure that the necessary spectrum is available in a timely manner, technical and [radio] regulatory difficulties require increased cooperation between system designers, spectrum managers and ATM experts.

10.4.1.6 Spectrum Pricing - Radio-frequency spectrum demand is very high for commercial applications such as mobile telephony, wireless applications and broadcasting. This increasing demand for spectrum exceeds available capacity ,which has resulted in the owners of spectrum (States) placing a price on its use (spectrum pricing). The idea of spectrum pricing has been progressed in the United Kingdom and after a decade of studies

47 CEPT - Conférence Européenne des Postes et Télécommunication

78

and consultations, spectrum pricing for aeronautical services is becoming a reality there, despite strong opposition from the aviation community. Once implemented, there is a risk that other countries may introduce spectrum pricing as well.

10.4.1.7 One of the philosophies behind spectrum pricing for aviation is to encourage more efficiency in the use of the radio frequency spectrum which would in turn enable some of the spectrum currently in use by aviation to be re-allocated for commercial services. The current “spectrum pricing” mechanism is known as “Administered Incentive Pricing (AIP). The cost rates for AIP are based on “opportunity cost”, which is related to the values of new (commercial) applications that may use the spectrum.

10.4.1.8 In particular for “spectrum-consuming” systems like primary surveillance radar and DME, the future cost of using spectrum may become excessive. The possible introduction of spectrum pricing in some countries may have an economic impact on aircraft operations and may be perceived as a new tax on aviation. As such, spectrum pricing is expected to be strongly opposed by the aviation community.

10.4.1.9 The military is the biggest user of spectrum resources in the world and it is easy to understand that civil-military coordination is crucial to safeguard the requirements essential for military mission effectiveness including access to required spectrum bands and maintenance of an interference-free environment.

10.4.1.10 If the military adopt the same technologies as the civil community they become another very small user of the same spectrum and hence the case for spectrum is just part of the larger requirement. If the military have needs for other spectrum this needs to be protected for continued access or increased if there are going demands.

10.5 Spectrum bands With Civil-Military Coordination Needs

10.5.1 VHF ATC navigation (108-117.975 MHz): ICAO systems such as VOR and ILS are supported in this band. Withdrawal of excessively redundant VOR (or VOR/DME) systems is expected along with the on-going implementation of GNSS. However, some continued use of VOR is expected to satisfy residual requirements for general aviation and for military use. The continued use of VOR and ILS is supported by military aviation in Europe. These systems are essential to provide for approach and landing services and the protection of these uses needs to be ensured. In particular military use of ILS Cat I systems is expected to continue beyond 2030.

10.5.2 VHF ATC communications (118.-137 MHz): The band 117.975 – 137 MHz is used globally for air/ground ATC communications, including voice and data link. The band is used to satisfy a variety of essential communication requirements to support the safety and regularity of flight, including airline operational control. This band is highly congested in much of Europe. The full introduction of VHF 8.33 kHz channel spacing in all European airspace is expected to assist in meeting the requirements for air/ground communications until 2030. Should there be a need for additional spectrum, this may be accommodated in the band 112 – 117.975 MHz, subject to the planned decommissioning of VOR systems. In order to cope with this situation, the SES Regulations on air-ground voice channel spacing will play a decisive role.

10.5.3 Military A/G communications for off-route (138-144 MHz): This band supports the handling of military aircraft flying as OAT or GAT off-route. In some countries the full range up to 150 or 160 MHz is used for military air/ground/air requirements. Cooperation between NATO and non-NATO air forces relies heavily on the availability of this military band.

10.5.4 Military uHF communications (225-400 MHz): This band is essential for NATO’s air forces. It is used primarily for line-of-sight tactical ground communications, A/G, A/A voice and data links.


Its use includes telemetry communications for military UAS/RPAS, UHF tactical satellite and tactical radio relay networks.

10.5.5 Future military communications requirements will rely heavily on the UHF spectrum, including the needs of deployable forces, command and control requirements and advanced technologies, which will be used for military purposes. UHF frequencies have traditionally been lent to civil ANSPs to be implemented in support of ATC services provided to military aircraft.

10.5.6 Aeronautical radio navigation (960-1215MHz): The L-band supports fundamental services for both civil and military aviation. These are based on the operation of systems such as DME, TACAN, SSR, PSR, ACAS, Mode S, IFF and some bands of GPS and GALILEO. JTIDS/MIDS uses a set of 51 frequencies in this band, but also on a non-interference basis. It is vital to maintain aviation interests in this band.

10.5.7 The use of TACAN is a continuing military requirement; the use of TACAN may be reduced when the transition to GPS/inertial navigation for military aircraft progresses in the longer term.

10.5.8 Rationalisation of DME needs to be considered. Such rationalisation may involve optimisation of the DME infrastructure as well as a review of the technical characteristics of DME (such as the need for hard channel pairing with ILS/VOR/MLS or the use of DME W/Z channels).

10.5.9 The band 960 – 1164 MHz is, in accordance with the ITU Radio Regulations, also available for air/ground communication systems. These systems are subject to protecting current and future use of this band by DME and SSR stations. Currently studies are underway to develop an air/ground data link system (LDACS) in this band which provides the necessary capacity while protecting radionavigation systems (DME and SSR).

10.5.10 In Europe, the introduction of a dedicated system for RPAS/UAS command and non-payload communications would not be feasible, due to the wide-spread (and increasing) implementation of DME. However, on an initial basis, subject to available capacity, while giving

priority to ATM communications, it might be possible to accommodate such RPAS/UAS communications.

10.5.11 Parts of the 960 – 1215 MHz band are used for JTIDS/MIDS, a military communication, identification and navigation system. Future use of JTIDS/MIDS needs to be secured when implementing an air/ground data link (LDACS) or other new systems in this band. The continued access to sufficient spectrum to support JTIDS/MIDS must be achieved.

10.5.12 There is a need to maintain the current allocations in the bands 1215–1400 MHz, 2700–3400 MHz, 9000–9200 MHz, 15.4–15.7 GHz and 31.8–33.4 GHz to secure continued availability of these bands for primary ground based radar systems in the longer run. This is crucial to sustain military operations that require the continuing availability of primary (independent non-cooperative) surveillance radar systems or any other way of tracking non-cooperative targets for Military ATC and Air Defence.

80

11 PLANNING AND PROCUREMENT

11.1 background

11.1.1 Interoperability between civil and military systems should be implemented at the lowest possible cost for civil and military budgets.

11.1.2 Military acquisition is a management process dealing with State investments in the technologies, programmes and product support needed to achieve national security and defence objectives. Modern military procurement and acquisition is a complex blend of science, management, and engineering disciplines within the context of a nation’s law and regulatory framework to produce military material and technology. This complexity evolved from the increasing sophistication of weapon systems, which started in the 20th century.

11.1.3 The result of such added complexity is that military planning and procurement programmes entail longer lifecycles that normally double the comparable civil planning/procurement lead times. When considered in the particular field of ATM these discussions gain additional complexity due to the additional safety and regulatory considerations involved.

11.1.4 The military are vulnerable to ATM/CNS evolution. Even when applying robust integrated logistics support methodologies to plan the deployment of relevant ATM/CNS capabilities, some factors limit the ability of ATM planners and military authorities to adopt ATM requirements:

n the civil nature of multiple ATM/CNS requirements lacking military justification;

n huge military fleets with multiple military aircraft types and variants;

n technical integration constraints;n lengthy procurement cycles and budget

constraints;n lack of civil-military coordination during

ATM/CNS regulation drafting;n lack of civil-military ATM/CNS standards

and equivalent verification of compliance/certification processes (a strict national competency which could benefit from an harmonized approach).

11.1.5 Recognition of available military capabilities, ground and airborne, and its re-utilisation or adaptation to support ATM functions can drastically reduce such retrofit costs and technical impacts.

11.1.6 A “Policy Guidance for the Exemption of State Aircraft from Compliance with Specific Aircraft ATM/CNS Equipage Requirements”48 [Ref 30] has been defined in EUROCONTROL since 2003 on the basis of a number of principles that are still to a large extent valid.

11.1.7 This policy states that State aircraft conduct a justified and legitimate activity. It recognises that for technical or operational reasons, compliance with specific equipage requirements is not always possible or, indeed, warranted. In particular, it is recognised that combat military aircraft are essentially weapons platforms and equipage priorities must therefore be decided accordingly. It stresses that the need for an exemption for State aircraft should be based on compelling technical or military imperative reasons and only used as a last resort.

11.2 Military Planning and Procurement Methodologies

11.2.1 Two particular processes or techniques [Ref 31, 32, 33] to organise, plan and execute requirement identification, approval, acquisition and operational sustainability of military systems should be highlighted:

n Systems Engineering (SE) is about creating and delivering successful systems by managing complexity, technical risk and the flow of decision making. SE considers military capability needs and, through the application of design and trade-off processes, shapes these into definitions of products and services against which contracts can be agreed.

n When applied in the context of defence, SE embraces Military Capability Engineering as it covers the various capability levels and it is concerned largely with Defence Capability Planning to support financial planning. In

48 Agreed by the EUROCONTROL Civil-Military Interface Standing Committee (CMIC) in March 2003 and endorsed by the Provisional Council


terms of System of Systems Engineering it manages the System of Systems consistency across all development streams. At Project Systems Engineering level it delivers results or upgrades and ensures the transition into service of a mission-effective product or service. A fundamental enabling technique of SE is Obsolescence Management which is quite relevant to mitigate the cost and impact of accommodating legacy systems.

n The Systems Engineering model extensively used by the UK MoD to express the system engineering processes and activities is the so-called Vee-Model. This model is the same as (or very similar to) the European Operational Concept Validation Methodology (E-OCVM), frequently used in the ATM context. This demonstrates that military organisations and ATM processes could easily be compared and streamlined.

n Integrated logistics support (ILS) is an integrated approach to the management of logistic disciplines in the military. All elements of ILS are ideally developed in coordination with the system engineering effort and with each other. Tradeoffs may be required between elements in order to acquire a system that is affordable (lowest lifecycle cost), operable, supportable, sustainable, transportable, and environmentally sound. The planning for ILS for a system may be contained in an Integrated Logistics Support Plan (ILSP). ILS planning activities coincide with the development of the system acquisition strategy, and the programme will be tailored accordingly.

11.2.2 The deployment of ATM/CNS improvements should be organised and planned using the following good practises:

n National Military Authorities should organise, plan and take deployment decisions on the basis of military requirements but take into account published SES interoperability implementing rules and national ATM/CNS regulations (regardless of the fact that military operations and training for wartime and crisis are excluded)

n Agencies and organisations involved in the planning of military C2 systems and communications and information systems

(CIS) will be involved in the planning process due to potential interactions with EATMN. These are fundamental to determining the level of compliance needed. This needs to be done for all areas of operation – European and globally as appropriate.

n The military will be involved in the preparation of SES interoperability regulations and associated standards (contributing to mandates given to EUROCONTROL or EASA)

n Stable guidance is provided to military organisations in the form of implementation roadmaps that evidence specific capabilities applicable to military systems and platforms

n National Military Authorities should communicate to civil Agencies involved in SES rulemaking, ATM deployment and Network Management their ATM/CNS equipage plans and procurement constraints technical limitations to cope with aviation mandates

n Exemptions will be envisaged for residual platforms whose out-of-service date is within 8 years after the latest capability implementation date and when there are justifying insurmountable technical constraints.

n Multiple capabilities are to be introduced in packages that should not force retrofit/mid life interventions more than once every 8 years for the same platform.

n Rather than favouring the implementation of special procedures, the first approach should be to enhance interoperability. (Consideration should also be given to impacts of non-compliance e.g. can limitations in when operations can take place be accepted? Can longer flight paths be flown avoiding the need to equip with CNS capabilities?)

n There is a need to consider performance-based approaches minimising retrofit efforts by meeting compliance on the basis of enabler-independent options

n Appropriate consideration needs to be given to the situations where high levels of automation entail the exclusion of options other than interoperability or conflict management

n Technology convergence targets should be pursued with any transition arrangement or exemption policies seen as temporary measures

82

n New requirements should be introduced, preferably as forward fits, and agile capability approaches should be maximised, including the re-utilization of avionics, multi-mode capabilities and enhanced obsolescence management

n Possibil it ies offered by backwards-compatible ATM services and capability levels should be considered as options for granting minimum airspace and airport access without significant retrofit efforts

n The verification of compliance and conformity assessment processes must be supported by enhanced civil-military ATM coordination practices. Military authorities are responsible for the certification of military systems.

11.3 obsolescence Management

11.3.1 Since retrofits are to be minimised in order to reduce overall compliance costs, it is essential that military organisations follow sound obsolescence management practices. These practices and processes require the early involvement of the defence industry

and involve technical, cost and re-certification considerations, normally including:

n Approaches that respond to repeated extensions of the service lives of air platforms, together with shorter lifecycles of hardware and standards

n Integrated Modular Avionics (IMA) solutionsn Use of Commercial Off The Shelf (COTS)

where vulnerability to standard updating and certification problems so allows

n Priority to “incremental technology insertions” that increase the intervals between capability changes

n Re-use of legacy hardware leveraged with enhanced components

n Re-use (re-writing) of legacy software functionalities to adapt to new processing environment (with re-certification)

n Use of software emulation to mitigate obsolete hardware

n Use of a model-driven architecture to allow for modular and incremental certification

11.3.2 UK MoD is a leading organisation in the field of obsolescence management and referenced document [Ref 31] provides sound guidance in the field.


12 SECURITY

12.1 Context

12.1.1 The growing threat to the aviation infrastructure from unlawful acts means that the security of passengers, aircraft and ATM facilities is assuming greater importance. However, security gaps may exist in ATM where risks are assumed and costs receive a paramount consideration.

12.1.2 As more advanced infrastructure enablers are introduced in EATMN, new threats call for tighter security analysis. The main technical areas raising security concerns are associated with the introduction of ADS-B, air/ground data link, use of GNSS and a ground network-centric environment, where higher levels of connectivity multiply risks. On the positive side, it must be highlighted that most of the ongoing ATM research and plans to introduce EATMN communications improvements comprise already security solutions that take stock of the most recent technologies in the field.

12.1.3 In normal circumstances, ATM information is sensitive but unclassified and security solutions for data exchanges with military sites/systems can be less stringent. Nevertheless, security and interoperability measures applicable to the interconnection between designated military systems and other external systems with different protection levels must be applied on the basis of sound security assessments.

12.1.4 Consideration needs to be given to the level of information security needed by the military for ATM information. Some may be more sensitive than others so a multiple level approach may be needed. A security review needs to be undertaken to determine this.

12.1.5 A generic informative outline of the standard technical security approaches applicable to the EATMN context is provided below, without prejudice to relevant national regulations and/or NATO Office of Security (NOS) directives/policies. Available interoperability interfaces may already offer a certain level of security services. The required specific information security measures for each installation must be identified in accordance with the security

policies in force, after adequate risk analysis and security assessment and taking into account local conditions and the level of sensitivity of the systems/data involved. Local military authorities must ensure adequate governance of security mechanisms and perform the necessary accreditation actions.

12.2 Technical Security outline

12.2.1 For air/ground systems like ADS-B or data link the main security concerns are the exploitation of real time airborne position data by malicious attackers. Another potential vulnerability is the possibility of generating false but credible ADS-B reports or data link messages, providing ghost aircraft tracks and thus confusing ATC (spoofing). Possible measures to mitigate this type of vulnerabilities could be the suppression or concealment of information, message authentication, and/or increased monitoring activities of suspicious messages [Ref 34]. More research is needed on this domain before consolidated security options become available.

12.2.2 For the interconnec t ion of ground communications networks, existing NATO doctrine applicable to the NATO Network Enabled Capability (NNEC) [Ref 35, 36] is a good baseline for identifying some technical security options. NATO has defined the concept of an information exchange gateway (IEG) to facilitate secure communications between different security and management domains. The IEG is designed to provide a standard and secure method of communication between NATO, NATO nations, non-NATO nations, coalition forces, non-government organisations (NGOs), and other international organisations.

12.2.3 The need to ensure the confidentiality, integrity and availability of information, has led NATO to define an interface architecture which makes use of well-defined, limited and symmetrical interfaces and a minimised number of standard protocols. The IEG works on the principle of the self-protecting node; it assumes that everything is hostile including the internal network, so only information and services that need to be exchanged are allowed across the interface.

84

12.2.4 A number of connectivity scenarios (or security domains) have been defined, including for the interaction between military systems and external ones, to determine the local requirements for the use of such interfaces. The architecture and components for the interfaces must comprise levels of protection to be provided to the nodes and to the information, including security services like network filtering, intrusion detection and virus/malware detection as well as services to check the releasability of information outside of the domain.

12.2.5 The information exchange is controlled in the interface through the use of proxies to enable specific information flows. Information exchange between domains is only allowed via proxy servers that define enclaves and ensure that there is no direct connection between servers in the external domain and servers in the internal domain.

12.2.6 Proxy servers provide a known protocol implementation conformance, hiding the internal domain implementation of the protocol. This provides a good basis for interoperability with a remote gateway. The actual proxy servers required in an interface will depend on the information that is to be exchanged between the two partners. Basic services may include informal messaging (e-mail), web browsing, directory replication and formal (military) messaging. Each service will require a proxy server to mediate the traffic flow between the two domains.

12.2.7 An e-mail proxy server will typically be a message transfer agent (MTA) capable of handling X.400 or SMTP traffic. A directory replication proxy server will allow replication between the two

domains. Directory replication will typically be using either X.500 directory information shadowing protocol (DISP) or a meta directory product using LDAP to read and write to the remote proxy server. A web browsing proxy server will allow web pages to be browsed between the two domains. Web browsing will use the HTTP(S) protocol. A formal messaging proxy server will be an MTA capable of handling X.400 traffic and supporting rich content such as attachments. Interworking of formal messages with the Military Messaging Handling System (MMHS) will require support for digitally signed X.400 messages, as defined in NATO STANAG 4406.

12.2.8 The IEGs will also include application level guards to ensure information protection services. These will inspect the application data to ensure that the information is suitable for release from the internal domain.

12.2.9 In general, the IEGs will use standard networking components, including switches, routers and firewalls. They will be defined on the basis of commercial off-the-shelf security mechanisms like IPSec. It is assumed that the market for IPv6 firewalls and router integration of IPSec for IPv6 will mature very rapidly. From a functionality or feature point of view and considering that ANSP applications operate over private infrastructure, there would be enough security mechanisms to start with.

12.2.10 Technologies for network security may comprise hardware (encryption devices, firewalls, internetworking devices) and software products (Secure Sockets Layer (SSL), IPSec, Digital Certificates and Public Key Infrastructure - PKI).


ANNEX A

SYSTEM WIDE INFORMATION MANAGEMENT

A-1 What is SWIM?

A-1.1 System Wide Information Management (SWIM) consists of standards, infrastructure and governance enabling the management of ATM information and its exchange between qualified parties via interoperable services.

A-1.2 In practical terms, SWIM supports the ATM community on its needs for timely, relevant, accurate, accredited and quality-assured information in order to collaborate and make informed decisions. It enables the sharing of an integrated picture of the real-time and planned state of the ATM situation on a system-wide basis so that ATM operations are conducted safely and in a more efficient manner.

A-1.3 SWIM is being defined, at the level of ICAO, as a global concept that provides a common understanding of the different domains of information as well as related operational concepts. Some data exchange models and mechanisms are already being developed for some information domains: the aeronautical information exchange model (AIXM), which is already in use, the flight information exchange model (FIXM) and the weather information exchange model (WXXM) are good examples.

A-1.4 SWIM gives the network-centric environment that will interconnect multiple domain systems providing or consuming information, including human users and aircraft. Through SWIM, information is made available and processed through services which need to conform to applicable standards and be registered. In addition, SWIM improves the interconnectivity of domain systems to improve information management and therefore information-sharing on a wide basis.

A-2 SWIM Principles

A-2.1 SWIM is based on the following principles:

n Principle of federation - SWIM will enable the stakeholders in the European ATM community to collaborate in a federated

manner, at pan-European, regional and local levels. A specific stakeholder can delegate responsibilities to other actors.

n Principle of information-sharing - Information will be available to all parties, except if specific policies restrict access to it. The objective is to make information available to a greater number of ATM stakeholders.

n Principle of service orientation - SWIM will use services as the mechanism for supporting the ATM stakeholders, decoupling the producers of information from the consumers, in order to separate concerns and responsibilities and to increase flexibility.

n Principle of open standards - SWIM services will be based on open and internationally agreed standards when fit for purpose. By using open standards, each stakeholder can choose the required technology, provided that it is compliant with the applicable standards.

n Principle of information and service life cycle governance - SWIM information and services will be governed throughout their life cycle.

A-3 SWIM and EATMN

A-3.1 SWIM will introduce a complete change in how information is managed throughout its life cycle across the whole European ATM system. SWIM is a key enabler for the future EATMN on the basis of the integration of all ATM business-related data. It enables the important ATM concept elements of trajectory operations, collaborative decision-making and shared situational awareness.

A-3.2 By using commercial off-the-shelf technologies, open formats and standardised interfaces, SWIM is expected to reduce the costs associated with the development and deployment of new applications and services. Service standardisation will facilitate the re-use of information in other contexts, thereby contributing to cost efficiency. The increased interoperability of data formats and interfaces will create a modular system architecture, in which domain systems from different manufacturers can be seamlessly connected, eliminating the need for expensive tailor-made interfaces.

86

A-4 How to build SWIM ?

A-4.1 SWIM can be build on the basis of the following elements:

n ATM Information Reference Model (AIRM) - representing the standard definition of all ATM information through harmonised conceptual and logical data models;

n Information Service Reference Model (ISRM) - representing the logical breakdown of required information services and their behavioural patterns. These services are also called ATM-specific services;

n Information Management Func tions (including governance) - such as operational a n d o rg a n i s at i o n a l f u n c t i o n s fo r the management of user identities, discoverability of resources, security aspects such as confidentiality, integrity, non-repudiation, accountability and authenticity;

n SWIM Technical Infrastructure (SWIM-TI) - interoperable infrastructure (ground/ground and air/ground) via which ATM data and services are distributed, shared and consumed; Its implementation may, depending on the specific needs profile, differ from one stakeholder to another, in terms of both the scope and the type of implementation. It will mostly be based on

commercial off-the-shelf (COTS) standard-based and interoperable products and services, but it is possible that in some cases specific software may need to be developed;

n SWIM-Enabled Applications - the application of SWIM standards and principles to the interfaces of ATM applications enables ATM business benefits by assuring the provision of commonly understood, quality information to the right people at the right time.

A-5 SWIM Technical Infrastructure (SWIM-TI)

A-5.1 SWIM-TI is a set of software components distributed over a network infrastructure providing capabilities properly enabling collaboration among ATM systems. These capabilities are instantiated in a set of SWIM nodes (stakeholder end points) and common components (providing capabilities to all the distributed SWIM nodes).

A-5.2 The SWIM node concept represents a package of SWIM-TI capabilities, allowing a given ATM system to use the SWIM-TI. Examples of common components are the registry, which is used to enable the sharing of information (metadata) about services, or the public key infrastructure (PKI), aimed at managing the trusted digital certificates.

A-5.3 The SWIM node logical architecture component can physically be deployed in various ways: SWIM node deployed as a software component integrated together with other software components of the ATM system or deployed in their own dedicated environment, independent of the software components of the ATM system.

A-5.4 SWIM nodes can be mapped against various SWIM needs with potential set of supporting technologies and services options, depending on usage and needs. It is nevertheless essential to understand that the fact that SWIM is as service oriented architecture (SOA) implies that the inner SWIM interfaces (between SWIM node and SWIM infrastructure) are standard on the basis of ISRM and users have to plug and play in a way which is compatible with the protocols made available. Local interfaces between SWIM nodes and APP (SWIM Application Interfaces) are proprietary and may satisfy local requirements.

Figure A-1 – SWIM Nodes and Interfaces


A-5.5 SWIM-TI is the interoperable (runtime) technical infrastructure (Ground/Ground and Air/Ground) over which data and services will be distributed. It includes the common SWIM technical services required to physically exchange the information and is predominantly based on mainstream IT technologies. The technical services are organised in so-called SWIM profiles. A SWIM profile is a particular set of services tailored at meeting specific functional and non-functional requirements expressed by the ISRM. The latest definition is: “a SWIM profile is a coherent, appropriately-sized grouping of middleware functions/services for a given set of technical constraints/requirements that permit a set of stakeholders to share Information. It will also define the mandated open standards and technologies required to realize this coherent grouping of middleware functions/services.”

A-6 Interfacing Military Systems with SWIM

General Considerations

A-6.1 Relevant military requirements should be captured when overarching SWIM architecture principles, information management, gover-

nance, supervision, exploitation procedures and data models are unilaterally defined.

A-6.2 The categories of military systems to be inter-connected through SWIM may include, inter alia, ATC, airport, flight/wing operations centre, regional and sub-regional systems, aircraft, SWIM supervision, air-ground data link inter-faces and external systems. External systems include some subsidiary military systems (in general systems supporting the command and control of military air operations) and airspace user agent systems.

A-6.3 From a functional point of view, the mili-tary will be a normal SWIM participant. As a consequence, military users must respect the underlying SOA infrastructure and join on the basis of the defined standard interfaces in place. Additional interoperability requirements will normally be raised and need to be covered at the level of proprietary API interfaces.

Data Formats and Models

A-6.4 Prior to defining any technical interfacing approaches, an exhaustive assessment is needed in respect to the overall compliance of military systems with current versions of aeronautical

Figure A-1 – SWIM Nodes and Interfaces

88

information and flight data standards, data quality requirements and communication proto-cols, including regulatory material included in SES IRs and Community Specifications.

A-6.5 The same applies to the need to study the migration to information solutions compliant with new data exchange standards like AIXM (expanded to cover military requirements), FIXM and others and to the data-centric infor-mation environment described in the ICAO Roadmap for the Transition from AIS to AIM. Another area of concern is the need to study the implications of Flight Object concepts. A first step is the Flight Object Interoperability Proposed Standard (FOIPS)49, which will be the basis for a new standard for flight data exchange in Europe.

Interfaces

A-6.6 The best solutions for military ATM and Air Defence/C2 system connectivity with the under-lying SWIM architecture depend heavily on the efforts to define and validate specific interfaces.

A-6.7 Such interfaces should be based on the Information Exchange Gateway (IEG) model (see also section 12). An IEG allows bidirectional data exchange between the networks of different security domains. In the case of SWIM, the IEG would allow communication between military legacy systems and non-governmental or inter-national organisations and the internet50.

A-6.8 The advantage of the IEG model is that it allows a double administration of security, i.e. one administration for each of the two intercon-nected networks. The other advantage is that the IEG model can be implemented through existing civil COTS such as XML gateways51. XML gateways apply fine-grained information filtering in order to avoid the disclosure of confi-

dential information. In addition, XML gateways, by translating different data formats, ensure that the XML messages generated are clean and cannot attack any internal military systems.

A-6.9 The use and configurations of IEG, imple-mented to interconnect military networks and other external communications infrastructures, is described in detail in multiple NATO docu-ments, including the NATO C3 Interoperability Handbook for Expeditionary Operations [Ref 36].

A-6.10 Such interfaces will have to be formally accre-dited by the proper certification bodies. These accreditations may be challenging in the SOA (Service Oriented Approach) context of SWIM. Actually, the underlying concept of accredita-tions is based on a fixed, stable product, which conflicts with the agile and evolutionary aspects of SOA.

A-6.11 R&D efforts are expected to completely define and validate an interface model, which consists in specifying ICDs (API-ICD, Wire-ICD) between IOP-middleware (interfaces between two middleware instances) and for the interfaces with the infrastructure. Such interfaces need to take into account all possible alternatives for the military to connect to SWIM, depending on the services supported and local conditions. This will comprise B2B profiles or interoperable ones through IP backbone/VPNs.

A-6.12 When the chosen connectivity option is for mili-tary systems to participate in IPv6 virtual private networks (VPN)52, military access to SWIM can be direct or via another regional or local network (e.g. ANSP) that influences the inter-facing options. This interfacing definition must start from the description of specific military protocols to delineate potential encapsulation strategies.

49 The FOIPS model defines the “Flight Object”. It is composed of two complementary models: an ‘analysis model’ and a ‘usability model’. The analysis model is a UML model of the flight object, defining a standard set of services that it must provide. The usability model defines a set of access rights that determine under what conditions each stakeholder can call on the services defined in the analysis model. The usability model also defines a set of “distribution clusters” that define the sub-components of the Flight Object that will be distributed and under what conditions.

50 If the use of internet is authorised for the type of information in question51 Experience of the IEG model has been successful in particular in the NATO Response Force, where networks of different classification levels

(NATO Secret, Mission Secret, etc.) are interconnected52 In the context of PENS or other IP networks


Interoperability Targets

A-6.13 The longer-term interoperability initiatives will consider:

n The widespread use of B2B and B2C web interfaces that will support a wide range of client applications, namely those that are not operationally critical

n A full PENS IPv6 environment providing backbone support to SWIM

n Extensive reliance on AIXM to enable systems to exchange aeronautical information in the form of XML encoded data. It will enable dynamic context based on the retrieval/delivery of aeronautical Information as opposed to the current semi-automated AIS

n Flight data management fully based on UML-driven Flight Object concepts to allow disparate systems from different suppliers, from within different organisations with different viewpoints to share information. NB, FO cannot be supported by legacy AFTN/CIDIN networks and requires IP and AMHS support

n Surveillance data broadly shared using integrated surveillance systems (e.g. Surveillance Data Distribution System – SDDS)

n Trajectory Management functions that will play a major role in future ATM concepts.

Security

A-6.14 The military should agree to connect their systems to SWIM if two conditions are met. Firstly, if the military are able to apply their own security policy (generally based on own safeguard mechanisms and measures). Secondly, if the military are involved in the definition of overall SWIM security policy and have confidence in its enforcement.

A-6.15 A significant difference between the military and civil participants may be the way security issues are addressed: The four main security topics are the following:

n Penetration (protection against unauthorised access) - The military will need assurances that their systems will not be exposed to the risk of intrusion via the SWIM node, which could result either in the disclosure of classified information or in the unavailability

of their systems. The typical military approach on this matter differs from the civil approach and may need to be taken into consideration when connecting to SWIM (probably raising SWIM security levels).

n Confidentiality (information protection) - Obviously, the military will prevent the dissemination of classified information in SWIM. This requires adequate information filtering on the publishing side and a fine-grained access control when answering requests. This requirement has to be implemented on the military side and does not depend on SWIM security.

The military may also publish non-classified information which might still be sensitive in some situations. The military will therefore need assurances about the non-disclosure of this information outside the group of users who need to know it. The protection of sensitive information depends here on internal SWIM security and on the protection of information in the civil system where it is processed.

n Data Integrity - Information exchanged over SWIM needs to be trustworthy. Data integrity provisions protect information against unauthorised modification during its exchange and processing. A military SWIM node needs to be able to verify the integrity of the information received.

n Availability - Maintaining a high level of availability is obviously a major concern for the military. This implies in particular being able to protect military systems against denial of service attacks.

A-6.16 When military systems exchange information with SWIM, the security principles described above apply. The SWIM ConOps recognises that initial SWIM design will not comprise a particular component dedicated to the security and authentication functions (except PKI). Nevertheless, it is expected that SWIM security and authentication policies and standards will be defined in due time.

A-6.17 In any case, without prejudice to internal SWIM security measures, the overall definition, accreditation and management of security mechanisms and practices associated with a node interconnecting a military system to SWIM must remain primarily under the ownership and supervision of military authorities.

b-1 State Aircraft Fleet (ECAC)53

b-1.1 Military aircraft fleets in European states comprise a huge variety of aircraft types and variants, depending on the military missions. There is a trend for a steady decrease, which can be identified as dropping from 13,344 aircraft in 2003 to 9,360 in 2012. Table C-1 presents the number of State aircraft in the inventory of ECAC states in 2012.

b-1.2 The U.S military aircraft fleet comprises more than 13.000 aircraft and the main impact on European ATM comes from the AMC (Air Mobility Command), which arrives in European airspace from many places of origin (but mostly from the US). There are also hundreds of U.S. aircraft stationed in Europe.

b-2 State Aircraft Flying

b-2.1 When establishing a relation between the military fleet and the need to fly as GAT, it seem that only a small portion of aircraft requires GAT capabilities. This is not, however, the case since all military aircraft need unrestricted access to all airspace and airports.

b-2.2 The current percentage of GAT/IFR flights conducted by State aircraft represents around 2% of the total, reaching an absolute number of around 180,000 flights/year according to CFMU/IFPS flight plan figures.

b-2.3 This low percentage of GAT flights proportionally has a much higher impact on airspace usage than civil airspace user flights. A small number of military flights can have a huge impact on airspace, as just a few flights may require huge reserved areas and also because non-equipped aircraft subject to special handling may need to be accommodated.

b-2.4 This situation is clearly illustrated by the GAT/IFR flights conducted by State aircraft with a lower level of capability or equipage exemptions. Non 8.33 kHz equipped State aircraft accessing the airspace where the carriage of VHF 8.33 radios is mandatory implies special handling on UHF or VHF 25 kHz, which increases ATC workload and may reduce sector capacity. The same applies to non-RVSM-approved State aircraft flying within RVSM airspace and getting 2000 ft separation. Other examples are B-RNAV, P-RNAV, Mode S, etc.

b-2.5 Some State aircraft flights contain GAT and OAT segments, which add complexity in terms of airspace impact. Moreover, there are around 3,000,000 OAT flights per year.

b-2.6 Almost 60% of military GAT flights in the ECAC region are flown by transport-type aircraft and, therefore, the ATM impact of transport-type aircraft may be classified as high. Fighters may be classified as having a medium impact because, despite accounting for a lower number of flights, they often trigger major airspace segregations and need to fly under exemption/special handling conditions. Light aircraft and helicopters account for approximately 18% of all flights, mainly in the vicinity of military aerodromes.

90

ANNEX B

MILITARY AIRCRAFT FLEET AND CNS EQUIPAGE CONSIDERATIONS

Table b1. State Aircraft Fleet (ECAC) - 2012

Aircraft Type Inventory

Combat aircraft (Fighters) 3417

Large aircraft 989

Light aircraft 1424

Helicopters 3800

ToTAL 9360

53 Source: EUROCONTROL Military Statistics Brochures


ANNEX C

AIRCRAFT SYSTEM INTEGRATION CONSIDERATIONS

C-1 Introduction

C-1.1 Future ATM concepts call for the prevalence of aircraft-centric views, with multiple functionali-ties intertwined, relating both to the exchange and processing of information. Avionics are taking on a growing importance and have a fundamental role to play in the design of future concepts. Particular attention needs to be paid to substantiating aspects like the use of airborne computers (Flight Management Systems - FMS or Military Mission Systems – MMS), the intro-duction of initial and full 4D functions in relation to trajectory management with flight control/flight guidance, new separation modes, some human-machine interface issues and the use of navigation data bases. This annex also includes some aircraft equipage information useful in interoperability discussions.

C-1.2 A key requirement derived from future ATM concepts is the need to ensure the capability to synchronise airborne and ground system trajec-tories and to make available during the flight,

through data link, the trajectory computed onboard. The enablers to exchange such data have been discussed in previous sections.

C-1.3 Advanced ATM concepts rely heavily on the use of advanced navigation capabilities and shared data to enable lateral/vertical/longitudinal trajectory management. The concept itself sets challenges for the direction of future navigation capabilities.

C-1.4 Key military aviation assumptions are that during baseline (see [Ref 39]) and step 1 periods only modern military transport-type aircraft will be impacted by limited trajectory requirements, following the same approach as commercial mainline aircraft (with adapted schedules). For steps 2 and 3, other aircraft types may be accommodated in trajectory structures, mainly on the basis of existing capabilities and ground interface support.

C-2 Aircraft Systems Functional breakdown

Figure C-1. Aircraft Systems Functional breakdown

92

C-2.1 Flight Management: This functional block encompasses both the in-flight and the surface portions of the trajectory. Management of the in-flight portion of the trajectory determines the trajectory on the basis of defined points and structures in a navigation database esta-blished from formally published aeronautical information. It may be lateral (2D), vertical (3D), and time-based (4D) and it provides the main guidance for control instructions to maintain the trajectory (the latter two involve speed guidance as well), depending on the aircraft functionality implemented. Other Flight Management functions are aircraft performance, predictions, and optimisations. In a military aircraft, the Flight Management Function, where it exists, can be implemented either in an FMS (Flight Management System) or be part of an MMS (Mission Management System), which also performs military-specific functions (e.g. threat assessment, weapon delivery, etc.). The surface portion of the trajectory is currently controlled by pilots on the basis of digital airport maps and airborne traffic and surface situation awareness.

C-2.2 Flight Guidance: This involves controlling aircraft along their trajectory, encompassing several modes, ranging from the highly auto-mated to the barely automated.

C-2.3 Positioning: This involves the aircraft system determining its evolving 4-dimensional position. It is a low-level function which is key to both of the above functions and to ATM. It requires external or aircraft local infrastructures and information for the positioning signals (GNSS, radio navigation, autonomous aircraft: inertial). Military aircraft may use specific positioning signals (e.g. restricted GPS/PPS or dedicated NAVAIDS) to achieve the positioning function.

C-2.4 Traffic: This encompasses 3 different aspects of traffic surveillance. ATC surveillance, where through a surveillance infrastructure ATC inde-pendently establishes the aircraft situation with transponder signals54 and/or with aircraft-derived information. Airborne traffic situation awareness (ATSAW55, which relies on the receipt of aircraft-aircraft broadcast data (ADS-B Out and In). In the present situation, military aircraft are not equipped with ATSAW. The equivalent

military systems, based on tactical data links or on-board sensors, are not yet certified for ATM usage. Airborne Collision Avoidance System (ACAS), which provides advisories and resolution manoeuvres as a last resort safety net (in the case of a traffic separation failure e.g. undetected or incorrect flight manoeuvre or deviation).

C-2.5 Weather: Weather information and hazard detection, which is an autonomous aircraft function for short-term detection of hazardous weather / hazardous atmospheric conditions.

C-2.6 Terrain: This functional block encompasses terrain awareness and avoidance resolutions to avoid terrain encounters. It is a safety net in the event of an incorrect flight manoeuvre or devia-tion when in proximity with terrain (mostly in certain approach conditions). It should be noted that ATM navigation services and trajectories are designed in association with a navigation perfor-mance and protected from terrain through structured routes and altitude minima.

C-2.7 Air-Ground Data Link: This represents the widely recognised term used in standards and requirements for the aircraft function. It repre-sents the data link services, for ATC to aircraft transactions (e.g. clearances, traffic and flight/airport/weather information56), for airline/AOC to aircraft transactions, and mobile data exchange applications and data protocol mechanisms. In today’s situation, most military aircraft do not support aircraft to ATC transac-tions (except few recent transport-type State aircraft). The data links that equip a growing number of military aircraft allow the aircraft to interface with Command and Control centres. In the future, some ground interfaces may enable that information to be exchanged with ATC.

C-2.8 broadcast Data: This represents the basic support for aircraft to aircraft, or aircraft to ground unsolicited broadcast data – this is the ADS-B function. The current baseline is supported by the transponder Mode S 1090 ES (extended squitter).

C-2.9 Voice: Voice mobile communications (of 2 basic types:short-range/continental, long range/remote-oceanic).

53 The transponder function is a baseline capability, which provides a response to an ATC SSR interrogation – no further development is foreseen.53 The opportunity to consider ATSAW as As-Is still needs to be clarified (the availability of ADS-B in as well). However, as no dedicated OIs

match to this capability, the definition has been kept as such for the time being. This will be improved in a later version of the document53 This encompasses ATM weather / meteorological information service provided to the aircraft operator/crew. Such information is taken into

account in flight trajectory (planning and execution) and accessibility for departure and arrival. The current system baseline provides such information through basic information means (reports, voice broadcast, a single simple ATIS datalink application). Additionally the airline operations can provide updated weather/meteorological information to the aircraft/flight crew (wind/temp, etc.).


C-3 Military Aircraft Architecture Aspects

C-3.1 If conclusions are to be drawn on civil-mili-tary CNS interoperability opportunities, it is important to ascertain the extent to which the above-mentioned functions are supported in military aircraft. There is a wide variety of military aircraft types, models, variants and upgrades and their specific roles or missions require very dissimilar architecture configura-tions. Nevertheless, the functional architectures of some military aircraft can be compared with civil mainline aircraft as far as ATM/CNS components are concerned. Additional func-tions fulfilled by military aircraft, specific to their mission, are not of interest for ATM/CNS. As regards the data-processing capabilities needed for trajectory management, the following diffe-rences can be identified as examples (significant differences can be noted, depending on aircraft type and variant):

n SATCOM is not supported on most platformsn Voice communications are supported by

both VHF and UHF radiosn Military communications are supported by

specific data link technologies on HF and UHF frequencies that allow secure data and voice exchanges

n GPS on military platforms relies on PPS, thus providing a more accurate positioning than SPS

n Some platforms may not support navigation based on VOR

n Military platforms support navigation based on GPS+IRU/INS and TACAN. Specific military sensors like GPS PPS and TACAN are not PBN eligible

n Landing systems usually rely on MMR, which incorporates ILS, MLS and Differential GPS, which is very similar to GBAS technology. A future JPALS concept will streamline this area with civil evolution

n The coupling of IRU is only specified for IRU/DME/DME, while the military usually hybridize IRU with GPS PPS

n Only a few military transport aircraft use DME/DME to update IRU or INS, sometimes without an automatic updating function

n The IRU by itself does not raise performance problems. Compliance with A-RNP could require the carriage of 2 eligible sensors

(GNSS and DME/DME) and a redundant RNAV computer (problematic on combat aircraft or jet trainers)

n The need for additional functioning modes (PPS lock-out mode) with an SPS/PPS selector should be assessed in order to avoid unnecessarily complex and costly receiver architectures

n The same considerations would apply for GALILEO PRS receivers, whether or not in combination with GPS PPS

n The TACAN transceiver could be used instead of DME for positioning updates, but no “scanning TACAN” is able to support an automatic update function. The performance of TACAN transceivers should be investigated in the light of civil standards

n For aircraft without DME/DME function (e.g. combat aircraft), the use of radar fixing, Terrain Reference Navigation or the MIDS PPLI message to update the IRU has never been investigated

n The eligibility of military GPS as a means of compliance would considerably alleviate the impact severity of PBN requirements on military aircraft

n On many military aircraft, the absence of navigation database is identified as the major difficulty

n Military navigation computers offer limited capabilities in terms of path computing since they usually comply with only a few ARINC 424 path terminators

n Flight plan management represents another difficulty as regards compliance with ARINC 424. Usually the flight plan can accept insertion of Way Points (WPTs) but not a complete sequence of WPTs, as is required

n Way Point (WPT) formats are not standardized in military navigation computers, which usually cannot recognize the ARINC 424 format and data structure (e.g. en-route WPT, APT or RWY etc.)

n Possible mitigation means to be investigated could include use of the mission planning system (MPS) used in conjunction with the aircraft mission computer to handle the ARINC 424 data

n The MPS would translate the ARINC 424 into appropriate paths coded with a format recognised by the aircraft navigation computer

n Such mitigation would imply manually handled in-flight tactical changes with

94

possible manual creation of WPTs in the flight plan, which is not an allowed method in PBN requirements

n The definition of a “minimum reduced” set of path terminators to be implemented could help to overcome some limitations

n The functions required by A-RNP (VNAV and RTA) raise severe problems on aircraft that do not offer a basic vertical navigation mode. This would require important modifications of the aircraft itself in addition to the navigation system modifications

n Fighter aircraft altimetry systems are subject to important altimetry system error (ASE) variations due to changes in external configuration. VNAV and RTA should be considered as hard points.

n Insufficient capabilities of the old generation of CRT displays to show the flight plan path and, in particular, curved trajectories like RTF or offset

n Old-generation displays may not be capable of the VNAV function

n Use of the head-up displays (HUD) is increasingly considered as primary flight display and is able to accurately provide the required navigation information for the active leg

n IFF antennas replace Mode S antennas, since they work on the same frequencies. IFF can be considered as a military transponder, enabling identification of friendly aircraft, but using encrypted codes; Mode S is supported on some IFF models.

C-3.2 Modern transport-type and fighter avionics architectures evidence sensors connected by data buses to support necessary data flow between equipment. Bus systems can comprise either a single bus or, more generally, multiple buses. Typically, the standard used is MIL-STD 1553 B. Navigational functionalities typically reside in a Mission Computer (MC).

C-3.3 Although it is difficult to identify common archi-tecture principles for multiple platforms, it is important to highlight that the state-of-the-art Integrated Modular Avionics architecture (IMA) used for mainline aircraft derive from military programmes. IMA was first developed in the context of the modern fighter programme in

the U.S., which is the basis for the principles provided below. It is now widely used by Airbus and Boeing and for multiple military aircraft. The IMA architecture was built from common components. It became the most important architecture principle for aircraft avionics. These components are specified in separate standards.

C-3.4 The IMA Core System can be defined as a set of

one or more racks comprising a set of standar-dised modules communicating across a unified digital network. The IMA Core System process inputs are received from the platform’s low and high bandwidth sensors.

C-3.5 The IMA Core System can be viewed as a single entity comprising many integrated proces-sing resources which can be used to construct any avionics system regardless of size and complexity. The concept of the IMA Core System is therefore equally applicable to smart missiles, UAVs, fast jets or large military aircraft.

C-3.6 Digital processing that occurs within the IMA Core System includes all the typical functional applications normally associated with avio-nics platforms: vehicle management, mission management, stores management, CNI, target detection & tracking, HUD & HDD displays, etc. The unified network used as the communication medium within the IMA Core System is also used to enable the functional applications to commu-nicate with the platform’s sensors and effectors. This communication is made possible by the use of interfaces with the network.

C-3.7 The main conceptual difference between the IMA Core System and the Line Replaceable Units of current federated systems is that the functional application software does not continue to reside on the modules on which it is ultimately to be processed. In the IMA Core System, all software is held on mass memory-storage devices and downloaded to the modules upon which they are to execute as part of the system initialisa-tion and configuration processes. This concept is instrumental in deferring maintenance and ensuring that modules can be replaced during first line maintenance. The essence of IMA is to use a minimum set of common parts: Common Functional Modules, software and interfaces.


C-4 Military Mission System/Mission Computers Typical Capabilities

C-4.1 Military aircraft might have specific flight control/flight guidance means which should be verified in terms of timing precision. The trajec-tory management function for military aircraft might have to be supported by military mission systems similar to FMS or emulated by ground systems. This is the aspect that will warrant the fullest attention in future R&D.

C-4.2 Military aircraft are typically equipped with a Mission Computer (MC). The MC enables the crew to create flight plans, store them, retrieve existing plans, make alterations and make new plans by modifying the existing ones. Once a particular flight plan is to be executed, the MC calculates the parameters, and provides ETA and ETE along the route with estimated fuel burn rates. En-route changes to the active flight plan can be added at any time.

C-4.3 The flight plan and data are displayed on the control panel display. The MC provides the capa-bility to plan and execute flight plans worldwide. The MC allows the crew to call up depar-ture runways for the selected airport, select a Standard Instrument Departure (SID) from a list of related SIDs and then the transition method from a list of transitions. The MC also allows the crew to call up arrival runways for the selected airport, select a Standard Terminal Arrival Route (STAR) from a list of related STARs and then the transition method from a list of transitions. Finally there are the STAR review pages that are used to display the legs of the STAR in a sequen-tial manner. The Mission Computer provides the capability to store navigation data to or load data from the navigation database.

C-4.4 While navigating the aircraft, the pilot can access performance pages. They are used to enter initial values for computing aircraft perfor-mance for the flight and generating cues. The Mission Computer generates and displays navi-gational solutions for selectable navigation modes. The MC is able to calculate and provide

Lateral Navigation (LNAV) guidance and Vertical Navigation (VNAV) guidance during non-precision approaches. The Mission Computer computes and displays guidance information relating to the active waypoint in the active flight plan.

C-4.5 The flight plan is created by the flight crew by manual entry, by transferring alternate flight plan waypoints to the active flight plan, or by retrieving a stored flight plan from the stored route list and transferring that data to a flight plan. Mission-specific operations can be prepared, reviewed, and edited.

C-4.6 A typical transport-type aircraft MC is able to store about 200 waypoints. Waypoints consist of locations entered as latitude/longitude coordinates, Military Grid Reference System (MGRS) coordinates, reference point identifiers (IDENT), or by five character IDENT/bearing/distance which is an identifier that is amended by the specific bearing and distance. In addition, operator-selected identifiers can be inserted for waypoints other than reference point database waypoints.

C-4.7 Once an active flight plan has been entered, the FMS provides the capability to make special edits to the flight plan, to add various attributes to waypoints, and to perform a variety of func-tions. The MC provides an interface for the pilot/co-pilot flight instruments and the AP/FD. The MC provides selectable solutions for guidance and signals to drive the pilot and co-pilot flight directors and flight instruments.

C-4.8 Guidance parameters are based on actual or planned navigation parameters and desired time of arrival at designated waypoints or Mission Flight Plans (MFPs). Actual guidance parameters are based on an «active» flight plan. The MC provides the means for the flight crew to define a non-precision Area Navigation (RNAV) approach with lateral and vertical guidance capability. The definition includes the final approach fix, Missed Approach Point (MAP), minimum descent altitude with touchdown zone elevation and descent path angle.

96

C-5 Flight Management System (FMS)

C-5.1 When existing as an independent component, the Flight Management System (FMS) provides electrical interfaces, interface control and flight management processing. For redundancy, each FMS has full functionality and calculates its own navigation solutions independently, comparing its solutions with the other FMS. Either FMS can perform all navigations function alone, should the other FMS fail. It controls operating parame-ters for the following functions: flight planning, navigation database management, airfield and in-flight performance lateral guidance, vertical guidance and calculation of navigation solu-tions. The FMSs integrate all outputs coming from all other CNS equipment, and perform all the calculations necessary to manage the communications and navigation functions. The MCs provide the FMS with necessary inputs and send FMS outputs to other aircraft devices that need CNS information.

C-6 Communication and Sensor Equipment

C-6.1 Communication between aircraft and ground is possible through voice communication radios and data links. Voice communication radios are V/UHF and HF radios in order to assure LOS and BLOS voice communication. Data link commu-nications are supported by VHF data link radios supporting VDL Mode 2 protocols or military data links.

C-6.2 Sensors are the equipment able to provide data to onboard computational equipment (i.e. MC and FMS) and to communication systems (i.e. VDL Mode 2 radio). Sensors are for example:

n INS (Inertial Navigation System) with gyros and accelerometers

n GPS (Global Positioning System) used to fix INS drift errors

n TACAN (Tactical Navigation) n VOR (VHF Omni-Range) n DME (Distance Measurement Unit)n ADS (Air Data System)n Radar Altimetern TCAS (Traffic Alert and Collision Avoidance

System)

n TAWS (Terrain Avoidance Warning System)n ILS/MLS (Instrumental Landing System/

Microwave Landing System)

C-6.3 These sensors are able to provide informa-tion about position, angles, angular and linear velocities and angular and linear accelerations. These data are generated for the purposes of navigational performance and guidance. A FOM (Figure of Merit) is associated with data from sensors.

C-7 Communication and Sensor Equipment

The Autopilot Control Panels interface with the Digital Autopilot/Flight Director (DA/FD) System through MIL-STD-1553B Buses. One shipset of Autoflight Control Panels consists of five individual Line Replaceable Units (LRU) encompassing edge lighted panels. The system consists of two (pilot and co-pilot) Heading/Course Select Panels, two (pilot and co-pilot) DA/FD Reference Set/Warning Panels, and one DA/FD Control Panel.

C-7.1 There are various Multi Function Displays (MFD) located on the main instrument panel of military aircraft in front of the pilot and co-pilot positions. Typically, there are two PFD (pilot and co-pilot) and two Navigation Displays (pilot and co-pilot) and two central system displays where aircraft status parameters are showed. All displays are multipurpose displays and so the pilot can decide the information to be shown in each display.

C-7.2 The Multipurpose Control Display Units (MCDUs) provide the primary operator inter-face via an alphanumeric keyboard, mode select keys, line select keys, annunciators, and a flat panel display. The two MCDUs are redundant to each other, and both MCDUs can communi-cate with either MC. The crew may operate any MCDU at any time, call up different pages on the MCDUs without affecting what appears on the other, and override the default operation. Synchronization of data between the MCDUs is handled by the MC.

C-7.3 The systems are interconnected to allow access and control of nearly all flight plan management parameters, as long as one MC and one MCDU are available. The communication radio mana-gement function acts through MCDU as the control for the VHF/UHF, and HF communication


radios and VHF datalink radio. The navigation radio management function acts through MCDU as the control for the TACAN, VOR, and LF-ADF navigation radios. The MCDUs are also used to control the IFF transponder, to select SAR, and rendez-vous functions. The Communication Management Display (CMD) may also be used to tune communication and navigation radios. The MCDU could operate as contract manager for the ADS-C and CPDLC application functionality by receiving data from the FMS and providing to the CMD the data requested by the interro-gation. It also provides access to the CMD and SATCOM controlled pages.

C-7.4 The Communication Management Display CMD is used to reduce pilot workload associated with the MCDU, and to provide pilots with a head up means of using the radios. CMD provides the pilots with an alternative way of tuning the communications and navigation radios. The CMD can access the scratchpads of the CMD, the co-pilot MCDU, and the pilot MCDU. The CMD is also capable of using the FMS database to tune navigation radios. To tune the database, the identifier of the navigation aid is entered into the co-pilot or pilot MCDU scratchpad and the CMD line select key corresponding to the desired navigation radio is pressed. A single navi-gation frequency, channel, or database entry can be entered into more than one navigation radio (such as setting both VORs to the same ILS frequency) by selecting the radio with the desired setting. The CMD can also control the IFF modes.

C-7.5 CMD provides the possibility of controlling VDL Mode 2 Radio. ADS-C contracts are managed with this control panel as well as the uplink and downlink CPDLC messages which are visualized in association with CMD.

C-7.6 IFF Control Panel consists of a control panel identical to the CMD but dedicated only to IFF. IFF Control Panel can be used as an alternative way of controlling CMD. The IFF control panel provides the pilot with power control, mode control, mode test control, code selection, and zeroize control. Available civil surveillance trans-ponder modes are: 3/A, C, S ELS/EHS. Military IFF Modes are: 1, 2, 4, 5.

C-7.7 The Digital Autopilot/Flight Director (DA/FD) system interfaces with the autopilot system control panels as well as the other compo-

nents of the avionics system. Two identical and interchangeable DA/FD Automatic Flight Control Processors (AFCPs) are connected to the aircraft avionics 1553B data buses. A Mission Computer (MC) is the bus controller for the 1553B bus structure. The MC controls the data required for operation of the DA/FD System. The output commands are routed through swit-ching relays to the pitch, roll, and yaw axis DA/FD servo motors. These servo motors drive their respective DA/FD drum and bracket assemblies, which are connected direct to the flight control system. The industrial baseline DA/FD System also supports the ability to interface and control an auto throttle servo.

C-7.8 Each data bus consists of two independent pairs of bus lines labelled left and right. Bus commu-nications are controlled by a Bus Controller (BC) which controls the flow of information transmitted across the bus to and from all the equipment on the bus. Remote Terminals (RTs) are devices which generate or receive the data available on the bus under the direction of the BC. The BC controls data flow across the bus by sending commands specifically addressed to individual RTs. The RTs, upon receiving a command addressed to them, transmit or receive the desired information. All buses have Backup Bus Controllers (BBC) which perform the same functions as the RTs until the BC fails, and then the BBC assumes control of the data bus and functions as the BC. The crew is alerted to a BC failure by a specific message; however data bus performance is not degraded in the event of a BC failure, since all buses have BBCs. The main challenge is to ensure that sensors can be accessed through the available bus to make the information available where needed.

C-8 Mapping between Military Aircraft Capabilities and ATM/CNS Needs

C-8.1 Comparing the above-described military aircraft generic capabilities with the technical require-ments associated with ATM/CNS functions may be the right approach to determine perfor-mance-based interoperability opportunities. The results of this mapping exercise are generated in several SESAR R&D projects on Interoperability Between Business and Mission Trajectory.

98

ANNEX D

STANDARDISATION ORGANISATIONS AND MATERIALS

organisation Role Products Scope

ICAo - International Civil Avia-tion Organisation

ICAO ensures that international civil avia-tion is developed in a safe and orderly manner.

SARPS - Standards and Recommended Practices

Guidance Material

GlobalCivil

EASA - European Aviation Safety Agency

EASA promotes common standards for safety and environmental protection in civil aviation. It has taken over some certi-fication responsibilities within EU.

AMC/GM - Acceptable Means of Compli-ance/Guidance MaterialCS - Certification Specifications forETSo - European Technical Standard Orders

EuropeCivil

JAA - Joint Aviation Authorities JAA is an associated body of ECAC, representing the civil aviation regula-tory authorities of a number of European States, developing and implementing common safety regulatory standards and procedures.EASA is expected to absorb all JAA functions.

JAR - Joint Aviation RequirementsA&GM - Administrative and Guidance Mate-rial including Temporary Guidance Leaflets (TGL)NPA - Notice of Proposed Amendments

EuropeCivil

EuRoCAE - European Organisation for Civil Aviation Equipment

EUROCAE is a stakeholder organisation developing specifications for airborne electronic equipment.

ED - EUROCAE Documents including:b) MOPS: Minimum Operational Perfor-

mance Specificationc) MASPS: Minimum Aviation System

Performance Specification d) Guidelines

EuropeCivil

EuRoCoNTRoL - European Organisation for the Safety of Air Navigation

The EUROCONTROL Convention provides for a regulatory role, which enables the organisation to produce rules and advisory material like Specifications and Guidelines

ESARRS - EUROCONTROL Safety Regulation Requirements

EuRoCoNTRoL Standards

EuropeCivil-Mili-tary

ESo - European Standardisa-tion Organisations

ETSI, CEN and CENELEC have been desig-nated by EC as the recognised ESOs

CS - Community Specifications (developed under a Mandate given by the European Commission)

EuropeCivil

RTCA - Radio Technical Commission for Aeronautics

RTCA develops consensus-based recom-mendations regarding CNS/ATM systems

Do ### - RTCA DocumentMoPS - Minimum Operational Performance Standards

Technical Guidelines

USCivil

ARINC - Aeronautical Radio, Inc The airline industry’s coordinator for radio communication and systems engineering

ARINC ###ARINC System Specifications

USCivil

SAE - Society of Automotive Engineers

SAE is a technical forum for standards related to self-propelled air and other vehicles.

SAE standards and publications GlobalCivil

FAA - Federal Aviation Admin-istration

The FAA’s mission is to improve the safety and efficiency of aviation and to provide the safest and most efficient aerospace system

FAR - Federal Aviation RegulationsAD - Airworthiness DirectivesTSo - Technical Standard OrderMSo – Military Standard Order

USCivil-Mili-tary


REFERENCES

[1] EUROCONTROL Civil-Military CNS/ATM Interoperability Roadmap, Edition 1.0 dated 03 January 2006

[2] EUROCONTROL Guidelines – Minimum CNS Infrastructure and Avionics Equipage for the Support of OAT Harmonisation, Eurocontrol GUI-0110, Edition 2.0, 17 March 2008

[3] ICAO Global Air Navigation Capacity & Efficiency Plan (GANP) 2013-2028, Document 9750

[4] Regulation (EC) No 552/2004 of 10 March 2004 on the interoperability of the European Air Traffic Management Network (the interoperability Regulation)

[5] EUROCAE ED-133 – Flight Object Interoperability Specification, 02/2009

[6] Regulation (EC) No 633/2007 of 07 June 2007 laying down requirements for the application of a flight message transfer protocol used for the purpose of notification, coordination and transfer of flights between ATC units

[7] EUROCONTROL SPEC-0136 Ed 2.0 of 18 September 2009 - EUROCONTROL Specification on the Air Traffic Services Message Handling System (AMHS)

[8] Regulation (EC) No. 1032/2006 of 06 July 2006 laying down requirements for automatic systems for the exchange of flight data for the purpose of notification, coordination and transfer of flights between air traffic units

[9] Eurocontrol Specification for On-Line Data Interchange (OLDI) Edition 4.2

[10] ICAO Document 9896 ATN/IPS Technical Manual, Applications and Guidance

[11] EUROCONTROL Interoperability Control Document for IP Support of LARA Systems, Edition 1.0, 08 June 2010

[12] Regulation (EC) No 1265/2007 of 26 October 2007 laying down requirements on air-ground voice channel spacing for the Single European Sky

[13] Regulation (EC) No 1079/2012 of 16 November 2012 laying down requirements for voice channel spacing for the Single European Sky

[14] EUROCONTROL Guidelines on the Use of UHF for ATC, GUID-138-2009, Edition 1.0, 02 June 2010

[15] ICAO Frequency Management Manual (Doc. EUR-011)

[16] ICAO Global Operational Data Link Document (GOLD), 2nd Edition, 26 April 2013

[17] Regulation (EC) No. 29/2009 of 16 January 2009 laying down requirements on data link services for the Single European Sky

[18] EUROCONTROL Communications Operating Concept and Requirements for the Future Radio System (COCR) Version 2.0

[19] Common Action Plan 17 on Future Communication Systems included in the Revised Memorandum of Cooperation (MOC) between the FAA and EUROCONTROL, 01OCT04

[20] NATO Position on Controller-Pilot Data Link Communications, AC/92-D(2011)0003, 11 April 2011

[21] NATO Position on Using Tactical Data links to Interface with Civil Data link Requirements, document AC/92(EAPC)D(2013)0002, 14 January 2013

[22] ICAO Doc 9613, Performance-based Navigation (PBN) Manual, AN/937, 3rd Edition, 2008

[23] EUROCONTROL Policy on GNSS for Navigation Applications in the Civil Aviation Domain SCG Action Paper SCG/8/AP10, 28/04/2008

[24] ICAO Document 7030 – EUR Regional Supplementary Procedures (SUPPS)

[25] NATO Position on Future Use of TACAN, AC/92-D(2011)0005, 23 June 2011

100

[26] Regulation (EC) No. 1206/2011 of 22 November 2011 laying down requirements on aircraft identification for surveillance for the Single European Sky

[27] Regulation (EC) No. 1207/2011 of 22 November 2011 laying down requirements for the performance and interoperability of surveillance for the Single European Sky

[28] Updated NATO Military Position on Mode S - MCM-197-04, 7 October 2004, distributed under AC/92(CNS)N(2004)0006, 21 October 2004

[29] NATO Position on Automatic Surveillance-Broadcast (ADS-B), AC/92- D(2011)0002, 11 April 2011

[30] EUROCONTROL Policy guidance for the exemption of state aircraft from compliance with specific aircraft ATM/CNS equipage requirements, March 2003

[31] UK MoD Systems Engineering Handbook, June 2009

[32] ISO 15288: Systems Engineering – System Lifecycle Processes, 1st Ed, 2002

[33] Integrated Logistics Support Handbook, James V. Jones, McGraw-Hill Logistics Series

[34] NATO C3 Agency Technical Note on ADS-B Exploitation and Spoofing Vulnerabilities and Mitigation Options, April 2009

[35] NATO Architecture Framework – Chapter 3 NATO Network Enabled Capability (NNEC) Architecture Concepts and Elements, AC/322-D(2007)0048-AS1, 23 November 2007

[36] NATO C3 Interoperability Handbook for Expeditionary Operations, AC/322-N(2009)0037-REV1, 24 July 2009

[37] EUROCONTROL Introduction to Mission Trajectory, Edition 1.0, 25 May 2010

[38] EUROCONTROL Mission Trajectory Detailed Concept, Edition 1.0, 22 October 2012

[39] EUROCONTROL Website - Avionics Requirements Web Pages (http://www.eurocontrol.int/articles/avionics-requirements)


GLOSSARY

Abbreviations

SACARS Aircraft Communication and Reporting SystemACAS Airborne Collision Avoidance SystemACC Area Control CentreACCS Air Command and Control System (NATO)ACL ATC ClearanceACM ATC Communications ManagementAD Air Defence ADD Aircraft-Derived DataADEXP ATS Data Exchange ProtocolADF Automatic Direction FinderADS Automatic Dependent Surveillance (C - Contract, B – Broadcast)AECP Aeronautical European Common PositionAFTN Aeronautical Fixed Telecommunications NetworkAIS Aeronautical Information ServicesAIXM Aeronautical Information Exchange ModelAMC ATC Microphone Check; Acceptable Means of ComplianceAMHS Aeronautical Message Handling SystemANC Air Navigation Conference (ICAO)ANSP Air Navigation Service ProviderAoA ACARS over AVLCAoC Airline Operational CommunicationsAPI Application Programming InterfaceA-PNT Alternative Positioning Navigation and TimingAPV Approach Procedure with Vertical GuidanceAP17 Action Plan 17 of MoU between EUROCO)NTROL and FAA (Future Communications Study)ARNS Aeronautical Radionavigation ServiceASAS Aircraft Separation Assurance SystemASDE Airfield Surface Detection EquipmentA-SMGCS Advanced Surface Movement Guidance and Control SystemASTERIX All-Purpose Structured EUROCONTROL Surveillance Information ExchangeATC Air Traffic ControlATCo Air Traffic ControllerATFCM Air Traffic Flow and Capacity ManagementATIS Automatic Terminal Information SystemATM Air Traffic Management ATN Aeronautical Telecommunications Network (ICAO concept)ATS Air Traffic Services ATSAW Air Traffic Situational AwarenessAuToPS Autonomous OperationsAVLC Aviation VHF Link ControlAWACS Airborne Warning and Control SystembLoS Beyond Line Of SightbRLoS Beyond Radio Line Of Sightb-RNAV Basic RNAV (RNAV-5)C2 Command and ControlC3 (Political) Consultation Command and Control (formerly known as Command Control and

Communications)CASCADE Co-operative ATS through Surveillance & Communication Applications Deployed in ECAC

102

CDM Collaborative Decision-MakingCDMA Code Division Multiple AccessCEN Comité Européen de Normalisation / European Committee for StandardizationCENELEC Comité Européen de Normalization Electrotechnique / European Committee for Electrotechnical

StandardizationCEPT Conférence Européenne des Postes et TélécommunicationsCEN Comité Européen de Normalisation/European Committee for StandardizationCENELEC Comité Européen de Normalization Electrotechnique / European Committee for Electrotechnical

StandardizationCEPT Conférence Européenne des Postes et TélécommunicationsCFIT Controlled Flight into TerrainCFMu Central Flow Management UnitCIDIN Common ICAO Data Interchange NetworkCIS Communication and Information Systems (NATO)CNS Communications, Navigation and SurveillanceCoM CommunicationsCooPATS Cooperative ATSCoSEP Cooperative SeparationCoTR Coordination and TransferCoTS Commercial Off-The-ShelfCPDLC Controller-Pilot Data Link CommunicationsCTR Control AreaDAP Downlink Airborne ParametersD-ATIS Data Link ATISDCA Designated Controlled AirspaceDCL Departure ClearanceDGPS Differential GPSDLIC Data Link Initiation CapabilityDME Distance Measuring EquipmentDSC Downstream ClearanceEANPG European Air Navigation Planning Group (ICAO)EASA European Aviation Safety AgencyEASS European Aeronautical Spectrum StrategyEATMP European Air Traffic Management ProgrammeECAC European Civil Aviation ConferenceECC Exemption Coordination CellECG EATMP Communications GatewayECIP European Convergence and Implementation PlanELS Elementary Surveillance (Mode S)EHS Enhanced Surveillance (Mode S)EPP (ADS-C) Extended Projected ProfileERRIDS European Regional Renegade Information Dissemination SystemEuRoCAE European Organisation for Civil Aviation EquipmentEXTRA European Cross-Border Transport Network for ANSPsFAA Federal Aviation AdministrationFANS Future Air Navigation SystemFCI Future Communications InfrastructureFCS Future Communications StudyFDE Flight Data ExchangeFDPS Flight Data Processing System


FIS Flight Information ServiceFIXM Flight Information Exchange ModelFLIPCY Flight Plan ConsistencyFMS Flight Management SystemFPALS Future Precision Approach and Landing SystemsFPL Flight PlanFRuIT False Replies Unsynchronised in TimeFuA Flexible Use of AirspaceGA General AviationGAT General Air TrafficGATM Global Air Traffic Management (United States Air Force)GbAS Ground-Based Augmentation SystemGNSS Global Navigation Satellite SystemGPS Global Positioning SystemGPWS Ground Proximity Warning SystemHF High FrequencyHMI Human Machine InterfaceHTTP Hyper Text Transfer ProtocolIC Interrogator Code (Mode S)ICAo International Civil Aviation OrganisationICD Interface Control DocumentIER Information Exchange RequirementsIFF Identification Friend or FoeIFPS Initial Flight (Plan) Processing SystemIFR Instrument Flight Rules II Interrogator Identifier (Mode S code)ILS Instrument Landing SystemIMA Integrated Modular AvionicsINS Inertial Navigation SystemIP Internet ProtocolIRS Inertial Reference SystemISo International Standards OrganisationITu International Telecommunications UnionJAA Joint Aviation AuthorityJPALS Joint Precision Approach and Landing Systems JTIDS/MIDS Joint Tactical Information Distribution System/Multifunctional Information Distribution SystemJTRS Joint Tactical Radio SystemJTSo JAA Technical Standard OrderLAN Local Area NetworkLCIP Local Convergence and Implementation PlanLDAP Light Directory Access ProtocolMASPS Minimum Aircraft Systems Performance Specifications (ICAO)MEMS Micro-Electromechanical Systems (NAV sensors)MILT Military TeamMLS Microwave Landing SystemMMHS Military Message Handling SystemMMR Multimode ReceiverMNS Mobile Network ServicesMoPS Minimum Operation[al] Performance SpecificationsMoR Military Operational Requirement

104

MTCD Medium-Term Conflict DetectionNoTAM Notice to AirmenNSA NATO Standardisation AgencyMSSR Monopulse SSRMTCD Medium-Term Conflict DetectionNATo North Atlantic Treaty OrganisationNDb Non-Directional BeaconNPA Non-Precision ApproachoAT Operational Air TrafficoI/SE Operational Improvement/System Enabler (SESAR)oJEu Official Journal of the European UnionoLDI On-Line Data InterchangeoSI Open Systems InterconnectionPA Precision ApproachPALS Precision Approach and Landing SystemPAR Precision Approach RadarPENS Pan-European Network ServicesPfP Partnership for PeacePKI Public Key InfrastructurePNT Positioning Navigation and TimingPPS Precise Positioning ServicePRMG Approach and Landing Radio Beacon Group System (co-located with RSBN)P-RNAV Precision RNAV (RNAV-1)PSR Primary Surveillance RadarPTT Post, Telegraph and Telecommunications (telecommunication service providers or operators)QSIG Quality Signalling (Telephony Protocol)RADNET Radar Data Exchange NetworkRAIM Receiver Autonomous Integrity MonitoringRAP Recognised Air PictureRNAV Area NavigationRNP Required Navigation PerformanceRPA Remotely Piloted AircraftRSbN Radionavigacionaya Systema Bliznoj Navigacii (Tactical Navigation Azimuth/Range System)RSP Required Surveillance PerformanceRVA Recorded Voice AnnouncementRVSM Reduced Vertical Separation MinimaSAR Search and RescueSARPS Standards and Recommended Practices (ICAO)SATCoM Satellite CommunicationsSbAS Space-Based Augmentation SystemSDDS Surveillance Data Distribution System SDR Software-Defined RadioSI Surveillance Identifier (Mode S code)SMTP Simple Mail Transfer ProtocolSNDCF Sub Network Dependent Convergence FunctionSPS Standard Positioning ServiceSSR Secondary Surveillance RadarSTCA Short-Term Conflict AlertSuR SurveillanceSWIM System-Wide Information Management


TACAN (UHF) Tactical Air Navigation AidTCAS Traffic Collision Avoidance SystemTCP/IP Transmission Control Protocol/Internet ProtocolTDMA Time Division Multiple AccessTGL Temporary Guidance LeafletTIbA Traffic Information Broadcasts by AircraftTIS-b Traffic Information System – BroadcastTMA Terminal Manoeuvring AreauAS Unmanned Aerial SystemuAT Universal Asynchronous TransceiveruHF Ultra High FrequencyVCS Voice Communication SystemVDL VHF Data LinkVFR Visual Flight RulesVHF Very High FrequencyVoLMET Meteorological Information for Aircraft in FlightVoR VHF Omnidirectional Radio RangeVoRTAC VOR associated with TACAN for civil usageWAN Wide-Area NetworkWRC World Radiocommunication ConferenceWXXM Weather Information Exchange Model

106

Definitions

ADS-C Extended Projected Profile (EPP) ReportADS-C report containing the sequence of 1 to 128 waypoints or pseudo waypoints with associated contraints or estimates (altitude, time, speed, etc.), gross mass and estimate at Top of Descent, speed schedule, etc.

Approach Procedure with Vertical Guidance (APV)An instrument procedure which utilizes lateral and vertical guidance, but does not meet the requirements laid down for precision approach and landing operations.

A-RNP (Advanced Required Performance)Required Navigation Performance (RNP) is a type of performance based navigation (PBN) that allows an aircraft to fly a specific path between two 3-dimensionally defined points in space. RNAV and RNP systems are fundamentally similar. The key difference between them is the requirement for on-board performance monitoring and alerting. A navigation specifi-cation that includes a requirement for on-board navigation performance monitoring and alerting is referred to as an RNP specification. One not having such a requirement is referred to as an RNAV specification.RNP also refers to the level of performance required for a specific procedure or a specific block of airspace. An RNP of 10 means that a navigation system must be able to calculate its position to within a circle with a radius of 10 nautical miles. An RNP of 3 means the aircraft navigation system must be able to calculate its position to within a circle with a radius of 3 tenths of a nautical mile.The benefits expected with reduced route spacing enabled by Advanced RNP relate primarily to increased capacity and flight efficiency, as already demonstrated by two Real-Time Simulations (RTS) run by Eurocontrol. Using a traffic sample of fully A-RNP-equipped aircraft, controllers were more able to keep aircraft on flight-planned routes and, moreover, the opportunity to issue tactical parallel offsets reduced the need for radar-vectoring. Together, this led to a reduced need for tactical controller intervention, which in turn reduced the demands placed on air-ground communi-cation. These workload benefits were more distinct when traffic was increased by 20%, which points to a potential gain in capacity enabled by A-RNP The Advanced RNP specification is an umbrella specification that includes many of the existing continental PBN speci-fications. It overtakes the limitations of P-RNAV (developed as a means to ensure safe connectivity between P-RNAV STARs/SIDs with B-RNAV ATS route network, absence of a mandate, ANSPs did not publish procedures and aircraft did not equip, did not satisfy some operational requirements and lacked too many functionalities). In comparison with P-RNAV, Advanced RNP responds to the operational requirements by including functionalities associated with RNP that are not associated with RNAV. These include on-board performance monitoring and alerting, which provides integrity monito-ring, the requirement for Radius to Fix (RF) and the option of Fixed Radius Transition (FRT). The latter ensure repeatable turn performance by a population of aircraft along a curved path, thus allowing the spacing between routes to remain constant on both straight and turning segments. RNP also permits the routes to be drawn closer together due to the on-board-performance-monitoring and alerting function required by RNP (but not by RNAV) specifications. Finally, a key part of Advanced RNP is ‘scalable RNP’, which was included as an option.

Air Defence All measures designed to nullify or reduce the effectiveness of hostile air action.

Air SurveillanceThe systematic observation of airspace by electronic, visual or other means with the primary purpose of identifying and determining the movements of aircraft and missiles.

Area Navigation (RNAV)This is a method which permits aircraft navigation along any desired flight path within the coverage of the associated navigation aids or within the limits of the capability of self-contained aids, or a combination of these methods.RNAV equipment is considered to be any equipment which operates by automatically determining aircraft position from one or a combination of sensors with the means to establish and follow a desired path.


Automatic Dependent Surveillance – broadcast (ADS-b)Automatic Dependent Surveillance – Broadcast (ADS-B) is a surveillance technique which allows the transmission of aircraft-derived parameters, such as position and identification, via a broadcast-mode data link for use by any air and/or ground users.Each ADS-B emitter periodically broadcasts its position and other data provided by the on-board aircraft avionics systems. Any user, either airborne or ground-based, within range of the emitter may choose to receive and process the information.

b-RNAVB-RNAV is defined as RNAV which meets a track-keeping accuracy equal to or better than +/- 5 NM for 95% of the flight time (RNP-5). This value includes signal source error, airborne receiver error, display system error, and flight technical error. This navigation performance assumes that the necessary coverage provided by satellite or ground-based navigation aids is available for the intended route to be flown.

Command and Control System An assembly of equipment, methods, procedures and, if necessary, personnel, enabling commanders and their staffs to exercise command and control.

Communication and Information Systems (CIS)Collective term for communication systems and information systems.

Commercial off-The-ShelfPertaining to a commercially marketed product which is readily available for procurement.

Communication SystemAn assembly of equipment, methods, procedures and, if necessary, personnel, organised to accomplish information transfer functions. A communication system provides communication between its users and may embrace transmission systems, switching systems and user systems.

Distance-Measuring Equipment (DME)Equipment (airborne and ground) used to measure, in nautical miles, the slant range distance of an aircraft from the DME navigational aid. DME is usually frequency-paired with other navigational aids such as a VOR or localiser.

Elementary SurveillanceElementary Surveillance includes basic surveillance and also delivers the following to the surveillance user including humans and systems that may utilise Controller or System Access Parameters (CAP/SAP):n the aircraft identity – the Mode A call sign and 24-bit address, flight identity or tail registration;n the aircraft pressure altitude in units of 100 ft or 25 ft, if the aircraft is appropriately equipped.Mode S Elementary Surveillance functionality must constitute the following transponder parameters and data formats for Ground Initiated Comm.-B (GICB) protocols as defined in ICAO Annex 10 volume III (Amendment 77 or later), Appendix 1:n 24-bit aircraft address, n SSR Mode 3/A n Altitude reporting in 25ft increments (or at least 100 ft increments – subject to airframe capability, ICAO Annex 10, Vol

IV 2.1.3) n Flight Status (airborne/on the ground) (ICAO Annex 10, Vol IV 23.1.2.8.6.7) n Data Link Capability Report (BDS 10 hex) n Common Usage GICB Capability Report (BDS 17 hex) n Aircraft identification (BDS 20 hex) n ACAS Active Resolution Advisory (BDS 30 hex) if ACAS equipped n The aircraft operator has to ensure that the aircraft reports a unique 24-bit aircraft address as assigned by the

appropriate State Authorities and as managed by the appropriate military domain (if applicable)

108

Enhanced SurveillanceEnhanced Surveillance includes elementary surveillance and also delivers to the surveillance user a set of air-derived data (ADD) in order to provide additional data to ground-based ATM systems and safety nets.When implemented using Mode S SSR, the following aircraft parameters are automatically extracted from the aircraft:

The two columns reflect which DAPs are to be provided if Track Angle Rate is or is not available.

Future Air Navigation System (FANS)In 1983 the ICAO Council established the Special Committee on Future Air Navigation Systems (FANS) to study, identify and assess new technologies, including satellite technology, and to make recommendations for the future development of navigation systems for global civil aviation. Until the ICAO ATN concept became available, Boeing and Honeywell built a FANS data link application to run on the existing ACARS system.This avionics package became known as FANS-1 and was certified in June 1995. The Airbus Industrie equivalent system is known FANS-A, and these systems are known collectively as FANS-1/A. The ACARS networks are designed for the transmis-sion of character-based messages to and from the aircraft, whereas the CPDLC and ADS applications intended for the ATN were defined using a binary (bit-oriented) message set. The FANS-1/A system achieved the packaging of binary messages as character-based messages in accordance with the ARINC 622 specification.FANS-1/A technology is being implemented in oceanic airspace around the world and is being used in domestic airspace in a few locations. There are gateways that allow communication between both FANS-1/A aircraft and those fitted with ATN data link avionics. The ATN side of the dual-stacked system will be based on redefining some of the CPDLC and ADS-C messages originally specified in the ICAO SARPS. The intention is to converge the FANS and ATN worlds to allow as many aircraft as possible to participate in data link services across oceanic and domestic airspace.Meanwhile, Europe has been working aggressively to expand the use of domestic ATN-based data link capability. Current European mandates exempt FANS-1/A+ aircraft. In parallel, FANS-1/A currently remains the only data link option for oceanic traffic (there is currently no ATN version of ADS-C).FANS 1/A data link messages can be sent either via a VHF or satellite network, or by HF. FANS-1/A services can also be provided by VDL Mode 2, an advanced digital VHF data network. This provides two «flavours» of VHF networks for FANS

bDS Registerbasic DAP Set

(if Track Angle Rate is available)Alternative DAP Set

(if Track Angle Rate is not available)

bDS 4,0 Selected Altitude Selected Altitude

bDS 5,0 Roll Angle Roll Angle

Track Angle Rate

True Track Angle True Track Angle

Ground Speed Ground Speed

bDS 6,0 Magnetic Heading Magnetic Heading

Indicated Airspeed (IAS) / Mach no. (Note: IAS and Mach no. are considered as 1 DAP (even if technically they are 2 separate ARINC labels). If the aircraft can provide both, it must do so).

Indicated Airspeed (IAS) / Mach no. (Note: IAS and Mach no. are considered as 1 DAP (even if technically they are 2 separate ARINC labels). If the aircraft can provide both, it must do so).

Vertical Rate (Barometric rate of climb/descend or baro-inertial)

Vertical Rate (Barometric rate of climb/descend or baro-inertial)

True Airspeed (provided if Track Angle Rate is not available)


services, POA (Plain Old ACARS) and AOA (ACARS Over AVLC (VDL Mode2)). Software within the Central Processing System automatically decides the most efficient (and cheapest) path for delivery of the message, depending on the location of the aircraft. HFDL is an available service. While the transit times of messages sent by HFDL do not meet the requirements for current reduced separation standards (i.e. 30/30NM), HFDL provides communications in polar regions where neither VHF nor satellite networks are available.To ensure that messages from one network are delivered to customers of another network, SITA and ARINC operate an internetworking agreement and associated connections to exchange messages.FANS 1/A is specified in standards EUROCAE/RTCA ED 100A/DO-258A.

Global Positioning System (GPS)GPS is a US space-based positioning, velocity and time system composed of space, control and user elements. The space element is nominally composed of 24 satellites in six orbital planes. The control element consists of five monitor stations, three ground antennae and a master control station. The user element consists of antennae and receiver processors provi-ding positioning, velocity, and precise timing to the user.

Identification, Friend or FoeA system using electromagnetic transmissions to which equipment carried by friendly forces automatically responds by, for example, emitting pulses, thereby distinguishing themselves from enemy forces.

Instrument Landing System (ILS)A precision instrument approach and landing system which normally consists of the following electronic components: VHF (very high-frequency) localiser and glide path equipment; an associated monitor system; remote-control and indi-cator equipment.

Information SystemAn assembly of equipment, methods, procedures and, if necessary, personnel, organised to accomplish information-processing functions.

Initial operational Capability (IoC)IOC corresponds to the first time an operational improvement is needed to start delivering benefits. For enablers, the IOC date implies that a change has been deployed and is ready for operations. The enabler IOC dates are driven by the timing of the operational improvements they support. IOC dates are therefore central in the Master Planning process. All earlier lifecycle phase dates have been planned according to the target IOC dates. The point in time of full stakeholder deploy-ment is called the Full Operational Capability (FOC) date.The notion of IOC is important. It means that all enablers are developed and sufficiently deployed to enable operation. This deployment may initially be limited to one airport, one area control centre and one aircraft or may require deploy-ment on several sites.The IOC dates are driven by the timing of the operational improvements that they support and all earlier lifecycle phase dates have been planned according to the target IOC dates.The SESAR Work Programme considers that V&V activities in the maturity life cycle should be completed at least 2 years before an IOC to permit industrialisation (V4 of the Maturity Lifecycle). This means that V3 needs to be completed at least two years before IOC, as stated above.

InteroperabilityThe ability of systems to provide information and services to and accept information and services from other systems and to use the information and services so exchanged.It is also defined as the condition achieved among communications-electronics systems or items of communications-electronics equipment when information or services can be exchanged directly and satisfactorily between them and/or their users.

Lateral Navigation (LNAV)Lateral navigation (LNAV) refers to navigating over a ground track with guidance from an electronic device which gives the pilot (or autopilot) error indications in the lateral direction only and not in the vertical direction. In aviation, lateral navigation is of two guidance types: linear guidance and angular guidance. Linear means that the left and right deviations

110

of the aircraft are available as a distance of the aircraft from the desired ground track to its actual position on either side of the desired track. In angular guidance, the error indication is given in degrees of angle from the desired line relative to a ground-based navigation device. To provide an illustration, as the aircraft approaches the ground device with a constant angular error, its distance to the desired ground line decreases. In the context of aviation instrument approaches, an LNAV approach (one that uses lateral navigation) implies a GPS-based approach with linear lateral guidance.

Lateral Navigation/Vertical Navigation (LNAV/VNAV)Lateral navigation/vertical navigation minima provided for RNAV systems that include both lateral and vertical navigation (e.g. WAAS avionics approved for LNAV/VNAV, certified barometric VNAV with IFR approach certified GPS).

Localizer Performance with Vertical Guidance (LPV)LPV is a procedure supported by SBAS systems such as WAAS in the US and EGNOS in Europe to provide lateral and vertical guidance. The term LPV stands for localizer performance with vertical guidance. The lateral performance is equi-valent to an ILS localizer and the vertical guidance is provided against a geometric path in space rather than a barometric altitude. LPV is of particular interest to a category of users with aircraft that do not have sophisticated FMS based avionics that can perform Baro/VNAV. LPV also provides geometrically based approach profiles; this has the potential to enable reduced decision heights compared with barometric VNAV, where the decision height has to take account of the limita-tions of barometric VNAV.

Microwave Landing System (MLS)MLS is a precision approach and landing guidance system which provides position information and various ground to air data.

MultilaterationMultilateration is a surveillance technique where aircraft replies from other SSR or SSR Mode S interrogations or spon-taneous squitter from Mode S transponders are passively received by three or more ground receiver stations. Using time-of-arrival techniques, the position and altitude of the target can be determined.In some multilateration systems at airports, active Mode S selective interrogations are used to extract aircraft identity, Mode A or other data from the aircraft.

NATo Consultation, Command and Control SystemsCommunication and information systems, sensor systems and facilities which enable NATO Authorities and Commands to carry out consultation, command and control.

NATo Standardisation AgreementThe record of an agreement among some or all the member nations to adopt similar military equipment, ammunition, supplies, stores and operational, logistic and administrative procedures. National acceptance of a NATO publication issued by the Military Agency for Standardisation may be recorded as a Standardisation Agreement. Also known as «STANAG».

Primary Surveillance Radar (PSR)Primary radar operates by radiating high levels of electromagnetic energy and detecting the presence and characteristics of echoes returned from reflected objects.Target detection is based entirely on the receipt of reflected energy. It does not depend on any energy radiated from the target itself, i.e. no carriage of airborne equipment is required.

P-RNAV (Precision Area Navigation)In order to support extensive use of the lateral and longitudinal manoeuvres (path stretching and speed adjustment) required to manage high aircraft arrival rates, ASPA-IM-S&M operations are defined following P-RNAV routes. Hence, a P-RNAV structure must exist in the airspace considered and also the IM aircraft must be capable of flying under standard P-RNAV published routes.Area Navigation (RNAV) is a method of Instrument Flight Rules (IFR) navigation that allows an aircraft to choose any course within a network of navigation beacons, rather than navigating directly to and from the beacons. This can conserve flight distance, reduce congestion, and allow flights into airports without beacons.RNAV can be defined as a method of navigation that permits aircraft operation on any desired course within the coverage


of station-referenced navigation signals or within the limits of a self-contained system capability, or a combination of both.The continuing growth of aviation increases demands on airspace capacity, thus emphasizing the need for optimum utili-zation of available airspace. Improved operational efficiency derived from the application of area navigation techniques has resulted in the development of navigation applications in various regions worldwide and for all phases of flight. These applications could potentially be expanded to provide guidance for ground movement operations. RNAV specifications include requirements for certain navigation functions. These functional requirements include:1. Continuous indication of aircraft position relative to track to be displayed to the pilot flying on a navigation display

situated in his primary field of view;2. Display of distance and bearing to the active (To) waypoint;3. Display of ground speed or time to the active (To) waypoint;4. Navigation data storage function; and5. Appropriate failure indication of the RNAV system including its sensors.Precision RNAV (P-RNAV), or Precision Area Navigation, is defined as a RNAV procedure that meets a track-keeping accu-racy equal to or better than +/- 1 NM for 95 percent of the flight time. Although there is currently no mandate for P-RNAV, and conventional terminal area procedures will continue to be provided, operators with P-RNAV approval will progressi-vely benefit from operational advantages in European terminal airspace. P-RNAV offers the ability to use RNAV functionalities in all phases of flight except final approach and missed approach. This allows the routes in the terminal airspace to be defined to best meet the needs of the airport, the air traffic controller and the pilot. This translates into fuel and flight time savings through shorter, more direct routes with simple connections to the en-route structure. This can also result in appropriately segregated arrival and departure streams, thereby reducing the need for radar vectors and hence the workload for both the pilot and the controller. Fewer radar vectors also means less uncertainty on the flight deck with regard to the anticipated tactical route and the distance to go.

Receiver Autonomous Integrity Monitoring (RAIM)A form of ABAS whereby a GNSS receiver processor determines the integrity of the GNSS navigation signals using only GPS signals or GPS signals augmented with altitude (baro aiding). This determination is achieved by a consistency check among redundant pseudoorange measurements. At least one additional satellite needs to be available with the correct geometry over and above that needed for the position estimation for the receiver to perform the RAIM function.

Required Communication Performance (RCP)RCP refers to a series of communication performance requirements defined in terms of capability, availability, error rate, traffic delay etc. In a given airspace, any communication system or combination of systems used to support ATM exchanges must comply with specified quality of service levels.Required Navigation Performance (RNP)This is a statement of the navigation performance necessary for operation within a defined airspace.RNP navigation performance targets are linked with aircraft operation on any desired flight path within the coverage of station-referenced navigation aids or within the limits of the capability of self-contained navigation aids, or a combination of these. It will likely cover the ability of aircraft sensors and navigation computers to sustain a defined level of accu-racy, integrity, continuity, availability and functionality needed for the proposed operation in the context of a particular airspace concept. Navigation performance includes on-board performance monitoring and alerting functions as well as the use of Flight Management System (FMS) to sustain more advanced functionalities where the use of navigation data bases is required.

Required Navigation Performance Type (RNP Type)RNP types are established according to navigational performance accuracy in the horizontal plane, that is, lateral and longitudinal position fixing. The type is identified as an accuracy value expressed in nautical miles (e.g. RNP-5).Required Surveillance Performance (RSP)RSP defines the surveillance requirements according to the airspace involved. The surveillance system must provide the updated aircraft position in order to ensure safe traffic separation. The surveillance system should allow users to select the preferred en-route flight path and to allow for the application of separation in a defined airspace.

RNP on ApproachThe RNP APPCH specification applies to the approach phase of flight and was created to offer four approach types inclu-ding Lateral Navigation (LNAV), Lateral Navigation with Vertical Guidance (LNAV/VNAV), Localiser Procedure with Vertical

112

Guidance (LPV) and Approach Procedures with Vertical Guidance (APV). There is a considerable number of runway ends in Europe where one of the approach types is published (or scheduled to be published).

Secondary Surveillance Radar (SSR)Secondary surveillance radar (SSR) operates by transmitting coded interrogations in order to receive coded information from all SSR transponder-equipped aircraft, providing a two-way «data link» on separate interrogation (1030 MHz) and reply (1090 MHz) frequencies.Replies contain positive identification as requested by the interrogation: either one of 4096 codes (Mode A) or aircraft pressure altitude reports (Mode C). The cooperative concept ensures stable received signal strength and considerably lower transmitted power levels than primary radar.

SSR Mode SSSR Mode S is a development of SSR. It uses the same interrogation and reply frequencies as SSR but the selective inter-rogations contain a unique 24-bit address. This ensures that transmissions can be decoded only by the aircraft equipped with the Mode S transponder corresponding to that 24-bit address.A Mode S station also transmits conventional SSR formats in order to detect SSR-only aircraft (Mode A/C) and is thus downwards compatible with SSR Mode A/C. The SSR Mode S transponder is also a fundamental part of the ACAS airborne installation and ADS-B when using the SSR 1090 MHz transmission.

SurveillanceSurveillance is defined as the technique for the timely detection of targets, the determination of their position (and, if required, the acquisition of supplementary information relating to targets) and the timely delivery of this information to users in support of the safe control and separation of targets within a defined area of interest.

Tactical Air Navigation (TACAN)Tactical Air Navigation (TACAN) is a NATO military radio navigation system which provides a pilot with a bearing and distance to a beacon on the ground, a ship, or specially equipped aircraft. TACAN is the primary tactical air navigation system for the military services ashore and afloat. TACAN is often collocated with civil VOR stations (VORTAC facilities).

Traffic Information Service – broadcast (TIS-b)TIS-B allows an air traffic situation picture to be transmitted to an aircraft from the ground. It is a Traffic Information Service.

Vertical Navigation (VNAV)Vertical NAVigation in aviation is an autopilot function which directs the vertical movement of aircraft either according to pre-programmed FMS flight plan during cruise or according to ILS glide slope during approach. If used while cruising, VNAV causes an aircraft to climb or descend according to a pre-programmed FMS (flight management system) flight plan. When used on approach to landing, VNAV follows an ILS (instrument landing system) glide slope toward the runway. This process is known as «autoland» and has been available since the mid-twentieth century.

Very High Frequency omnidirectional Radio Range (VoR)A very high frequency radio navigational aid which provides suitably equipped aircraft with a continuous indication of bearing to and from the VOR station.

Very High Frequency omnidirectional Radio Range/Tactical Air Navigation (VoRTAC)A navigational facility consisting of two components, VOR and TACAN, which provide three services: VOR azimuth, TACAN azimuth, and TACAN slant range.

EUROCONTROL

January 2014 - © European Organisation for the Safety of Air Navigation (EUROCONTROL)

This document is published by EUROCONTROL for information purposes. It may be copied in whole or in part, provided that EUROCONTROL is mentioned as the

source and it is not used for commercial purposes (i.e. for financial gain). The information in this document may not be modified without prior written permission

from EUROCONTROL.

www.eurocontrol.int