docbox.etsi.org · web viewinformation paper only – background information for icb members and...

Version with consolidated DFS comments /V0.99/ Releasable to CANSO, ICB, ETSI STF293

Detailed Descriptions of Proposed IRs and CSsInformation Paper Only – Background information for ICB members and ETSI STF293

Introduction

This document provides background information relating to the Interoperability Implementing Rules (IR) and Community Specifications (CS) proposed by the European Commission to the ICB in Paper ICB/2/3 [1].

It provides an analysis of the background, content, and objectives of the various IRs and CSs proposed originally by the EC. Individual Helios experts were tasked with completing a pro-forma for each topic. These are presented in Annex A.

Any views expressed in this document are that of DFS experts based on the opinions of the Helios team of experts (and not of the ICB or the ICB sub-group).

P364D003 HELIOS TECHNOLOGY 1 of 89

Version including consolidated DFS comments /V0.99/ Releasable to CANSO, ICB, ETSI STF293

Group Title AnnexAirspace Management CS IR on Airspace Design and Flexible Use of

Airspace1 A.1.1

CS on Airspace Design and Flexible Use of Airspace2 A1.2Air Traffic Flow Management

IR on the Initial Flight Plan A.2.1CSs on Airport Collaborative Decision Making (A-CDM) A.2.2

CS on Data Eexchanges Formats A.2.3Air Traffic Services (ATS)

IR on Co-ordination and Transfer A.3.1IR on Data Link Services A.3.2IR on Flight Data Processing A.3.3CS on On-Line Data Interchange (OLDI) A.3.4CSs on Open ATC system architecture model A.3.5CSs on interoperability of Flight Data Processing A.3.6CS for an ATS Middleware A.3.7CSs on Arrival and departure management3 A.3.8CSs on Advanced Surface ManagementMovement Guidance and Control Systems (A-SMGCS) A.3.9

Communication

IR on the Flight Message Transfer protocol A.4.1IR on Air/Ground Voice Channel Spacing A.4.2CS on Ground/Ground Communications A.4.3

Navigation

IR on the Required Navigation Performance A.5.1CS on Ground Based Augmentation Systems A.5.2CS on Space Based Augmentation Systems A.5.3CS on Galileo, GNSS A.5.4

Surveillance

IR on Surveillance Requirements A.6.1IR on the Mode S Interrogator Addressing Plan A.6.12CS on Surveillance Data Processing ARTAS A.6.3CS on Surveillance Data A.6.4

AIS IR on Aeronautical Data Integrity A.6.57.1

Use of Meteo Information None Proposed N/A

Table 1: Summary of Proposed IR/CS

1 This CS has been assigned a new title within its group.

2 This CS has been assigned a new title within its group.

3 ICB2/3 [1] included a single CS covering AMAN, DMAN and A-SMGCS. This has been split into two topics, AMAN/DMAN and A-SMGCS on the advice of the ICB Interoperability Sub-Group.



A Detailed Analysis

A.1 Airspace Management

A.1.1 CSs IR on Airspace Design and Flexible Use of Airspace

A.1.1.1 Introduction

A.1.1.1.1 ICB2/3 [1] described an Airspace Management (ASM) development without identifying whether these would be IRs or CSs. The purpose is to develop means of compliance in support of the application of the implementing rules on airspace design and on flexible use of airspace. These means of compliance would be developed as Community Specifications in application of Article 4 (1b) of the Interoperability Regulation.

A.1.1.1.2 Two mandates have been issued to Eurocontrol in respect of Air Space Management (ASM):

Airspace Design (ASDAD)

Flexible Use of Airspace (FUA)

A.1.1.1.3 These two mandates draw not only on the Interoperability Regulation [9] but also the Airspace Regulation [10] to define their scope.

A.1.1.1.4 A third ASM mandate has been issued to Eurocontrol in relation to Functional Airspace Blocks however this does not fall within the scope of ICB/2/3 [1].

A.1.1.2 Objective

A.1.1.2.1 The ultimate goal of the Airspace Design mandate is to enable a more effective use of the European Upper Flight Information Region (EUIR) in terms of access to user preferred routings and profiles, optimal capacity management and a more efficient airspace organisation by ANSP’s.

A.1.1.2.2 The Mandate for the development of IR’s on the Flexible Use of Airspace (FUA) is aimed specifically at the civil/military interface of airspace management. There are over 13000 military aircraft in the ECAC region with over 150 military airfields. The operations of these aircraft make up an essential group of European airspace users and therefore are important stakeholders in European Air Traffic Management.

A.1.1.2.3 The FUA mandate’s primary goal is to improve the capacity and safety of the air traffic system primarily through a more flexible process for the activation of reserved airspace most notably in terms of activity times and airspace dimensions.

A.1.1.3 Status

A.1.1.3.1 In relation to Airspace design Eurocontrol has an existing Airspace & Navigation Team (ANT) which has conducted significant work on route network optimisation and airspace classification harmonisation. However the design principles and application process and the guidance material produced from this group requires strengthening. Regulations produced from the draft IRs developed by Eurocontrol through its consultation process will provide a more robust solution.

A.1.1.3.2 Military requirements are addressed in several working groups within EUROCONTROL, such as ANT or RNDSG. The Civil/Military Interface Standing



Committee (CMIC) has to date been the primary Commission tool for dealing with interface issues. It receives significant input from the Harmonisation Group (MILHAG) which is a military only forum designed to co-ordinate military positions on ATM/CNS issues.

A.1.1.3.3 Using the ANT as its primary communications medium, work began mid 2004 on both mandates interfacing, inter alia, with the CMIC for the drafting of the IRs. On 30th December 2004 Eurocontrol forwarded the two final reports, containing the draft IRs for each mandate, to the Commission.

A.1.1.3.4 The draft IRs for each mandate have proposed two distinct implementation mediums. The ASD AD IRs have been proposed as a draft regulation whereas the FUA IRs have been proposed as a directive. The primary reason for the difference is the differing level of detail obtainable in the IRs.

A.1.1.4 Technical Issues

A.1.1.4.1 The first 3 Articles of the proposed Airspace Design regulation will be heavily dependant on the application of the directives proposed under the FUA mandate due to the impact on the civil/military interface (in particular VFR operations above FL285) hence conflicts may arise between states due to the non-prescriptive nature of directives in terms of the methods used to achieve outcomes.

A.1.1.4.2 Hence if the IRs for FUA are not supported the ability for states to effectively comply with the IRs on ASD AD will be compromised.

A.1.1.5 Pros and Cons

A.1.1.5.1 The advantages of the proposed IRs on ASD are:

They provide a distinct and reduced set of principles for member states to focus on in relation to interoperability of what can often be a considerable set of ASM issues.

They require member states to participate in the pan-European ATS-route network planning process.

They require the member states to implement airspace classification in airspace above common flight level as class “C” according to ICAO Annex 11, reducing the use of different airspace classifications to a single class across Europe above this level.

A.1.1.5.2 The disadvantages of the proposed IRs on ASD AD are:

In consideration of the initial focus on the EUIR, various Articles require the constraint of the vertical split between upper and lower airspace to be removed. This may result in conflicting scopes while undertaking airspace design changes, in particular route design.

A.1.1.5.3 The advantages of the proposed IRs on FUA are:

A standardised approach for member states to ensure internal cooperation between their civil and military authorities is a priority.

A.1.1.5.4 The disadvantages of Remark concerning the proposed IRs on FUA are:

The choice to propose Directives rather than Regulations may allow too great an opportunity for continued fragmentation in civil/military interface resolution activities between neighbour states. Although the directives call for greater



harmonisation across national borders much of the focus is on internal communication and coordination between national civil and military authorities.

On the other hand, the EC cannot interfere into member states matters on national security and military affairs. Hence, IRs which include prescriptive measures for the military cannot be introduced under the auspices of SES.

A.1.1.6 Cost Benefit Analysis

A.1.1.6.1 No CBA has been undertaken for these IRs.

A.1.1.6.2 There are potential for airspace users, as follows, but these can only be confirmed by CBA:

The aligning of users flight profile needs with the structure of the airspace including routes, dimensions and reservation activity leading to cost savings for airspace users.

The baseline case would result in a realisation of cost estimates on flight delays and a fragmented ATS system not designed around a pure focus on operational requirements.

A.1.1.7 Timeline

A.1.1.7.1 Please refer to the ENPRM material on ASD AD and FUA.

A.1.1.8 Conclusion

A.1.1.8.1 The inclusion of this IR in ICB2/3[1] indicates the importance of ASD AD and FUA concepts within the scope of the Interoperability Regulation.

A.1.1.8.2 The reason for this importance lies in the application of these concepts and the identified need for adequate constituents to support information sharing on airspace management, the breaking down of current FIR boundaries and the harmonisation of a redesigned EUIR with lower airspace for a more seamless processing of flights from gate to gate all with the sole driver of, and solely limited by, operation needs.

A.1.1.9 Descriptive text proposed to be included in Commission’s mandate for this IR

The inclusion of Airspace Design and Flexible Use of Airspace within the Interoperability IRs is not required since an AD IR and a FUA IR are already available / under preparation.



A.1.2 CS on Airspace Design and Flexible Use of Airspace

A.1.2.1 Proposal: text should be drafted by EUROCONTROL

A.1.2.1.1 If Community Specifications on Airspace Design are seen to be required they should be based on existing ICAO documentation (SARPS) and respect the guidelines specified by EUROCONTROL.

As a minimum, the following documents should be considered:

ICAO Annex 11, ICAO Annex 2, ICAO Annex4

ICAO DOC 8168-OPS/611 VOL II, ICAO DOC 9368 AN/911, ICAO DOC 4444 ATM/501, ICAO EUR DOC 001 RNAV/5

ECTL Airspace Planning Manual, ECTL Advanced Airspace Scheme

ECAC Airspace Management Handbook

IR on Airspace Design

A.1.2.1.2 If Community Specifications on FUA are required they should be based on the reference material which has been provided and developed by EUROCONTROL in close co-operation with its member states:

EUROCONTROL Report on Organisational Structures and Procedures Required for the Application of the Concept of the Flexible Use of Airspaceadopted by the ECAC Transport Ministers at their Fourth meeting on the Air Traffic System in Europe (MATSE/4) (Doc.94.70.08 March 1994)

EUROCONTROL Functional Specification for System Support to Airspace Data Distribution and Civil/Military Co-ordination [DPS.ET1.ST10.2000-FS-01-00] Edition 1.0 15/05/96

EUROCONTROL Guidance Document for the Implementation of the Concept of the Flexible Use of Airspace [ASM.ET1.ST08.5000-GUI-02-00] Edition 2.0 18/08/03

EUROCONTROL Manual for Airspace Planning – Common Guidelines - Vol. 2 [ASM.ET1.ST03.4000-EAPM-02-02] Edition 2.0 22/10/03

EUROCONTROL Handbook for Airspace Management [ASM.ET1.ST08.5000-HBK-02-00] Edition 2.0 22/10/03

Draft Concept of Operations for the Enhancement of ASM/ATFM/ATC Processes to ensure seamless FUA Operations from strategic to tactical use – FUA 2008 Scenario Edition 0.A 12/05/04

Draft Operational Requirements Document for the Enhancement of ASM/ATFM/ ATC Processes to ensure seamless FUA Operations from strategic to tactical use FUA 2008 Scenario Edition 0.3 March 04

Enhanced Flexible Use of Airspace Process Safety Policy – Proposed Issue Edition 1.0 22/03/04

Enhanced Flexible Use of Airspace Process Safety Plan – Proposed Issue Edition 1.0 22/03/04

Draft Outline Safety Case for the Enhanced Real-time Civil/Military Coordination Edition 0.2 08/06/04

A.1.2.1.3 EUROCONTROL should be tasked to further develop the a.m. documentation



A.2 Air Traffic Flow Management

A.2.1 IR on the Initial Flight Plan


A.2.1.1.1 An independent review aimed at improving ATFM, reinforced by Eurocontrol ATD/CFMU studies, highlighted shortcomings in current initial flight planning processes. Most notable is the transmission of inconsistent data between IFPS and FDPS. This is often exacerbated by some airspace user’s inadequate knowledge of procedures and supporting operational documentation.

A.2.1.1.2 Departure and ATC co-ordination procedures do provide safeguards against data inconsistencies. However, there have been several safety-related incidents related to the transmission of inconsistent flight plan data which also impacts on the overall efficiency of the ATM system.

A.2.1.1.3 This regulation applies to the pre-flight phase of a flight and deals with the submission, modification and distribution of flight plans for operations within the ICAO EUR Region (known as the IFPS Zone (IFPZ)).

A.2.1.2 Objective

A.2.1.2.1 The objective of this regulation is to mandate mechanisms to ensure that key elements of a flight plan processed within the EATMN are kept consistent between all parties responsible for the safe conduct of the related flight.

A.2.1.2.2 The scope of this regulation is the exchange of flight plans, repetitive flight plans and associated updated messages between aircraft operators, IFPS and ATS units in the pre-flight phase.

A.2.1.3 Status

A mandate was delivered to Eurocontrol on 5 April 2004.

An informal consultation of target groups took place between June and September 2004 followed by a workshop in October 2004

A formal consultation period followed from 7 November 2004 to 7 January 2005.

The draft Final Report was delivered to the EC on 29 October 2004.

Final Workshop: 20 January 2005

Final report to EC: January 2005.


A.2.1.4.1 Authoritative documentation is required specifying standard operating procedures and providing the basis for unit training programmes.

A.2.1.4.2 A potential means of compliance already exists in the form of the IFPS User Manual which forms part of the CFMU Handbook. Given appropriate regulatory authority this document meets the requirement.

A.2.1.4.3 The EC mandate specified the use of ADEXP in the IR implementation of the requirements. However, the IR addresses high level procedures only, not the



detailed solutions used to implement it. The use of ADEXP was therefore considered outside the scope of the draft rule. Consequently, following informal consultation, it was considered inappropriate to mandate ADEXP4.

A.2.1.4.4 Some concern was also expressed that the draft IR appeared to require the adoption of ICAO message format when two other formats (ADEXP and IFPS-RPL) are already in use within Europe. It was confirmed that there is no regulatory impediment on the type of format to be used and the IR would not impose such a restraint.


A.2.1.5.1 Pros:

The draft IR was generally well received by stakeholders. None of the respondents considered the draft proposals unacceptable under any circumstances. All acknowledged the need for standardised procedures as the basis of safety and efficiency.

Most respondents suggested changes to improve the draft provisions, notably in the areas of definitions and clarity of requirements.

A.2.1.5.2 Cons:

There may be a need for additional staff to match the possible increase in messages during the transition phase.

ANSP implementation costs may vary considerably in relation to their present capability.


A.2.1.6.1 There have been several studies quantifying the cost of flight plan inconsistencies at European level. To improve estimated IR implementation costs, further data was collected from the stakeholders; this will be reflected in the final report justification material.

A.2.1.6.2 The IR is not expected to have financial implications for Airline Operators. System changes to permit the automatic handling of additional messages have not been quantified at this stage. The system change costs per FDPS will depend upon the need for minor enhancements or major software changes. Rough estimates obtained from a limited number of providers vary between € 100K to one million Euro. However these costs may have been overestimated.

A.2.1.6.3 With regard to the systems under development, manufacturers have confirmed that they will be perfectly capable of achieving the rule without any major change in the near term.

A.2.1.7 Timeline

A.2.1.7.1 The first draft of the revised IFPS User Manual will be available in March 2005. This should ensure that the document can be formally approved and nominated as a means of compliance by the end of 2006.

A.2.1.7.2 To enable ANSPs adequate time to make any desired system enhancements, the proposed implementation date has been reviewed. Compliance with the regulation will now be required from 1 January 2009.

4 See section A.2.3 for discussion on CS for ADEXP.



A.2.1.8 Conclusion

A.2.1.8.1 The IR drafting procedure has been completed.

A.2.1.8.2 The key element to successful implementation is the production of a revised IFPS User Manual, the revision of which is on track. The IR has generally been well received although the cost implications for some ANSP require clarification. Full implementation is expected on 1 January 2009.


None (task already done)



A.2.2 CS on Airport Collaborative Decision Making (A-CDM)


A.2.2.1.1 The purpose is to define the minimum technical requirements for the standardisation of an airport airport CDM making data model.

A.2.2.2 Objective

A.2.2.2.1 Airport Collaborative Decision Making A-CDM aims to improve airport operations by ensuring that airport partners (e.g. Airports, Airlines, ATC and ATFM) receive relevant and accurate information on time.

A.2.2.2.2 This CS was included in the Standardisation Mandate M/354 [15] and is currently being pursued by EUROCAE WG 69. The intention is to develop a more generic Implementing Rule in support of CDM.

A.2.2.2.3 It is noted that Airport CDM, is only one part of CDM, which also includes ATFM practices.

A.2.2.3 Status

A.2.2.3.1 A-CDM is covered by ECIP Objective ‘AOP05’ [11].

A.2.2.3.2 The EUROCAE WG-69 Collaborative Decision Making (CDM) aim is to define ‘the different interconnected sub-systems to implement the Airport CDM concept (e.g. Airport Management systems, Airline Operation centre, SMGCS, ATS systems, CFMU)’ and their minimum required functionalities. Two documents are currently in preparation:

‘Specification of minimum functionalities for the implementation of the Airport CDM concept’;

‘Specification of technical interfaces between the interconnected sub-systems’.

A.2.2.3.3 Further, CDM forms a central part of the ATM 2000+ Strategy. The Strategy foresees:

CDM for ATFM (network capacity);5

CDM at airports (airport throughput)6.

A.2.2.3.4 Within the next five years the Strategy foresees the ‘first applications of Collaborative Decision Making (CDM), principally for ATFM and at airports’.

A.2.2.3.5 EUROCONTROL has an ongoing CDM project which includes trial/implementation projects at a number of European airports (e.g. Barcelona, Brussels, Heathrow and Stockholm Arlanda). Two new ATFM messages have been developed by EUROCONTROL to facilitate the ‘Collaborative Management of Flight Updates’;

5 Regional CDM is achieved when a network of CDM airports are linked with the Central Flow Management Unit (CFMU) through the exchange of DPI (Departure Planning Information) and FUM (Flight Update Message) (EUROCONTROL website [12]).

6 At a CDM airport all partners share the same information and get the Target Off Block Time (TOBT) of an aircraft provided by the aircraft operator; accurate estimates of arrival times are provided to the CDM airport by the CFMU (EUROCONTROL website [12]).



the Flight Update Message (FUM) and the Departure Planning Information (DPI) message.


A.2.2.4.1 Local development: To date information systems have been or are being developed and built independently at individual airports (for example, ranging from an internet-based system allowing interfaces with legacy systems to considering CDM system adaptations as part of wider airport information system upgrades (e.g. integration with A-SMGCS)).

A.2.2.4.2 Data confidentiality and security: Information is to be shared amongst a number of partners (in some cases potentially using web-based systems). Certain partners are reluctant to share information which they consider “commercially sensitive”, therefore restricting information sharing [13]7.

A.2.2.4.3 Most relevant information exists somewhere around the airport in various systems, but is not readily available to all partners [13]:

Data standards: Standardisation of data formats, while considering local needs and being flexible/adaptable to technology change.

System compatibility: Standardisation of the interfaces between CDM stakeholders.

Data quality: Provision of automated data of sufficient quality.


A.2.2.5.1 The potential benefits of CDM are:

Enhanced decision making capabilities through information sharing.

Better use of existing resources and efficiency in operations.

Common situational awareness between partners of flight progress in the air and on the ground.

Predictable air traffic due to timely and accurate shared information.

Recovery from disruption made easier through timely dissemination of information.

A.2.2.5.2 It is generally accepted that the standardisation of data is required and the advantage of this CS is that it will help prepare industry to the development for any required CDM-products.

A.2.2.5.3 The potential disadvantages of this CS are:

CDM is still to be further developed. It would therefore not be appropriate to write too specific rules on the subject. The ATFM rules, limited to broad principles, would pave the way towards increasing use of CDM processes [14].

A clear idea of the operational requirements should be developed before defining the technical requirements. Additional documents that define the

7 CDM and System Wide Information Management raise a general concern of malicious or accidental compromise to the integrity and availability of ATC data. An IR may be required to cover information security requirements for ATC systems.



benefits, costs, needs of the various stakeholders and data sources will be required prior to the promulgation of an IR.

May drive technical solutions at the expense of operational solutions.


A.2.2.6.1 A CBA has not been produced specifically for this CS.

A.2.2.6.2 EUROCONTROL have undertaken a CBA for A-CDM Level 1 (development of an A-CDM platform based on existing airport information systems, and the implementation of new information sharing procedures among the airport partners).

A.2.2.6.3 The Level 1 benefit to cost ratio is high at around 60:1 for year 1. The ratio reflects the assumption that system costs are relatively low as they are likely to involve the integration of current airport information systems to accommodate A-CDM procedures, rather than radical changes to software/hardware.

A.2.2.7 Timeline

The following timeline was proposed in: ATM-CNS Interoperability Roadmap [2]

2006-2008: A CS describing the minimum technical requirements for airport CDM.

2008-2010: Delivery of the mandatory material for CDM implementation and capacity optimisation might become realisable, and could specify:

- The revised structure of ATFM-related information exchanges between ATM services and their responsibility with regards to airspace users, in terms of support for flight planning mainly.

- The capacity information exchange structure enabling common air traffic and capacity information management at Single European Sky scale.

- The adoption of the “flight object” as the standard format for flight information exchange within the SES ATM network (see section A.3.6).

A.2.2.8 Conclusion

A.2.2.8.1 This CS covers the data requirements for Airport CDM. Consideration should be given to an IR covering CDM encompassing all forms of CDM including Airspace and Flow Management CDM. Additional CS may be required to support such an IR.

A.2.2.9 Descriptive text proposed to be included in Commission’s mandate for this CS

A.2.2.9.1 The work of the European Airport CDM Project, which is part of the European Airport Operation Programe, shall be taken into account. Already developed guideline material, i.e. the „Airport CDM Implementation Manual", „Airport CDM Functional Requirement Document" and the "Airport CDM Operational Concept Document" as well as its further developments shall be the basis for CS/IR on Airport CDM.



A.2.3 CS on Data Exchanges Formats


A.2.3.1.1 The purpose is to develop a CS of the technical details of the ATS Data Exchange Presentation (ADEXP). The issue concerning the use (mandatory or not) of ADEXP will be addressed during or after the development of the CS.

A.2.3.1.2 This topic was included in the Standardisation Mandate M/354 [15] and ICB/2/3 [1]. The CS was initially proposed in the ATM-CNS Interoperability Roadmap Study [2].

A.2.3.2 Objective

A.2.3.2.1 The Eurocontrol Convergence and Implementation Plan (ECIP) [4], [5], [6] contains an agreed objective for the 2006 – 2010 cycle, to implement collaborative flight planning.

A.2.3.2.2 The aims are to improve the collaboration between the CFMU, ANS providers, airports and airspace users in flight plan filing, in particular to assist airspace users in filing their flight plans and in re-routings according to the airspace availability and AFTM situation. Also to improve flight plan distribution to increase consistency of flight plan data amongst all parties involved (CFMU IFPS/ETFMS, ANSPs, etc.).

A.2.3.2.3 In due course this becomes a key enabler to the broader objectives of Flexible Use of Airspace.

A.2.3.2.4 The objective of this CS is to adopt ADEXP as a formal European Standard, developed by ETSI. ADEXP would then form the basis for the various forms of message exchange needed.

A.2.3.3 Status

A.2.3.3.1 The ATS Data Exchange Presentation (ADEXP) is a format for message exchange in the following areas:

Flight Planning

Air Traffic Flow Management (ATFM)

Air Traffic Control Co-ordination

Airspace Management

Civil / Military Co-ordination

A.2.3.3.2 ADEXP is a format, not a protocol. No restrictions are imposed on the transmission media or protocols to be used, other than that of the character set.

A.2.3.3.3 ADEXP exists as a Eurocontrol Standard [16] and was adopted by COMMISSION REGULATION (EC) No 2082/2000 [17].

A.2.3.3.4 The ADEXP standard is based on ideas from French CAUTRA system which were used to support CFMU development. It goes significantly beyond the ICAO 4444 standard for flight data interchange [18]. ADEXP has a high level of support.




A.2.3.4.1 The action plan for collaborative flight planning using ADEXP involves a number of actions by ANSPs to use IFPS (and hence the ADEXP format) to provide more data to the CFMU.

A.2.3.4.2 The key issue involved is not adoption of the standard per se but the extent of its use.


A.2.3.5.1 It seems straightforward that support could continue to be given to the collaborative flight planning action and that appropriate support could also be provided by means of a CS for ADEXP.


A.2.3.6.1 The expected benefits listed in the ECIP [4], [5], [6] are as follows:

Safety: Prevention of overloads

Capacity: Better use of the available network capacity

Cost-effectiveness: Reduction of costs induced by delays

A.2.3.6.2 These benefits are not quantified. Nor are the costs, but we do not believe that the costs of aligning with an existing well-defined standard will be large.

A.2.3.7 Timeline

A.2.3.7.1 The main timescale involved in the collaborative flight planning action should be complete in 2006.


A.2.3.7.1 Exchange of Flight and Airspace Data between the main actors in the EATMN, - ANS Providers, CFMU, Airports and Airspace Users - is one key enabler for efficient and timely execution of air traffic. A widely and flexibly usable and commonly accepted format for this kind of data is necessary in order to ensure automated data distribution and exchange.

The purpose is to develop a CS on an ATS message exchange format adopting the existing ATS Data Exchange Presentation (ADEXP). ADEXP is a mature Eurocontrol Standard which has been implemented by various stakeholders



A.3 Air Traffic Services

A.3.1 IR on Co-ordination and Transfer (COTR)


A.3.1.1.1 The objective stated in the ICB2/3 paper [1] is to define the co-ordination and transfer requirements based on the On-line Data Interchange (OLDI) standard. A mandate was issued to Eurocontrol in respect of Coordination and Transfer on the 5th April 2004 for the development of an IR.

A.3.1.2 Objective

A.3.1.2.1 The goal of the Coordination and Transfer mandate is to develop a draft implementing rule for interoperability on coordination and transfer between Air Traffic Services Units. The rule is also to address civil-military coordination.

A.3.1.2.2 The IR is aimed at addressing the interoperability for the exchange of system information between ATS units in the process of ‘notification, coordination and transfer of flights’.

A.3.1.2.3 Ultimately the IR will lead to reduced voice coordination across sector boundaries and therefore reduced controller workload and improved safety through the reduction in human errors associated with regular and routine coordination of flight data across FIR boundaries.

A.3.1.3 Status

A.3.1.3.1 The draft implementing rule for Co-ordination and Transfer (COTR) has been circulated for formal consultation between November 2004 and the beginning of January 2005, using the mechanisms of the EUROCONTROL Notice of Proposed Rule-Making (ENPRM) process.

A.3.1.3.2 The Consultation process has provided significant comments from Stakeholders. About half of those who responded (the total number of responses was 31) considered that the proposed rule was not acceptable but it would be acceptable with amendments. [19]

A.3.1.3.3 Currently the Draft IR regulation is being revised to incorporate issues discovered during the consultation process with a final draft due by the end of January March 2005.


A.3.1.4.1 Based on feedback received from member states the draft regulation is achievable albeit with modifications. The most significant issue raised was that of the scope of the application of the regulation in terms of interoperability between all ATS units and between Civil civil units and Military ATS Units.

A.3.1.4.2 Actions taken to address those concerns have resulted in the limiting of the mandatory data flows to enroute units thus making all other interfaces voluntary (e.g. Airports and Military Units).

A.3.1.4.3 Annex I of the draft is too prescriptive in its description of the data exchanges. This finding is supported by the comments received from members and the revised draft will focus on the processes to support the goals rather than the messages themselves.



A.3.1.4.4 There is still work to be completed on the development of CS’s to further clarify the IR’s especially in relation to the use of OLDI to comply with the IR and conformity assessments.


A.3.1.5.1 Advantages of the proposed IR on COTR are:

Allows for technological advancement to achieve the goals through other means than OLDI.

Lays down a clearer set of performance requirements between enroute sectors that take-up a majority share of the airspace structure thus providing a significant benefit to the bulk of airspace users.

A.3.1.5.2 Disadvantages of the proposed IR on COTR are:

Compromise with the complications of data flow requirements resulting in mandates only applying to the interface between en-route units with the balance applying a voluntary approach may hinder the progression of other mandates such as ‘Flexible Use of Airspace’ (FUA), ‘Functional Airspace Blocks’ (FAB) and ‘Airspace Management’ (ASM) which will all require a high level of complete system interoperability to achieve their goals.


A.3.1.6.1 No CBA has been undertaken. The benefits of the resultant ATM system are:

The prime (and immediate) beneficiary of increased interoperability of flight data coordination are the air traffic controllers. As such benefits will be found in decreased workload and improved safety from factors such as increased situational awareness for cross FIR boundaries or Civil/Military boundaries.

Airspace user cost savings may be derived from possible capacity gains through controller workload reductions as well as increases to optimal flight profile access through improved situational awareness.

A.3.1.7 Timeline

A.3.1.7.1 The ENPRM consultation process is now closed.

A.3.1.8 Conclusion

A.3.1.8.1 A significant analysis of changes made to the draft regulation for this IR will be required. The new version will deal with a number of significant issues, most notably the over prescription of the interoperability and performance requirements.

A.3.1.8.2 The other significant issue to be resolved is the current paradigm of OLDI being the only method to achieve the objectives. This will have to be resolved for the IR to maintain flexibility towards technological improvement.

A.3.1.8.3 The decision to provide mandates for the data flows between En-route sectors may result in a diluting of the achievable aims of the SES through the heavy reliance on interoperability of flight coordination data between the other components of the airspace system (eg. Military, Airports, TMA etc).




A.3.1.9.1 None (task already performed)



A.3.2 IR on Data Link Services


A.3.2.1.1 The purpose of this IR is to specify the regulatory provisions for Air Traffic Services supported by air ground data link communications in order to harmonise the provision and use of data link services.

A.3.2.1.2 The proposed IR would be based on the Link 2000+ programme and would include mandating:

The following datalink services:

- Data Link Communications Initiation Capability (DLIC)

- ATC Communications Management (ACM) service

- ATC Clearances and Information (ACL) service

- ATC Microphone Check (AMC) service

The ATN protocol stack

VDL Mode 2 (VDL2)

A.3.2.2 Objective

A.3.2.2.1 Over the last 20 years the ATM capacity has doubled. This was achieved by creating more ATC sectors and by reducing vertical and horizontal separation between aircraft. In the mean time the communication means between controllers and pilots have not changed. One single VHF channel is still the standard way to communicate. More and more voice communication is becoming the bottleneck to sector capacity. Pilots cannot make requests when they want and this leads to less then optimal flight profiles. Controllers spend more then half of their time on voice communication and cannot organise the traffic flow in an optimal way. In addition there is a rising trend in the number of misunderstandings and repetitions caused by regional accents and bad radio quality. The LINK 2000+ Programme was created to implement CPDLC8 in core Europe as a supplement for voice communication.

A.3.2.2.2 Controller pilot data link communication addresses both problems. It provides a means of conveying non-time critical routine messages in a safe way. This frees up the voice frequency for urgent calls and reduces controller and pilot workload. CPDLC provides a clear readable and retrievable message to the correct aircraft and in doing so enhances safety.

A.3.2.2.3 An airspace capacity increase of 11% is expected to be delivered by the successful completion of the programme, based on a target 75% equipage. This is achieved through using CPDLC for Transfer of Communications and a limited number of en-route clearances.

A.3.2.2.4 In order to realise the expected benefits, the majority of airspace users must be equipped with ATN/CPDLC capable avionics and use them. Furthermore, Safety considerations limit operations with mixed equipage i.e. in order to avoid possible confusion, it is desirable that, within an airspace, the aircraft should either be predominantly datalink equipped or predominantly voice only.

8 Controller Pilot Data link Communications (CPDLC) is the application that support the datalink services listed in the introduction.



A.3.2.2.5 Eurocontrol has also established a follow-on programme: CASCADE. This is intended to realise further airspace capacity benefits through extending the use of ATN/CPDLC to deliver additional ATS Services.

A.3.2.3 Status

A.3.2.3.1 UAC Maastricht is already delivering an ATN/CPDLC service together with a compatible service for FANS-1/A equipped wide bodied aircraft. Other European ANSPs, including the German, French, Spanish, Portugese, Italian, Swiss and Irish ATS Providers are committed to providing similar services in the 2007/2008 timeframe.

A.3.2.3.2 Under the Link2000+ Pioneer Programme, over 100 aircraft either have or are being equipped to use the Maastricht service. These include aircraft from SAS, American Airlines, Federal Express, Lufthansa, Air Europa, Airbus Transport, Hapag Lloyd, Finnair, Air Berlin and Aeroflot.

A.3.2.3.3 Avionics are available from Rockwell Collins, and Link2000+ Avionics are expected to be delivered during 2005 by Honeywell. Airbus will be supplying Link2000+ Capable avionics from 2007.


A.3.2.4.1 In terms of implementing the proposed mandate, the only main outstanding technical issue is the certification level of avionics. In order to realise the full benefits, avionics will need to be certified to DO178B Level C. This is a normal requirement for safety related systems and needs to be taken into account in any mandate as a system certified to a lower level may not be acceptable.

A.3.2.4.2 A number of datalink services are currently supported using the ACARS network but are not considered within the implementation scope of the Link2000+ program, these are:

- Departure Clearance (DCL);

- Down Stream Clearance (DSC);

- Data Link ATIS (D-ATIS).

A.3.2.4.3 Other applications are also being considered for implementation within the CASCADE program. Given that the mandate would not apply to retrofit aircraft until 2014, it seems likely that additional applications may be required. A refresh of the EC Datalink Roadmap is a potential means for identifying additional applications that could be considered for the mandate.

A.3.2.4.4 Concerns have also been raised about the inclusion of VDL Mode 2 and ATN in the mandate rather than leaving the technical means of compliance to a Community Specification; an approach which would seem more aligned to the EC’s ‘New Approach’.

A.3.2.4.5 It is noted that the use of VDL2 is entirely pragmatic and leverages off the considerable industry investment in VDL2 for delivery of Airline Operational Communications.

A.3.2.4.6 The ATN is an OSI based communications protocol stack. Whilst popular in the1980s when the ATN was first proposed, the OSI stack has fallen out of favour since the TCP/IP stack has become so popular due to the spread of the internet. Ground-ground communications within ATN are ATM are already migrating to



TCP/IP and most industrial forecasts, including the Boeing Communications Strategy, foresee the use of TCP/IP for the air-ground networks as well.

A.3.2.4.7 There is also a need to accommodate the older long range FANS-1/A aircraft. This is being done at Maastricht. However, due to limitations in the FANS-1/A technology an equivalent service cannot be offered in the long term or over the entire continental airspace. CASCADE is expected to consider the future of FANS-1/A equipped aircraft.


A.3.2.5.1 The advantage of the IR is that it ensures the rapid take up of datalink based ATC. It gives suppliers the confidence to develop products knowing that a market will exist and justifies investment by airlines and ANSPs. Without a mandate, there is a risk that such investment will be wasted if insufficient aircraft are equipped.

A.3.2.5.2 LINK 2000+ services on VDL2/ATN are expected to reduce communication errors and contribute to higher safety levels; to increase controller efficiency and reduce voice congestion; reduce controller workload and, consequently, enable an increase in airspace capacity increase (up to 11% if 75% of the aircraft are equipped).

A.3.2.5.3 However, a number of concerns have been raised over the proposed content of the implementing rule:

Mandating LINK 2000+ services on VDL2/ATN could exclude FANS-1/A equipped aircraft. Mechanisms are required to ensure that FANS-1/A aircraft can be safely accommodated in the Link airspace and that migration path is established for all aircraft to converge on a common solution.

Such mandate would create additional difficulties in terms of frequency management if it is confirmed that 3 frequencies could be required to accommodate 75% of the traffic in the busy areas.

Mandating LINK 2000+ services, in particular as retrofit aircraft would not need to be equipped until 2014, may not pass the best signals if the objective remains to introduce as early as possible the new concepts of operation. Of particular concern are concepts which require a tactical datalink with priority mechanisms to ensure the timely delivery of specific messages.


A.3.2.6.1 The CNS/ATM Focus Team (CAFT), an airline lead group produced a business case for CPDLC in 2000. The business case contained a strategic part and a cost benefit analysis. The strategic arguments to implement CPDLC have not changed, but the Cost Benefits Analysis has now been updated with actual cost figures and with confirmed assumptions.

A.3.2.6.2 Both CBAs show that from an airline perspective and from an ANSP perspective the introduction of CPDLC is economically justified.

A.3.2.6.3 However, in the airlines’ view a business case has yet to be demonstrated for the fitment of new data link equipment to existing aircraft.

A.3.2.6.4 CPDLC will reduce controller workload and consequently increase sector capacity. Simulations show that 11% more sector capacity can be expected if 75% of all flights in a given sector are equipped. This will reduce delays and increase sector productivity.



A.3.2.7 Timeline

A.3.2.7.1 The Pioneer Phase of Link 2000+ is expected to last until 2007 when the other European ANSPs start to deliver datalink services.

A.3.2.7.2 Following on from this Eurocontrol plans an incentives phase to encourage early adopters prior to the application of the mandate. Funding constraints limit the incentives phase to approximately 25% equipage levels.

A.3.2.7.3 The mandate is expected to start in March 2009 for aircraft registered after Jan 2008. Retrofit of aircraft registered before then is required by 2014.

A.3.2.7.4 The 75% equipage target is expected to be reached around 2011.

A.3.2.8 Conclusion

A.3.2.8.1 The rapid introduction of datalink services is seen as an essential enabler for future ATM. The Link2000+ Programme is the result of extensive development work by ICAO and Eurocontrol over the last 20 years including major trials and validation work. The technical issues and benefits are well understood.

A.3.2.8.2 However, the content of the proposed IR requires further debate.


A.3.2.9.1 The purpose of this implementing rule is to specify the regulatory provisions for ATS supported by Air/Ground Datalink communications in order to harmonize the provision and use of datalink services.

A.3.2.9.2 The proposed IR should be based on the defined scope of the Link 2000+ programm and should comply to the framework given by ECIP ATC06 and the relevant EUROCAE standards.

A.3.2.9.3 The aim of this IR is to ensure that datalink services implemented could be used to the full operational extent in order to achive the expected benefits



A.3.3 IR on Flight Data Processing (FDP)


A.3.3.1.1 The purpose of this item is to mandate the minimum requirements for FDPS systems: interconnectivity, common data exchange format, performance and core functions.

A.3.3.1.2 The IR on Coordination and Transfer should be regarded as a subset of this one. There are two CSs (for: On-line Data Interchange (OLDI) and Interoperability of Flight Data Processing) which will be required for operational compliance to this IR; in addition, there are also likely to be dependencies on the CSs:

for an Open ATC system architecture model (see section A.3.5)

for an ATS middleware (see section ).

the OLDI standard (see section A.3.4)

A.3.3.2 Objective

A.3.3.2.1 The Essential Requirements for Flight Data Processing as defined in the Interoperability Regulations are as follows:

Seamless Operation

- Flight data processing systems shall be interoperable in terms of the timely sharing of correct and consistent information, and a common operational understanding of that information, in order to ensure a coherent and consistent planning process and resource-efficient tactical coordination throughout the EATMN during all phases of flight.

- In order to ensure safe, smooth and expeditious processing throughout the EATMN, flight data processing performances shall be equivalent and appropriate for a given environment (surface, terminal manoeuvring area (TMA), en-route), with known traffic characteristics and exploited under an agreed and validated operational concept, in particular in terms of accuracy and error tolerance of processing results.

Support for new concepts of operations

- Flight data preparation systems shall accommodate the progressive implementation of advanced, agreed and validated concepts of operation for all phases of flight.

- The characteristics of automation-intensive tools must be such as to enable coherent and efficient pre-tactical and tactical processing of flight information in parts of the EATMN.

- Airborne and ground systems and their constituents supporting new, agreed and validated concepts of operation shall be designed, built, maintained and operated, using appropriate and validated procedures, in such a way as to be interoperable in terms of timely sharing of correct and consistent information and a common understanding of the current and predicted operational situation.

A.3.3.2.2 The purpose of an IR in this area is to ensure that these Essential Requirements can be implemented according to phasing which takes account of two factors: the



need for incremental development of this capability and its deployment alongside legacy systems; the variable levels at which costs will be incurred and benefits acquired depending on the density of traffic and complexities of existing systems.

A.3.3.3 Status

A.3.3.3.1 The interoperability of FDP and ATS systems is a cornerstone of the SES expectations for the EATMN. The Essential Requirements are extensive in scope; the realisation of benefits will come in systematic improvements in the capacity and cost effectiveness of the overall system. It is not expected that all requirements will be implemented together or at a similar rate in Europe between, for example, high and low density areas of traffic. The ATM-CNS Interoperability Roadmap Study [2] proposes that material could be developed in several packages of work, combining development of both IRs and CSs in a phased manner.

A.3.3.3.2 CANSO have suggested that work could be managed in three phases:

Exchange of messages, according to certain format and semantics (e.g. OLDI);

Exchange of information (e.g. Flight Object);

Possibility of integrating modules produced by different manufacturers (“plug and play”).

A.3.3.3.3 Thus, the implementation of the IR on Coordination and Transfer and the CS on OLDI could be regarded as the first phase of the overall IR on FDP. Each phase will require its own cost benefit analysis and full justification before proceeding to implementation.


A.3.3.4.1 Much of the original ground work for interoperability of FDP was done during the collaborative development of the eFDP Procurement Specification. This work was carried on by an Operational Interoperability Task Force under the umbrella of the Flight Data Management Sub-group managed by EUROCONTROL. A variety of Interoperability Requirements documents were developed and are published on EUROCONTROL’s web-site [12]. This area was also responsible for the update of the OLDI standard to Version 3. Recently EUROCONTROL has let a contract to EUROCAE for the development of a Flight Object Model via WG59.

A.3.3.4.2 In parallel to the EUROCONTROL activity, two projects are underway with the intention of developing a new generation of advanced FDP capability:

The iTEC-eFDP project, for which the customers are AENA (Spain), DFS (Germany) and NATS (UK) and the supplier is INDRA.

The coflight project for which the customers are DNA/STNA (France), ENAV (Italy) and Swisscontrol and the suppliers are Thales and AMS.

A.3.3.4.3 The objectives of the Service Providers are to:

Meet the objectives of the European Commission’s Single European Sky initiative

Enable the flexible use of airspace



Provide greater levels of automated support to Air Traffic Control (ATC) services by implementing capabilities such as Flight Path Monitoring and Medium Term Conflict Detection and Conflict Resolution Assistant

Support interoperability improvements between the partners in air transport: ATS providers, Air Traffic Flow Management (IFPS/CFMU), Aircraft/Pilots, Airline Operators and Airports

A.3.3.4.4 The core functions to be offered by these next generation FDP systems will include:

Flight Data Management and Distribution

Air Ground Data Link (AGDL) Flight Data Processing (FDP)-Applications

Advanced Trajectory Prediction

Co-ordination and Transfer

Correlation and SSR Code Management

Management of the Operational Configuration

Environment Data Processing

A.3.3.4.5 Each FDP system will need to provide interfaces to the following external systems:

Controller Working Positions

Flight Data Operator Positions

Operational and Technical Supervisor Positions

Local center sub-systems (Surveillance Systems, Supervision System, Recording System, Data Analysis System, Adaptation Database)

Aircraft Systems via AGDL

Flight Plan Information Subscriber (for e.g. Airline Operators and Airports)

Adjacent civil and military Air Traffic Service Units (UAC, ACC, APP, TWR)

European Air Traffic Flow Management (CFMU/IFPS (TACT and CADF, ETFMS))

Traffic Management Support Systems (Arrival Manager, Departure Manager, Traffic Load Monitor)

Meteorological Service Providers

A.3.3.4.6 We understand that the two projects, involving both service providers and industry, have set up an Interoperability Consultancy Group which will work via the EUROCAE WG59 (or other suitable body) with objectives which are to:

Contribute to community specifications in support of the EC Interoperability Regulation

Deliver a new interoperability mechanism for air traffic control to achieve an early realisation of the SES objectives

Provide a generic solution (beyond OLDI) that can accommodate the requirements of all stakeholders



The data exchange principle (in line with the SES regulation for service provision) is non-discriminatory access to relevant operational data for ANSPs, airports and other airspace users.

A.3.3.4.7 We assume that The Roadmap to be developed in due course by the SESAME project in this area will be based on the ongoing work of the iTEC-eFDP and coflight projects.


A.3.3.5.1 The position of the core service providers, supported by their industry suppliers, is that they control a very large proportion of European airspace including most of the high density areas. They have both the motivation and the capability to find a successful way forward in terms of both operational requirements and system solutions. They will create the interoperability solutions required for Flight Data Processing. Subsequently these solutions, in terms of operational methods and system products can be rolled out elsewhere in the ECAC region.

A.3.3.5.2 The involvement of EUROCONTROL at this stage, by means of coordination activities and funding provided to EUROCAE and others, is to ensure that the resulting solutions are relevant to the needs of all users in the ECAC area, thus generating capacity benefits, and also result in the competitive supply of industry products enabling users to deploy this capacity in a cost-effective manner.

A.3.3.5.3 The risks of this approach are:

The user organisations may in practice solve their own local needs only

The work may proceed at a pace which is too slow for the overall objectives of the Single European Sky

Industry may fail to work together to create system products which are genuinely interoperable

The resulting products may be insufficiently open and/or the commercial framework may not create enough competition to retain value for money and cost effective deployment

A.3.3.5.4 As noted above, it is likely that the SESAME proposals will be closely aligned with developments in this area. The expected outcomes will have wide-scale implications for the Single European Sky and future improvements in the productivity of the EATMN.


A.3.3.6.1 To our knowledge no formal Cost Benefit Analysis has yet been performed; it is noted however that the benefits of providing interoperable FDP are an important cornerstone of the modernisation of ATM and the result is likely to be positive. A formal CBA should however be conducted as part of the draft process for the IR.

A.3.3.7 Timeline

A.3.3.7.1 We understand that current expectations of timescales are approximately as follows:

Contribute to the specification of eFDP-compliant systems (by end 2006);

Contribute to the specification of interoperability interfaces (by end 2006)



A.3.3.7.2 Direct access to timescale reporting from the key participants would be beneficial, in particular:

The iTEC-eFDP and coflight projects;

EUROCONTROL

EUROCAE Working Group 59.

A.3.3.7.3 The initial stance of waiting for completion of the CS activity prior to initiating work on the IR for Interoperability of Flight Data Processing creates a risk that technical solutions will be created at CS level which are insufficiently grounded in operational need and processes. However, it is assumed that the user organisations involved in the iTEC-eFDP and coflight projects are focussed already on the user requirements for these developments. Is there some way in which this content can be elevated into appropriate material for the IR in parallel with the CS activity?

A.3.3.8 Conclusion

A.3.3.8.1 Much work has been done in this area in recent years by the eFDP project, the FDM SG coordinated by Eurocontrol and recently by the iTEC-eFDP and coflight projects.

A.3.3.8.2 It can be assumed that technical interoperability will be addressed by industry, probably via the mechanism of EUROCAE WG 59.

A.3.3.8.3 If work on the functional requirements represented by this IR on Flight Data Processing proceeds in parallel with the complementary CS work, links could be established with the ANSPs who are acting as customers for the eFDP compliant projects to ensure that the relevant operational knowledge and experience and the requirements for those projects are reflected in this IR.


A.3.3.9.1 None – time horizon within SESAME.



A.3.4 CS on On-Line Data Interchange (OLDI)


A.3.4.1.1 This item concerns the development of a CS based on OLDI standard (draft version 3.0) to ensure that Air Traffic Control Units will be interoperable for Co-ordination and Transfer purposes.

A.3.4.2 Objective

A.3.4.2.1 A mandate has been given to EUROCONTROL by the European Commission for the development of a draft Implementing Rule for Coordination and Transfer under the Single European Sky (SES) Regulations. This mandate is one of several issued under the Interoperability Regulations, related mandates being for the Initial Flight Plan (IFPL) and Flight Message Transfer Protocol (FMTP). The draft IR for Coordination and Transfer has been published by EUROCONTROL and has been subject to a review and workshop process. A draft summary of responses was published by EUROCONTROL on 20 January 2005.

A.3.4.2.2 OLDI is currently a EUROCONTROL standard which has been widely adopted by ECAC states already. In many cases, OLDI has been operational in various versions for more than 10 years.

A.3.4.2.3 OLDI is a means of compliance to the Implementing Rule for Coordination and Transfer and the existing standard needs to be defined as a Community Specification.

A.3.4.3 Status

A.3.4.3.1 OLDI is currently implemented widely in the ECAC region. It facilitates automatic communication between FDP systems in adjacent Area Control Centres, in particular when flights are being handed over between controllers in the relevant Flight Information Regions. The use of OLDI therefore provides an existing capacity benefit. The specification of a standard data interface between separate ATC systems also enables system providers to develop once-only solutions to operational requirements. There is also therefore a cost-effectiveness benefit arising from the use of the OLDI standard.

A.3.4.3.2 In addition to the use of the OLDI standard for data communication between Member States in the ECAC area, it is known that OLDI is also used by choice by service providers to manage the communication between units which are internal to their own systems, thus extending the capacity and cost effectiveness benefits. OLDI is also known to be widely used elsewhere in the world.

A.3.4.3.3 There is no particular mention of the OLDI standard in the current version of the European Convergence and Implementation Plan (2005 – 2009) [4], [5], [6], except for a technical communications issue of the need for a phased transition of the data communications protocol from X25 to an internet based TCP/IP protocol.

A.3.4.3.4 Under the guidance of an Interoperability Development Task Force (IDTF) organised by EUROCONTROL, the OLDI standard has recently been up-issued to version 3 (not yet formally issued); this new version offers improved capabilities for Civil to Military coordination and is also now able to support the SYSCO Level 1 Concept, thus introducing new capacity benefits.




A.3.4.4.1 To date, the implementation of individual instances of OLDI data communication has been arranged bilaterally between adjacent service providers and Area Control Centres. There is nothing to require or guarantee a consistent level of application of the standard from a top-down operational viewpoint. Thus, for example, service providers may choose bilaterally to implement a sub-set only of the OLDI messaging capability. This however is a matter for the related Implementing Rule on Coordination and Transfer (see section 3.1 above).

A.3.4.4.2 The OLDI standard is a peer-to-peer data communications mechanism. Without very substantial change or replacement, it does not fit with the System Wide Information Management concepts envisaged by the European Commissions Interoperability Regulations and currently envisaged in forward plans for the ATM Roadmap in Europe and related plans for systems architecture. In due course, therefore, the OLDI standard and the various implementations of it in Europe will become part of the legacy system.

A.3.4.4.3 The officially released version of the OLDI standard is version 2.3. In order to support the Implementing Rule for Coordination and Transfer, it is version 3 which should become the Community Specification for OLDI. This CS is not however included in the Mandate issued by the European Commission to CEN/CENELEC/ETSI for the development of European Standards for Interoperability of the EATMN. It is unclear whether this is a necessary action, or whether the continuation of a EUROCONTROL standard would be acceptable.


A.3.4.5.1 The main argument in favour of the course of action is that it recognises and regularises the current de facto situation.

A.3.4.5.2 There are concerns however about the combination of IR and CS in this area. In effect the IR has been written to require use of the OLDI standard. In principle other mechanisms could be envisaged but there are no other known solutions available. The IR has been written at SYSCO Level 1 for data communication between adjacent ACCs. It is unclear how a development path forward from this level is to be handled and what the implications will be for subsequent versions of the OLDI standard or its replacement.


A.3.4.6.1 The draft justification document for the IR for Coordination and Transfer estimates the costs for implementing the capability (in essence upgrading to OLDI version 3) for a single centre. Clearly this would need to be scaled up by the number of centres which are required to be upgraded to this level of capability.

A.3.4.6.2 The draft justification document also identifies a variety of capacity benefits, but does not at this stage quantify these in any way.

A.3.4.7 Timeline

A.3.4.7.1 There is no mention in the current version of the European Convergence and Implementation Plan 2005-2009 [4] of any initiatives on Coordination and Transfer. Correspondingly there is no requirement identified for OLDI implementation. Also as noted above, this standard was not included in the list of items mandated by the European Commission. It seems necessary therefore to complete:



The cost benefit analysis of moving towards the IR for Coordination and Transfer.

Formal issue of the OLDI Standard Version 3, as a EUROCONTROL document.

Implementation of the new standard at individual centres and hook-up with adjacent centres by means eventually of a series of bilateral actions. This will involve both systems upgrade and operational readiness actions (eg. procedures and raining as required). It is likely that centre systems would be upgraded on a controlled basis (annual upgrades are normal). In general the facility can be tested, verified and deployed, with activation under operational control at some later date.

Subsequent re-badging of this document as a Community Specification. Feedback is required from ETSI on the timescale required by them to complete this final stage.


A.3.4.8.1 The processes of Co-ordination and Transfer of flights between ATS Units have been described and will be regulated by an Implementing Rule within the SES framework. Currently most ANS providers in Europe use the OLDI (Online-Data Interchange) mechanism to provide for an automated exchange of information supporting these processes of co-ordination and transfer. OLDI is a Eurocontrol Standard, which defines message exchanges between ATS units. The purpose is to produce a CS on Online Data Interchange adopting this already widely used standard and to identify this CS as means of compliance for the IR on co-ordination and transfer.



A.3.5 CS on Open Air Traffic Control (ATC) System Architecture Model


A.3.5.1.1 This item calls for: ‘Definition of an open ATC system architecture including its standard interfaces towards the other entities of the ATM/CNS (Air Traffic Management/Communication, Navigation & Surveillance) network’.

A.3.5.1.2 The item was included in the Standardisation Mandate M/354 [15] and is addressed by the Eurocontrol OATA project and the associated EUROCAE WG 61 ATC High Level Model (AHLM) project.

A.3.5.2 Objective

A.3.5.2.1 The modernisation of ATM requires a clear understanding of the future operational concepts to be augmented by agreement on the necessary services and interfaces required to support those services. The operational concepts are defined in the EUROCONTROL OCD and CONOPS documents.

A.3.5.2.2 Development of a system architecture which is reviewed and agreed by industry enables the identification of services and interfaces required by future operational concepts.

A.3.5.2.3 A key objective for the architecture would be to support the identification of further Community Specifications and Implementing Rules required to support the modernisation of ATM.

A.3.5.2.4 The ultimate goal is to move ATM systems from the current bespoke developments to Open System Platforms. This goal is also supported by the CS on the adoption of Middleware (See ).

A.3.5.2.5 The creation of a systems architecture model for Europe will also facilitate the alignment of systems and interfaces with those of the USA and other ICAO member states outside ECAC, in particular with respect to common interfaces to stakeholders (including airports and aircraft).

A.3.5.3 Status

A.3.5.3.1 The EUROCONTROL OATA project is developing a Logical Architecture of ATM/CNS services in the 2011 timeframe based on the operational concept defined in the EUROCONTROL OCD and CONOPS documents. The OATA Phase 2 programme is due to complete in 2005 summer 2006.

A.3.5.3.2 EUROCAE WG 61 is preparing a document entitled ‘Standards of an Open Architecture for Future European interoperable ATC Systems’. The work is supported by the AHLM project which is developing implementation models based on the following OATA clusters:

En Route and Approach ATC;

Flight Management;

Air Surveillance.

A.3.5.3.3 The AHLM Project is funded by EUROCONTROL and administered by the OATA Project Office. It is also due to complete during 2005.




A.3.5.4.1 The OATA Project, supported by the AHLM project, is the only significant current high level architecture for ATM for Europe.

A.3.5.4.2 The OATA product is a target logical structure for ATC systems. Substantial work is required to define the:

process for moving forward from a target expectation to the standardised definition of system functions and interfaces. (this is the role of the ALHM project).

The outputs (e.g. standards for interfaces) of the work which need to be produced and maintained.

A.3.5.4.3 The development of a high level architecture of ATM is a significant undertaking requiring a full QA, Review and Consultative processes. Ideally a permanent organisation would exist to develop, maintain and analyse the architecture.

A.3.5.4.4 If successful, the high level architecture would enable the identification of:

The Services required/provided by interoperating entities support ATM functions.

The interfaces between such entities.

Requirements for IRs and CSs supporting interoperability.

A.3.5.4.5 There is a danger that any model becomes overly prescriptive. Care is required to ensure that the model remains at a high level and that any necessary detail is presented in additional IRs and/or CSs as appropriate.

A.3.5.4.6 The development of the required architecture is likely to form part of the SESAME work program.


A.3.5.5.1 The advantages of the proposed CS are:

Provides a means to identify services and interfaces supporting the development of further IRs and CSs.

A.3.5.5.2 The disadvantages of this CS are:

The model may become overly prescriptive.

The model requires organisational support to enable its development and maintenance.


A.3.5.6.1 No CBA has been undertaken. The costs of developing the architecture are estimated to be in the order of 10 MEuro. In addition, costs must be estimated for the cost of deployment.

A.3.5.6.2 The benefits of the architecture are:

cost reductions in procurement of systems from industry arising from the creation of an open and consistent market within Europe;



increased interoperability due to higher technical level of consensus achieved over the need for, and definition of, services and interfaces;

consequent cost savings (reduced development costs) in other programmes.

A.3.5.6.3 The baseline case would include not developing an Open ATC Architecture. This would lead to increased procurement costs.

A.3.5.7 Timeline

A.3.5.7.1 The OATA Project and ALHM are likely to produce results during the third of fourth quarters of 2005 summer 2006.

A.3.5.8 Conclusion

A.3.5.8.1 The existence of an agreed high level architecture is an essential enabler for the identification for other CSs and IRs.

A.3.5.8.2 Significant work is underway such that EUROCAE Working Group 61 should be in a position to provide the necessary specification during 2005 based on the EUROCONTROL OATA project. Close collaboration between the EUROCONTROL OATA project and EUROCAE WG-61/AHLM needs to be maintained. However, further work is required to define the use and applicability of the specification.

A.3.5.8.3 Future work on the definition of the CS should take account of the results of the OATA and AHLM projects and should be focussed on enabling the progressive adoption of Open Standards within ATM.


A.3.5.9.1 Should be discussed within SESAME



A.3.6 CS on Interoperability of Flight Data Processing


A.3.6.1.1 This item concerns the development of a Flight Object Model (FOM) which is based on the definition of a standard flight data model that should previously define the Flight Object Model (FOM).

A.3.6.1.2 Other related activities include:

It has been included in the Standardisation Mandate M/354 [15];

It has been the subject of substantial work by the Eurocontrol FDM SG and is being addressed by EUROCAE WG 59;

The CS has also been identified in point 7 of the “Draft Justification Material – Draft Implementing Rule for Co-ordination and Transfer” (see section A.3.1 IR on Co-ordination and Transfer).

A.3.6.1.3 It is assumed that a CS in this area will be followed by the IR on Flight Data Processing (see section A.3.3 above).

A.3.6.2 Objective

A.3.6.2.1 CANSO state that:

Development of the Flight object model (FOM) should be carried out with high priority. Once operational and technical maturity is achieved, the FOM should be adopted as a CS and/or IR. EUROCAE WG-59 and OATA project output should be taken into account.

The objective and scope of this standard should be clearly articulated before definitions can be developed. Task scope and performance requirements are critical to this work. A long - medium term view needs to take into consideration the developments being made concerning European FDP systems.

A.3.6.2.2 As noted in the ATM-CNS Interoperability Roadmap Study [2] Flight Data Processing remains a core interoperability issue, the regulation of which needs to be rapidly addressed. Given the complexity of the task and the difficulty of defining the “target” European FDPS network architecture, in particular regarding the level of commonality and centralisation, the ATM-CNS Interoperability Roadmap Study [2] proposes that IR/CS development might:

be focused on flight data needs between FD consumers at short, long and medium term;

define their nature and associated performance depending on their use and achievability for the SES;

define the necessary consistency assurance processes to be developed either centrally or locally.

A.3.6.2.3 Furthermore, the IR/CS development program could be split into:

A first package production – focused on achieving greater information consistency between FDPS systems in the current environment.



A second work-package production – providing for the integration of the new data provision constraints inherent to the introduction of new ATC enhancements (MTCD, Multi-Sector Planner, AMAN, etc).

A third package preparing the integration of airborne flight data.

A.3.6.3 Status

A.3.6.3.1 This CS has been subject of substantial work by the Eurocontrol FDM SG and is being addressed by EUROCAE WG 59 and the FOIPS study. Detailed results are expected in 2006.


A.3.6.4.1 The OATA project has identified a Cross-Domain module for Flight Management. The module offers a transparent access of up-to-date flight information for its potential users. It has been identified as a common module for several EATM domains: ATC, ATFCM, Airport Operators, Aircraft Operator.

A.3.6.4.2 The elements of Flight Management have been grouped in a number of modules:

Flight plan management

Flight data management and “what if” analysis

Trajectory management

Constraint management

A.3.6.4.3 It is assumed that the development of the Flight Object Model (FOM) will be an initial deliverable from the EUROCAE WG 59, and that traceability needs to be clearly established and maintained between:

User requirements, as represented by an IR process.

The technical definition of standards for implementation, as represented by this CS.


A.3.6.5.1 The benefits of developing a CS in this area include capacity and cost effectiveness.

A.3.6.5.2 Phasing of activity will be necessary to ensure that benefits are delivered in an incremental fashion and that feasibility and cost of implementation are fully considered.

A.3.6.5.3 However, our interpretation at the moment is that the only area of (partial) cost/benefit analysis is for the IR on Coordination and Transfer and the associated CS for OLDI. A more broad-based mechanism for fully considering the benefits, costs, feasibility and trade-offs for development plans for the general case of FDP Interoperability needs to be established.


A.3.6.6.1 No formal CBA has been conducted, but studies have shown benefit in interoperable FDPs.



A.3.6.7 Timeline

A.3.6.7.1 The timescale expected for the development of standard specifications through the mechanism EUROCAE WG 59 is expected to be 2006.

A.3.6.8 Conclusion

A.3.6.8.1 Work has already been initiated in this area by Eurocontrol, EUROCAE WG 59 and others. This particular CS on proposals for a Flight Object model represents only a part of the overall standardisation work required for Flight Data Processing.

A.3.6.8.2 In addition to ongoing work on this CS, other work which could be conducted includes:

Investigating the need for additional complementary CS which cover the overall scope of interoperability of Flight Data Processing

Supporting the parallel development of this CS and an IR for Interoperability of Flight Data Processing.


A.3.6.9.1 Flight Data Processing and the sharing of Flight Data are of key importance for ATM. In order to provide a comprehensive and consistent view of relevant flight data to all involved stakeholders a Flight Object Model should be developed. The purpose of this CS is to define a data model for flight data and the relevant operations on them as well as access methods for the users as derived from interoperability requirements. This set of data and operations will form the Flight Object Model. Work done in the framework of EUROCAE WG 59 and the FOIPS study, as well as results obtained by ICOG (iTEC and Coflight FDPS implementation projects) should form the basis for this CS.



A.3.6.9.2



A.3.7 CS for an ATS Middleware


A.3.7.1.1 At the Single Sky Committee meeting on 26th May 2004, a proposal was made as follows: The Commission was requested to present to the next SSC a mandate for harmonization of so called “middleware” in the ATM sector. The issue was time-critical, as several service providers would already be active and co-operating in the area of developing new flight data processing systems which required middleware to be portable into different ATM system environments. The Commission stated that it would reflect on the request for the mandate and get back to the members of the SSC.

A.3.7.1.2 The main task of a standard ATS middleware is to provide a unified and standardized interface for the ATS applications.

A.3.7.1.3 There may be some considerable overlap between this CS and the work on an Open ATC system architecture model.

A.3.7.2 Objective

A.3.7.2.1 The relevant Essential Requirements in the Interoperability Regulations are contained in Part A: General Requirements as follows:

A.3.7.2.2 Seamless operation: Seamless operation can be expressed, in particular, in terms of information-sharing, including the relevant operational status information, common understanding of information, comparable processing performances and the associated procedures enabling common operational performances agreed for the whole or parts of the EATMN.

A.3.7.2.3 Principles governing the logical architecture of systems: Systems shall be designed and progressively integrated with the objective of achieving a coherent and increasingly harmonised, evolutionary and validated logical architecture within the EATMN.

A.3.7.2.4 Principles governing the construction of systems: Systems shall be designed, built and maintained on the grounds of sound engineering principles, in particular those relating to modularity, enabling interchangeability of constituents, high availability, and redundancy and fault tolerance of critical constituents.

A.3.7.2.5 The key issue is to establish:

how far these objectives can be met at the level of commonality of a middleware standard;

what are the interactions with the plans for a CS covering ATC system architecture;

what is the position of industry, both those who may be directly involved with the SESAME project and other industry providers who may wish to provide complementary system products.



A.3.7.3 Status

A.3.7.3.1 No current work has been identified. The Object Management Group has previously issued Request For Proposal (RFP) for the development of middleware specific to ATS. It is understood that this work is not currently progressing.


A.3.7.4.1 It is assumed that the CS for an ATC Middleware would be drawn up on the basis of European standards for systems or constituents, together with the relevant procedures, drawn up by the European standardisation bodies in co-operation with EUROCAE, on a mandate from the Commission, as defined in the SES Interoperability Regulation.

A.3.7.4.2 In practice, it is likely that the middleware would need to be defined and agreed between the Industry suppliers to the iTEC-eFDP and coflight projects. It needs to be regarded therefore as a means to achieve the objectives of data interchange and interoperability between ATC systems


A.3.7.5.1 We need in due course to see what is in the proposal from Germany with respect to benefits arising in this area. We assume that they will be largely concerned with cost effectiveness. Categorising of benefits are likely to include:

Completion of the iTEC-eFDP and coflight projects in a manner that ensures inter-changeability of operational data between the systems of the user organisations;

Interchangeability of operational data with other user organisations in the ECAC area which are not currently involved with either of the iTEC-eFDP and coflight projects;

Creation of an open market for inter-operable ATC system products in Europe.

A.3.7.5.2 The development of a CS for an ATS Middleware could also facilitate the achievement of other objectives for system wide information sharing with attendant benefits.


A.3.7.6.1 No CBA has been completed for this CS.

A.3.7.7 Timeline

A.3.7.7.1 Currently, a CS requirement for ATC Middleware has not been included in the Mandate provided to CEN/CENELEC/ETSI by the European Commission. The EUROCAE working groups have not yet documented an agreement that this represents a necessary line of action to achieve interoperability of ATC systems.

A.3.7.7.2 It seems premature therefore to identify a timescale for completion of work in this area.



A.3.7.8 Conclusion

A.3.7.8.1 From a system procurement perspective, the issue of a common ATC middleware standard is largely concerned with the eventual cost of system acquisition and support:

Will it be cheaper to buy and replace major ATC systems

Will it be easier and cheaper to add components from third party suppliers to systems


A.3.7.9.1 Middleware supports the development of platform independent ATS application software and its operation within a distributed network of heterogeneous computer systems.

In the context of the SES Interoperability Regulation the introduction and use of a common Open Middleware will support the implementation of Essential Requirements on Seamless Operation and for Principles governing the logical architecture and the construction of systems such as e.g. information-sharing between various stakeholder systems.

. The purpose of this CS is to develop and identify in a first step an Open Middleware Standard for ATS applications which is based on an existing commonly used Middleware Standard (e.g. CORBA) enhanced with specific services considered important for the sharing of data between ATS units (e.g. ACC-to-ACC interoperability). Work ongoing for the iTEC and Coflight projects should be considered as basis for this CS.

A.3.7.9.2 In a second step a complete ATS Middleware Standard could be developed specifying also intra-system Middleware services which could support the harmonisation of ATM systems. This step has to be aligned with the development of a complete ATM architecture.



A.3.8 CS on Arrival and Departure Management


A.3.8.1.1 This item calls for the development of a CS covering Arrival Management (AMAN) and Departure Management (DMAN) tools and is covered by the Standardisation Mandate M/354. [15]

A.3.8.1.2 The item was initially proposed in the ATM-CNS Interoperability Roadmap Study [2] and included A-SMGCS which is covered in a separate CS in Section A.3.9.

A.3.8.2 Objective

A.3.8.2.1 The objective of implementing both the Arrival and Departure Management systems is to create a more orderly and expeditious flow of traffic for both departing and arriving aircraft.

A.3.8.2.2 This will allow the more efficient use of departure and arrival runaways without increasing the current strain on holding stacks.

A.3.8.2.3 An Arrival Manager is an automated assistance tool that performs runway sequencing functions for arrival traffic. It optimises the arrival order and assigns runway time slots to arrivals.

A.3.8.2.4 A Departure Manager is a computer-based tool for assisting air traffic controllers at airports with the management of departing flights. The function of DMAN is to plan take-off times and consequent start up times and to make these available to ATC, airport authorities and aircraft operators.

A.3.8.2.5 The primary objective of DMAN is to maximise runway throughput for departing flights. The minimum separation between two successive departing flights depends on the specific details of the flights, including their wake turbulence categories and their proposed route through the TMA (Terminal Manoeuvring Area). Using these details for a sequence of departures it is possible to minimise the average time between them. DMAN uses an algorithm to shuffle the planned departure times from the natural order.

A.3.8.3 Status

A.3.8.3.1 AMAN and DMAN are both constituents of the Eurocontrol ASA Programme. AMAN is a significantly more mature concept than DMAN.

A.3.8.3.2 Basic Arrival Management systems are already in use in several European airports. For example COMPAS (Computer Oriented Metering Planning and Advisory System)the 4D Planer is currently being used by DFS at Frankfurt airport and CALM (Computer-assisted Approach and Landing Management) is in use by Skyguide at Zürich airport.

A.3.8.3.3 Several validations and trials have been carried out on the AMAN tool. This included trials at Stockholm Arlanda in Autumn 2003 and Rome in Autumn 2004, with a joint AMAN and DMAN trial planned for Stockholm Arlanda in Autumn 2005.

A.3.8.3.4 DMAN is less mature than AMAN. Skyguide have implemented a Basic Departure Management tool, DARTS at Zürich. Further, Eurocontrol is developing DMAN, and have produced a ‘DMAN Demonstrator’, which is adaptable to any airport and can be used for simulation and live trials. This demonstrator allows technical and operational staff to become familiar with the DMAN concept.




A.3.8.4.1 AMAN considers arriving aircraft at a radius of up to 200NM from the destination airport. It calculates an unconstrained arrival time over the runway threshold using the expected flight profile and aircraft performance parameters. This calculation is done using a Trajectory Prediction tool or TP. Therefore, functionality of AMAN is reliant upon the accuracy of the TP.

A.3.8.4.2 If the unconstrained arrival times conflict with each other by the overlap of expected runway occupancy time and/or required wake-vortex (WV) separation, AMAN considers all possible sequences of arrivals and computes a cost-value for each, respecting the required separation.

A.3.8.4.3 AMAN also has to be able to adapt its plan to new situations. Technically, a complete refresh of the AMAN sequence should be possible with each turn of the radar. However, the solution presented to the respective operator must be more stable.

A.3.8.4.4 DMAN uses the expected ready-time for pushback as the main input. This data can be further improved by the co-operative effort of all airport actors. The Eurocontrol CDM (Collaborative Decision Making) project aims to make this possible.

A.3.8.4.5 Considering that airport traffic is highly dynamic, DMAN will have to react and adapt flexibly to changes in traffic. DMAN will use the standard inputs from the EFPS (Electronic Flight Progress Strip) Systems to detect these changes without increasing controller workload.

A.3.8.4.6 ASMGCS (Advanced Surface Movement Guidance and Control System) will enable accurate and reliable surveillance and provide a close link between reality and the plan. This will also enable the display of the DMAN information in the traffic label.


A.3.8.5.1 The advantages of AMAN are:

Enables optimal use of available ATC and runway capacity;

Reduced need for holding stacks;

Reduced controller workload;

Reduced fuel burn from Continuous Descent Approaches increasing operator economy and reducing environmental impact;

A.3.8.5.2 The advantages of DMAN are:

Enables optimal use of runway capacity;

Reduced controller workload;

The only One disadvantage of AMAN and DMAN is that in order to fully optimise the traffic sequence the First Come First Served principle is not strictly applied. However, there would be a maximum displacement from this principle to enable optimisation.




A.3.8.6.1 Eurocontrol are currently undertaking a Cost Benefit Analysis of AMAN and DMAN.

A.3.8.7 Timeline

A.3.8.7.1 AMAN is a mature application and the procedures for it’s use are due for implementation in 2005 along with adaptation of the TMA organisation to accommodate the use of AMAN and the validation, safety assessment and CBA.

A.3.8.7.2 In 2006 the guidelines for the adaptation of ATCO working methods are due for production with AMAN functions being implemented in 2007. This will run in parallel with the publishing of the regulations on arrival management tool operation.

A.3.8.7.3 DMAN also has a target implementation timescale of starts 2005-2007, however, this is unlikely to be achieved.

A.3.8.8 Conclusion

A.3.8.8.1 It is clear that AMAN and DMAN both represent future forms of controller automation. AMAN is more developed than DMAN but industrial products exist for both. Current developments are also being driven by industry.

A.3.8.8.2 Development of the CS needs to draw on work already done by EUROCONTROL, its member states and ICAO, and take account of the Eurocontrol ASA programme results and other industrial developments.


A.3.8.9.1 Should be part of CS on Airport CDM



A.3.9 CS on Advanced Surface Movement Guidance and Control Systems (A-SMGCS)


A.3.9.1.1 The purpose of this item is to develop a community specification covering Surface Movement Guidance and Control System (SMGCS).

A.3.9.1.2 In the ICB/2/3 [1], this CS was combined with the definition of a standard for arrival management (AMAN) and departure management (DMAN). A CS for AMAN and DMAN is described in section A.3.8.

A.3.9.2 Objective

A.3.9.2.1 Advanced Surface Movement Guidance and Control System, A-SMGCS, will in its initial stages, provide a display to controllers with the uninterrupted accurate position information of all targets and positive identification of all suitably equipped aircraft and vehicles on the entire manoeuvring area. The introduction of a secure and high integrity labelling system will greatly increase the situational awareness of controllers, which will not only increase safety but also improve efficiency and airport throughput.

A.3.9.2.2 In conditions of restricted or reduced visibility the benefits of the system will become more apparent, allowing the controller to be completely sure of the position of identified aircraft and vehicles.

A.3.9.2.3 In addition the system will enhance safety, alerting the controller by detecting potential conflicts between arriving and/or departing aircraft and other targets on the runways.

A.3.9.2.4 Harmonised procedures are being developed to ensure that as A-SMGCS becomes widespread, pilots, vehicle drivers and controllers will be working to the same rules and standards throughout the European region.

A.3.9.3 Status

A.3.9.3.1 Currently SMGCS are already in place in most significant airports across Europe. The need for further improvements has led to the development and initial implementation of A-SMGCS.

A.3.9.3.2 A-SMGCS are already commercially available based on SMR and 1090MHz technology and are becoming operational at different levels of maturity on larger airports across Europe.

A.3.9.3.3 A-SMGCS is currently being considered by the Eurocontrol A-SMGCS project as part of the Airport Operations Programme, and by EUROCAE WG41.

A.3.9.3.4 Existing standards:

ICAO (recommendation, not a Standard in the sense of ICAO)

- Advanced-Surface Movement Guidance and Control Systems (A-SMGCS) manual/ Published as global manual in 2003.

EUROCAE/RTCA

- ED-116 Electronic Copy - MOPS for Surface Movement Radar Sensor Systems for Use in A-SMGCS. Issued in January 2004.


Hartmut Müller, 22/03/05,

Ist doppelt erwähnt unter Punkt A 3.9.2.3


- ED-117 Electronic Copy – MOPS for Mode S Multilateration systems for use in A-SMGCS.

- ED-87A Electronic Copy – MASPS for A-SMGCS, issued January 2001.


A.3.9.4.1 A-SMGCS is a key enabler both for increased airport capacity, the maintainability of high capacity in periods of reduced visibility, and the prevention of runway incursions. Significant research has been undertaken by the EC, Eurocontrol and Industry, leading to a number of ICAO and EUROCAE specifications (listed above).

A.3.9.4.2 A-SMGCS systems requirements are specific to a particular airport configuration and traffic level and composition. Standards must remain flexible enough to accommodate all types of aerodromes, however, they should also be common enough for aircraft operators to be able to adhere to the local situation at different aerodromes without additional frustration or confusion.

A.3.9.4.3 Different technologies are available to achieve the objective of uninterrupted identification of aircraft and vehicles on the manoeuvring area. This may put different requirements on the local procedures and on avionics. The identification of aircraft should be based on the mandatory aircraft equipment, the identification of vehicles can be based individual local solutions.

A.3.9.4.4 Systems aimed at alerting ATC about potential runway conflicts on runways and/or taxiways have been the subject of discussion and development for a long time, with satisfactory results still being unclear.


A.3.9.5.1 The advantages of the proposed CS are:

Improved Surveillance through better coverage of the manoeuvring area and secure labelling for uninterrupted identification of aircraft and vehicles.

Improved Situational Awareness in all weather conditions through the provision of additional information on ATC traffic displays.

Improved Safety through the provision of additional information on ATC traffic displays, causing all necessary information in case of conflicts to be available through a single information source.

Improved Safety through the implementation of a Runway runway / taxiway incursion alert system.

Increased Efficiency through enhanced procedures to make best use of improved surveillance capabilities, leading to increased airport throughput in IMC conditions when the manoeuvring area is not longer visible from the tower.

A.3.9.5.2 The disadvantages of this CS are:

Potential for reduction in safety and capacity in case of partial or full system failure, causing degradation of an important source of information.

Possibility for false/nuisance incursion alarms, hindering operational acceptance due to controller frustration.



A system failure of the A-SMGCS does not consequently lead to a reduction of safety if the appropriate measures are taken immediately.


Better coverage is only achieved through the use of Multilateration with cooperative targets.



A.3.9.6.1 The effects of the adoption of an A-SMGCS system would be very dependent on the local situation, both with respect to costs and benefits. As a result, it is very difficult to perform a general CBA to determine the overall impact of the introduction of A-SMGCS. CBAs should be performed at local level. Eurocontrol does foresee an assessment for the benefit of the aircraft operators, who may need clear reasons for the investment required to retrofit current aircraft with the proper avionics to comply with A-SMGCS standards.

A.3.9.7 Timeline

A.3.9.7.1 The timeline for A-SMGCS development and implementation at individual aerodromes will be very dependent on local needs, depending on issues such as traffic forecasts, lay-out complexity, occurrence of periods with reduced visibility etc.

A.3.9.7.2 In general, the implementation of A-SMGCS is usually divided into incremental levels. Eurocontrol foresees implementation of the first level, related to improved surveillance capabilities, on individual aerodromes form the year 2000 onwards. For the next level, covering runway incursion alerting, is foreseen for implementation from 2006 onwards. Further levels covering guidance and route planning are expected from 2006 and 2009 onwards respectively.

A.3.9.8 Conclusion

A.3.9.8.1 A-SMGCS is generally agreed as the key enabler for maintainable high airport capacity and implementation is already ongoing at several of the largest airports in Europe.

A.3.9.8.2 A-SMGCS development and implementation is very much dependent on local issues. The effect this might have on aircraft operators operating at different airports requires attention.


A.3.9.9.1 tbd



A.4 Communications

A.4.1 IR on the Flight Message Transfer protocol


A.4.1.1.1 A draft mandate concerning the Flight Message Transfer Protocol was presented to the SSC on 31 March 2004 and sent to Eurocontrol on 5 April 2004. The purpose is to define message transfer protocol to support On-line data interchange (OLDI) using the internet protocol (IP).

A.4.1.2 Objective

A.4.1.2.1 The EATMP communications strategy (COM Strategy) sets out a roadmap for the introduction and deployment of new technological solutions to meet the gate-to-gate requirements of Air Traffic Services Providers (ATSPs), airports and airspace users (airlines, general aviation and the military) in the ECAC area.

A.4.1.2.2 A specific strategic action has been identified in the EATMP Communications Strategy to evaluate requirements, specify and implement new data communication services and voice communication services based on evolving or new operational concepts.

A.4.1.2.3 The OLDI standard for flight data communication between adjacent ACCs and military facilities is currently based on the X.25 protocol. In the commercial systems world, X.25 has been replaced by Internet Protocols, specifically TCP/IP. While X.25 is still supported, it represents legacy technology which is becoming increasingly expensive to support. In particular for operational use it requires hardware and proprietary software solutions which must be duplicated for safety and service continuity reasons.

A.4.1.2.4 The objective of this IR is to mandate the FMTP standard [20] for flight data communication. In essence, OLDI will then act as the application layer of information communications running on top of FMTP.

A.4.1.3 Status

A.4.1.3.1 Eurocontrol are in the process of delivering the final report for the Implementing Rule for FMTP to the Commission.

A.4.1.3.2 The Eurocontrol Convergence and Implementation Plan (ECIP) [4], [5], [6] already contains an Implementation Objective COM04 to migrate flight data exchange from X.25 to TCP/IP on an agreed timescale by 2007.

A.4.1.3.3 The timescale requirement currently stated in the draft IR for FMTP is January 2009.


A.4.1.4.1 The Eurocontrol Communications Strategy makes limited reference to the issue of Security and by and large the subject has been avoided in the text of the IR for FMTP9. The change, from locally configured X.25 peer to peer connections to a

9 The draft response material states: The security of system information exchanges between ATC units shall consider all physical and non physical elements, subject to security threats, supporting system information exchanges. The target of the implementing rule is limited to end systems supporting system information exchanges between ATC units. Therefore, the re-assessment of security



global Internet Protocol approach mandated in an IR, changes very substantially the nature of the security threat to operational systems. We suggest that, if this is to be the subject of an IR, then the security requirements need to be explicitly defined.

A.4.1.4.2 There are some difficulties with the technical content of this IR:

The structure of an IR for a detailed, bottom up technical interface, with no associated CS is contradictory to the approach adopted, for example, with an IR at functional level for Coordination and Transfer and an associated CS calling up the OLDI standard.

The IR appears to re-title previously existing work. As such it does not appear to conform to best practice for content, layout and quality control.

Because the requirement is stated at IR level, there appears to be underlying confusion about the roles of system supplier and ANSP.


A.4.1.5.1 It is assumed that the objective listed in the ECIP [4], [5] and [6] is necessary and should be reinforced by, or incorporated in, the SES Interoperability process. The questions remaining, concern whether an IR is the best way to achieve this.

A.4.1.5.2 In favour of the IR is that it adds weight to the ECIP process and establishes this requirement within the SES Interoperability structure.

A.4.1.5.3 Against this form of IR is that:

Action is already in hand.

This action appears to be slowing down the process.

An IR for a detailed technical requirement seems inappropriate.


A.4.1.6.1 The ECIP [4], [5], [6] states that the X.25 protocol is expected to be phased out by 2009, although we cannot find specific traceability for this assertion in the Eurocontrol Communications Strategy document10. Nevertheless there is a clear technical need for migration in due course onto Internet Protocols. The limiting factor eventually will be not the availability of software but instead the availability of hardware on which to run the software.

A.4.1.6.2 OLDI connections have been established by an extended process of bilateral agreements in the ECAC area, a process which is still going on. To date all of this has been based on X.25 communications, initially using proprietary solutions. The community experts, meeting under the aegis of the iPAX Task Force have stated that the new FMTP standard (FDE ICD Part 2) will have limited backwards compatibility to the existing X.25 standard (FDE ICD Part 1)11. Therefore the

programme due to the change in technology from X.25 to TCP/IP is not included in the FMTP IR.

10 The draft justification material for the FMTP IR makes various references to the fact that X.25 is a declining technology – an assertion which we fully support. However, we think that it is unlikely that legacy use of X.25 for many applications, including the world outside ATC, will be phased out in any particular timescale.

11 In essence backwards compatibility can be achieved only by means of a special purpose gateway.



process of migrating to the new standard will be complex and involve reimplementation on the basis of bilateral installation.

A.4.1.6.3 At individual ANSP level, there will be business advantages in replacing old, proprietary, X.25 based operational solutions with new systems and equipment which are cheaper to procure and easier to maintain. Nevertheless there is a substantial transition cost involving the replacement of operational components, which is identified in the draft justification material prepared by Eurocontrol. A per-centre cost of 2.5MEuros is quoted.

A.4.1.6.4 There is in additional business case issue identified in the draft justification material concerning OLDI communication internal to a large ANSP which has several operational centres.

A.4.1.7 Timeline

A.4.1.7.1 A Stakeholder Consultation Workshop for the SES Interoperability mandates was held in October 2004, following which the draft final report for FMTP was published by Eurocontrol. A further workshop was held in January 2005, following which Eurocontrol were due to complete the handover of the final report. Overall, progress on completing the IR for FMTP appears to have progressed in a timely fashion.

A.4.1.7.2 The position on the timeline for implementation seems rather less clear. The Eurocontrol Convergence and Implementation Plan (ECIP) [4], [5], [6] already contains an Implementation Objective COM04 to migrate flight data exchange from X.25 to TCP/IP on an agreed timescale by 2007.

A.4.1.7.3 The timescale requirement currently stated in the draft IR for FMTP is January 2009. Furthermore, some of the responses to the consultation process propose that the timescale requirement should be pushed back further to align with the timescale requirements of the Interoperability Requirement12; that is April 2011 (note that some of this comment arises from the inclusion of military facilities in the scope of the IR).

A.4.1.7.4 If accepted, the overall effect of this would appear to be an unsatisfactory prolongation of timescales already agreed in the ECIP [4], [5], [6] arising from the application of the SES.

A.4.1.8 Conclusion

A.4.1.8.1 The action COM04 already identified as agreed with timescales in the ECIP [4], [5], [6] but has not yet been endorsed by the SES process.

A.4.1.8.2 However the issue is at a low level of detail in the data communications structure; for example the Eurocontrol Communications Strategy does not mention this objective at overview level.

A.4.1.8.3 We were originally concerned that the means of implementation proposed, consisting of an IR covering a requirement for a detailed technical interface with no associated CS, is the optimum way forward. However, in the view of the EUROCONTROL Regulatory Unit, the use of an IR in this case will be helpful in limiting the risk of technical divergence and we accept the use of an IR for this reason.

12 The Interoperability Regulation states that compliance with the essential requirements shall be required for all systems and constituents of the EATMN currently in operation by 20 April 2011, if not otherwise specified by the relevant implementing rules for interoperability.



A.4.1.8.4 There is a concern that the application of the SES process in this area appears to be driving timescales to the right, by comparison with the existing timescale plans published in the ECIP.


A.4.1.9.1 None – work already performed



A.4.2 IR on Air-Ground Voice Channel Spacing


A.4.2.1.1 The aim of this IR is to mandate the further deployment of 8.33 kHz channel spacing in the Single European Sky area. The IR is supported by Eurocontrol Regulatory Committee.

A.4.2.2 Objective

A.4.2.2.1 Air Traffic Control is currently based on air/ground voice communications between pilot and controller. While some aspects of en-route ATC are increasingly being performed using data communications, voice communications is expected to be the basis of ATC for the foreseeable future.

A.4.2.2.2 ATC demands that a single voice channel is available for each sector and shared between the controller and all aircraft under that controller’s control. One means of increasing airspace capacity is to increase the number of sectors and, in turn this demands an increase in the number of voice communications channels.

A.4.2.2.3 Available spectrum for VHF Voice Communications is limited and all but exhausted. The only way that new voice channels can be found, without a radical technology shift, is to reduce the spectrum occupied by each voice channel. This is being achieved by a move to 8.33 kHz channel spacing. However, this is only possible if all aircraft in a sector are able to communicate using 8.33 kHz channel spacing.

A.4.2.2.4 The purpose of this IR is ensure that additional VHF voice communications channels can be made available in line with the need to increase airspace capacity by mandating aircraft equipage.

A.4.2.2.5 An additional benefit of the IR is that more VHF data communications channels can also be made available through 8.33kHz channel spacing for Voice Communications. Use of datalink based ATC will also increase airspace capacity and reduce the demand for more voice channels.

A.4.2.3 Status

A.4.2.3.1 In order to alleviate the shortage of VHF radio frequencies in the congested upper airspace of the ICAO European Region, the introduction of 8.33 kHz channel spacing was recommended during the European Regional Air Navigation Meeting (EUR RAN - Vienna, 1994) and the Special Communications and Operations Divisional Meeting (SP/COM/OPS - Montreal, March-April 1995).

A.4.2.3.2 On behalf of the EUR RAN and SP/COM/OPS, the European Air Navigation Planning Group (EANPG) delegated in 1995 the development of the 8.33 kHz transition plan to EUROCONTROL. The Agency acts as a programme manager and coordinator for all involved stakeholders.

A.4.2.3.3 The mandatory carriage of 8.33 kHz radio equipment was introduced above FL245 in the ICAO EUR Region on 7th October 1999. Initially, 7 Core Area States enforced mandatory carriage. As part of the Horizontal Expansion programme, a further 23 ICAO EUR Region States enforced mandatory carriage from October 2002.

A.4.2.3.4 The following states now enforce mandatory carriage: Austria, Belarus, Belgium, Bosnia & Herzegovina, Croatia, Czech Republic, Denmark, Estonia, Finland,



France, Former Yugoslav Republic of Macedonia, Germany, Hungary, Ireland, Italy, Latvia, Lithuania, Luxembourg, Netherlands, Norway, Poland, Portugal, Romania, Serbia & Montenegro, Slovak Republic, Slovenia, Spain, Sweden, Switzerland, United Kingdom.

A.4.2.3.5 Work is now progressing to expand vertically the mandatory carriage of 8.33 kHz radio equipment:

Above FL195 in the ICAO European Region from 2006.

In certain busy Terminal Manoeuvre Areas (TMAs) and Control Zones (CTRs), where individual States have determined this to be a practical measure for alleviating VHF congestion (no date specified).

In Designated Controlled Airspace in the ICAO European Region from 2009 onwards.

A.4.2.3.6 There may be state level exceptions for this expansion, including exceptions for General Aviation.


A.4.2.4.1 8.33 kHz channel separation is a straightforward evolution of existing analogue radio technology and as such, the technical issues are mainly those relating to a need to upgrade existing radios. There are also consequential procedural impacts due to changes in phraseology needed to identify the new frequencies.

A.4.2.4.2 In the long term, 8.33 kHz channels are probably the end of the line as far as evolution of analogue technology is concerned. Any further development will require the adoption of digital voice communications.


A.4.2.5.1 Some form of mandate is essential to the continued deployment of 8.33 kHz channel spacing as it is only possible once all aircraft in a given airspace are equipped.

A.4.2.5.2 The deployment of 8.33 kHz is already in progress and supported by state mandates. The IR must be carefully developed to avoid interfering with ongoing activities.


A.4.2.6.1 No CBA has been undertaken for this IR.

A.4.2.7 Timeline

A.4.2.7.1 The timescale for the IR should be compatible with the vertical expansion of 8.33 kHz channel separation below FL245.

A.4.2.8 Conclusion

A.4.2.8.1 The deployment of 8.33 kHz channel separation is an example of a successful project conducted by Eurocontrol and European States.


A.4.2.9.1 None – already under discussion with EUROCONTROL



A.4.3 CS on Ground/Ground Communications (G/G COM)


A.4.3.1.1 This items calls for a community specification for the ‘Definition of the functional specifications and performance of G/G COM. The Functional Specifications developed should take into account the need for the exchange of voice, flight, surveillance, environmental and other data

A.4.3.1.2 It is noted that this is a wide topic and as such, the resultant CS will either have to be partitioned or be sub-divided into separate CSs in order to reflect the diversity of technology in the G/G COM area.

A.4.3.2 Objective

A.4.3.2.1 There are many different applications, each of which have a requirement for Ground-Ground Communications Networks. These are:

A.4.3.2.2 Voice Communications, where ground networks are required to support communications between ATSUs and as a ground infrastructure supporting air/ground voice based controller to pilot communications.

A.4.3.2.3 Voice Communications may either use analogue circuits or digital communications networks. In the latter case, the transfer and delivery of digitised voice is characterised as “time critical” i.e. it must be delivered within a given time if the quality of communications is to be acceptable.

A.4.3.2.4 Surveillance applications, where ground networks are required for the distribution of plot and track data from many different sources including primary and secondary radar interrogators, and ADS-C and ADS-B sources.

A.4.3.2.5 Surveillance data is also “time critical” as its accuracy decays with time, and it is generally better to discard delayed data in order to make way for later but more timely surveillance data.

A.4.3.2.6 Flight Plan Distribution, where ground networks are required to support the receipt of Flight Plans from Airlines and other Aircraft Operators, and the distribution of Flight Plans between ATSUs.

A.4.3.2.7 The transfer and delivery of “Flight Plan” data may be characterised as “data critical”. That is, it is more important to deliver the data intact and with no loss of integrity than to deliver it within a set time.

A.4.3.2.8 Inter-Facility Communications, where ground networks are required to support the exchange of data used for negotiating and supporting the transfer of control of aircraft between ATSUs. This includes data exchange in support of air/ground Controller to Pilot Datalink Communications.

A.4.3.2.9 Inter-Facility Communications are both time and data critical. The messages need to be exchanged in a timely manner and without data loss.

A.4.3.2.10 Air/Ground Communications, where ground-ground network are required to support communications between ANSPs and air/ground communications service providers.

A.4.3.2.11 Air/Ground communications (e.g. CPDLC) is both data and time critical and this requirement also feeds through to the supporting ground infrastructure.



A.4.3.2.12 NOTAMs, Meteorological data, and other information, where ground networks are required to support the distribution of the information from information providers to its users.

A.4.3.2.13 In order to ensure interoperability, there is a need to define the Required Communications Performance (RCP) for each type of data as Community Standards. These will provide a common reference for the procurement and operation of ground networks.

A.4.3.2.14 In addition, it needs to be recognised that there are two levels of information interchange. That is, the data but not time critical applications will use the ICAO AMHS as the means for information distribution, while the other applications will make more direct use of communications services in order to meet their requirements for timely delivery of information.

A.4.3.2.15 There is a need for a CS for the use of AMHS in the European Region in order to ensure commonality of equipment and interoperability. Such a CS will be a “profile” of the ICAO AMHS SARPs.

A.4.3.2.16 There is no requirement for a CS for the underlying bearer networks used by AMHS and other applications. These may include DSL, Frame Relay, and Asynchronous Transfer Mode. However, there is a need for an Internetworking CS, applicable wherever there is a need for interconnection of national or regional networks.

A.4.3.2.17 Network interconnection implies the need to consider security issues and these must be considered as part of the development of Community Standards or as a separate CS.

A.4.3.3 Status

A.4.3.3.1 The Eurocontrol SPACE Programme was funded by the EU ‘Trans European Networks’ projects, and studied and planned the interconnection of four ATSOs (AENA, DFS, NATS & STNA), together with Eurocontrol (primarily the Central Flow Management Unit), using AMHS. It has now completed its work and its deliverables include a European AMHS Implementation Plan.

A.4.3.3.2 SPACE has also developed Functional Profiles for AMHS and these can be the basis of CSs for AMHS.

A.4.3.3.3 Under a separate project, Eurocontrol also developed the EATMP Communications Gateway (ECG). This is primarily a software product for use by ANSPs. It’s functionality should be taken into account when developing a CS for AMHS.

A.4.3.3.4 There are long standing industry standards for the use of TCP/IP networks by the ITU X.400 protocols used by AMHS. These standards are being used by Eurocontrol for AMHS deployment using TCP/IP communications services.

A.4.3.3.5 The Eurocontrol iPAX Task Force has also studied the use of TCP/IP networks in support of aeronautical communications and for a Pan-European TCP/IP network. This work has also included the development of specifications for the use of TCP/IP Networks for the exchange of Surveillance Data, and for the OLDI/FDE application.

A.4.3.3.6 In support of Link2000+, the Eurocontrol Communications Group has developed standards that have now been progressed as ICAO SARPs, for the inclusion of



ground TCP/IP networks as part of the ICAO ATN. These have now been validated and are part of the ICAO specification.

A.4.3.3.7 There is thus common agreement on the use of AMHS for information distribution in Europe and the use of TCP/IP networks as the common internetworking communications service.

A.4.3.3.8 The EUROCAE Working Group (WG67), established in January 2004, is in the process of analysing the today’s utilisation of Voice over IP (VoIP) solutions in ATM environment and developing specifications related to the implementation of "Voice on IP protocol" (VoIP) for ATM applications in the future.


A.4.3.4.1 The main technical issue is the wide variation in the Quality of Service requirements between the applications that will use a Pan European IP Network and how the network supports the differential quality of service.


A.4.3.5.1 The Proposed CSs for RCP are essential starting points for the development of common communications standards. Without them, it will not be possible to have meaningful agreements on the facilities needed for AMHS and IP networks, or the appropriate bearer networks.

A.4.3.5.2 The Proposed CS for AMHS will ensure interoperability and the efficient distribution of information by ANSPs and others.

A.4.3.5.3 The Proposed CS for TCP/IP Networks will ensure interoperability without compromising the different Quality of Service requirements by the different applications that will use it.

A.4.3.5.4 The possible downside of the proposed CSs are that they will result in “technology lock-in”. That is while they will permit flexibility of choice of bearer networks, there will be no flexibility of choice over the technologies used for internetworking and information distribution. It is thus important that both are based on well-known and well supported standards.


A.4.3.6.1 No CBA has been undertaken for this CS.

A.4.3.7 Timeline

A.4.3.7.1 No timeline has been proposed for the development of the necessary standards.

A.4.3.8 Conclusion

A.4.3.8.1 The deployment of AMHS and TCP/IP Networks is already well underway. The adoption of CSs for each technology will help ensure that interoperability is ensured during this deployment.

A.4.3.8.2 CSs for Required Communications Performance are also essential as the main outstanding technical issue is the support of differential Quality of Service and these CSs are needed to define the QoS Requirement for each application.



A.4.3.9 Descriptive text proposed to be included in Commission’s mandate for these CSs

A.4.3.9.1 Error: Reference source not found The Required Communication Performance (RCP) definition currently under discussion at ICAO (OPLINKP) has not reached the level of maturity required to form a basis for a CS. It is therefore suggested to postpone this part of the work till the international groups have agreed on a reasonable concept. This is expected by End of 2005.

A.4.3.9.2 Ground/Ground Communication has a wide use. A single CS for each application is therefore recommended.

A.4.3.9.3 An inventory of Ground/Ground applications and a proposed list of derived CSs should be discussed and agreed by an stakeholder expert group in the course of 2005 and be mandated thereafter.



A.5 Navigation

A.5.1 IR on Required Navigation Performance


A.5.1.1.1 ICB/2/3 [1] indicates that this IR is for the definition of the horizontal and vertical separation/ navigation performance for Precision RNAV and the horizontal and vertical navigation performance for RNP-RNAV in different airspaces, particularly for Precision RNAV (P-RNAV).

A.5.1.2 Objective

A.5.1.2.1 It is assumed that the intent of the IR is to mandate P-RNAV in ECAC airspace. It is noted however, that other forms of Area Navigation could possibly be implemented in a similar time frame.

A.5.1.3 Status

A.5.1.3.1 There is an ECAC wide mandate for Basic-RNAV in European Upper and Lower Airspace. B-RNAV operations within European airspace requires a lateral navigation and along track position fixing accuracy equal to, or better than, 4.6km (2.5NM) for 1 standard deviation and the realisation of a 95% containment value of +/- 9.26km (+/- 5NM). This value includes signal source error, airborne receiver error, display system error and flight technical error. requires an adherence to RNP-5 supported by limited additional navigation functionality. B-RNAV is not suited to use in terminal airspace.

A.5.1.3.2 Precision RNAV (P-RNAV) is an enhancement to B-RNAV which requires that the system must have a lateral navigation and along track position fixing accuracy equal to, or better than, 0.93km (0.5NM) for 1 standard deviation and the realisation of a 95% containment value of +/- 1.85km (+/- 1NM). adherence to RNP-1 supported by additional navigation functions, not least the availability of a navigation database. P-RNAV is currently used in a number of TMAs in Europe. Eurocontrol is supporting the local adoption of P-RNAV.

A.5.1.3.3 RNP-RNAV is a further level of area navigation. The concept of RNP-RNAV is introduced in the Minimum Aviation System Performance Standards (MASPS) for Required Navigation Performance for Area Navigation (RNP-RNAV), RTCA DO 236A / EUROCAE ED 75 RNP-RNAV. RNP-RNAV combines the accuracy standards set out in the ICAO RNP Manual (Doc 9613) with specific containment integrity and containment continuity requirements, as well a functional and performance standards for the RNAV system. The functional criteria for RNP-RNAV address the need for the flight paths of participating aircraft to be both predictable and repeatable to the declared level of accuracy. The RNP Types range from 5 to 0.003. The required accuracy is set dependant on the current airspace or procedure. Typically RNP-0.1RNP-0.3 is required for non-precision approach procedures. RNP-RNAV includes significant additional navigation functions including containment accuracy and fixed radius turns. Some new aircraft are already equipped to RNP RNAV standards, but Currently, no operational procedures exist in Europe. ICAO has implemented an RNP study group to resolve issues on certification, and operational issues.



A.5.1.4 Technical issues

A.5.1.4.1 Required Navigation Performance (RNP): RNP is only may be one parameter in the determination of air-air separation standards. RNP levels should not be set in isolation but take into account other requirements including relevant communication and surveillance requirements.

A.5.1.4.2 According to the Navigation Strategy for Europe RNP1 is envisaged ultimately for the most accurate and efficient route operations in Europe and RNP0.3 is envisaged ultimately for the main TMAs in Europe. RNP0.003/z is planned for CAT III Precision Approach and Landing including touchdown, landing roll and take-off roll requirements. RNP0.1 may also be required for approach procedures.

A.5.1.4.3 Area Navigation (RNAV): The RNAV concept relates to a method of navigation that permits the aircraft to operate on any desired flight path within the coverage of station-referenced navigation aids or within the limits of the capability of self-contained aides or a combination of these.

A.5.1.4.4 B-RNAV (RNAV equipment meeting the RNP5 accuracy requirement) became mandatory for en-route in 1998.

A.5.1.4.5 P-RNAV (RNAV equipment meeting the RNP1 accuracy requirement) is progressively introduced in selected TMAs. PRNAV exists in Norway and Finland and there are plans for introduction in the fall of 2005 in Sweden, Italy, Austria, Switzerland, Belgium, the Netherlands, Greece, France and Spain. According to the European Aviation Safety Agency (EASA) there are no authorized Database producers, and there are some problems concerning the System Safety Assessment. So the proposed implementation of 2005 may be pushed back further.

A.5.1.4.6 RNP-RNAV: P-RNAV would be progressively replaced by RNP-RNAV operations, the concept combining the accuracy standards of ICAO with inter alia specific integrity and continuity requirements plus vertical navigation accuracy in addition to horizontal accuracy for approaches requiring vertical guidance based on either barometrical or geometrical computations. These sensor inputs for position accuracy may be either supported by GNSS (unaugmented), SBAS, GBAS, DME/DME or INS.

A.5.1.4.7 A key issue is to see to it that aircraft capabilities, conventional ground navigation infrastructure and GNSS infrastructure plus airspace planning are analysed and improved in parallel so that the expected benefits accrue in a timely manner. Currently, A typical example is the statement that most of many aircraft are already capable of P-RNAV but cannot use it this since there are no certified databases.

A.5.1.4.8 If an IR is developed for RNP then consideration should be given for the continued development of a common set of tools to validate and monitor the performance of the system.

A.5.1.5 Pros and cons

A.5.1.5.1 Pros:

There is consensus that Safety benefits would accrue, due to harmonisation;

Capacity benefits could accrue from P-RNAV;



Noise containment would result from optimised approach and departure patterns;

Cost reductions and pollution avoidance would result from reduced trajectories.

A.5.1.5.2 Cons:

Migration from B-RNAV to P-RNAV could result in a net cost for aviation (costs exceeding benefits) in case too many exemptions would be granted on a large scale basis due to the high retrofit costs that P-RNAV would incur.. In some TMA’s dual systems will be required causing a greater imbalance in the cost benefit equilibrium. In such an environment, noncompliant aircraft would cause, resulting in an increase of the controllers workload;

Lack of benefits if surveillance and communication dependencies are not taken into account in due time and introduced in a timely manner;

The flexibility to combine station-referenced navigation aids, self-contained aids or combination of these might result in the creation of a “patchwork” of local solutions and equipage levels. This makes interoperability harder to achieve and economies of scale unlikely and plays against the development of aviation in Europe


A.5.1.6.1 An analysis of cost and benefits of P-RNAV and a set of recommendations are available in RNAV Business Case, doc Doc P172DO23 of 23 January 2003. Eurocontrol are currently refreshing this work in light of recent air space simulations on the benefits of P-RNAV and RNP-RNAV.

A.5.1.6.2 Several benefits are expected from improved navigation performances, such as the benefits described in the OCD (Operational Concept document):

Structured Routes: The capability of flights for more accurate navigation and the improved predictive ability of airborne and ground-based systems will enable the current horizontal separation standards to be reduced, resulting in increases in capacity.

Terminal Airspace: The Terminal Airspace of the future will be characterised by:

More accurate navigation found using P-RNAV and integrity monitoring capabilities found using RNP-RNAV, both could perhaps allowing reduced separation minima, reduced spacing between-routes, flexible routes with dynamic route restructuring and Terminal Airspace re-sizing in response to traffic flow so as to use only the airspace necessary to satisfy operations;

Aircraft with 3-D and 4-D navigation capability with RNAV and ASAS, some with the ability to accept responsibility for self-Separation Assurance;

Aircraft noise - The use of automated support tools and advanced navigation aids will help to optimise approach and departure patterns around airports. Without any infringement on safety, support tools will assist in providing a balance between noise abatement requirements the reduction of aircraft emissions;



A.5.1.6.3 In addition it is accepted that, although difficult to quantify, safety benefits would accrue from harmonisation across Europe. Also cost reduction could result from reduced track length and rationalisation of ground infrastructure.

A.5.1.6.4 The level of benefit accrued is dependant upon the level of RNAV adopted. Eurocontrol are currently conducting studies on the level of benefits achieved by P-RNAV and RNP-RNAV.

A.5.1.7 Timeline

A.5.1.7.1 The Navigation Strategy has foreseen that in particular that:

Starting 2005 RNAV would be mandatory in selected TMAs for the departure & landing phases of flight (RNP X) and starting 2010 would be mandatory in all TMAs (RNP X);

The progressive extension of the Free Routes would result in mandating RNP 1 RNAV by 2010;

A rationalisation of the ground infrastructure in particular as SBAS (for Cat 1 operations) and GBAS (for Cat 1 operations progressively followed by GBAS Cat II/III) become available.

A.5.1.8 Conclusion

A.5.1.8.1 It is likely that a change to the existing B-RNAV mandate will be required to support the modernisation of ATM foreseen by the existing strategies. However, it is not yet clear if P-RNAV, RNP-RNAV or a more advanced form of 4D-RNAV would result in the most beneficial change and largest cost benefit.

A.5.1.8.2 In addition to the work on the IR, action could be undertaken to:

Support Eurocontrol’s programme for the progressive introduction of P-RNAV (including development of best practise for the cost effective certification of P-RNAV).

Review the current cost benefit analysis of the various RNP-RNAV levels in order to determine which have the potential to produce the largest benefits (to be always linked to a defined concept of operations).

Take customer wishes and commitments more into account.


A.5.1.9.1 tbd



A.5.2 CS on Ground Based Augmentation Systems


A.5.2.1.1 This item calls for the development of a CS to define the technical requirements for Category II / III precision approaches relying on GBAS. It was included in the Standardisation Mandate M/354 [15].

A.5.2.2 Objective

A.5.2.2.1 Ground Based Augmentation System (GBAS) has been promoted as a replacement for the current Instrument Landing System (ILS). GBAS employs a local monitoring network and VHF data link to uplink differential corrections to GNSS (currently using GPS) signals along with the required final approach segmentpath. GBAS requires the correct operation of the GPS GNSS constellation.

A.5.2.2.2 The objective of this item is to ensure that the necessary standards exist for the timely deployment of GBAS systems supporting Cat II/III operations.

A.5.2.3 Status

A.5.2.3.1 ICAO standards for GBAS Cat I were produced in 2002 and by the end of 2003 EUROCAE had produced MOPS for the MMR (ED-88A) together with MOPS for the ground GBAS component (ED-114). ICAO PANS OPS Doc 8168 Vol II are is in place since 25 November 20042002.

A.5.2.3.2 However, GBAS Cat II/III is still being worked on by the Navigation System Panel of ICAO who are working on the production of high level standards and EUROCAE WG 62 who are working on the production of relevant MOPS for the multi-mode receiver.

A.5.2.3.3 It is understood that significant technical obstacles are still to be overcome before standardisation of GBAS Cat II/III can be finalised.


A.5.2.4.1 GBAS developments in Europe have followed those in US (the FAA LAAS programme).

A.5.2.4.2 It is considered beneficial for EU that European industry retains an independent proficiency in the domain of GBAS. This is especially desirable as it is not clear at the present time whether the US industry will in the future develop GBAS systems which offer any Galileo capability.

A.5.2.4.3 No comprehensive plan seems to be in place in Europe for the deployment of GBAS Cat I ground stations. Two Three reasons for that: the lack of market (the cost of a station would be similar to the cost of an ILS); the lack of a clear transition to GBAS Cat II/III; and the fragmentation of user requirements (in the case of GBAS, airports and operators tend to make local decisions for or against the use of this technology which cannot be combined into a single decision). The only fully funded European programme in place is the SCAT 1 programme for the deployment of 25 SCAT 1 stations in Norway but it is far from offering the characteristics and complexity of a Cat 1 programme DFS GBAS project in Bremen, Germany. This project was funded on 14 March 2005, and is supported by Eurocontrol. Additionally in Malaga, Spain a SCAT-I ground station is being upgraded to the Beta LAAS standard by AENA.



A.5.2.4.4 Performing GBAS Cat II/III landings would may require the use of two frequencies in order to perform the ionospheric correction in the receiver itself. As a consequence performing GBAS Cat II/III landings could not possibly comemay underly certain restrictions before such date when a sufficient number of GPS Block IIF and/or Galileo satellites are operational.

A.5.2.4.5 In order to make use of one single frequency the US industry would recommend downgrading the Cat II/III requirements so as to launch GBAS Cat I on the assumption that a transition would then exist from Cat I to Cat II/III. The FAA seems to line-up with the European approach for uncompromised Cat II/III capabilities. Regarding Cat 1 I operations, the FAA is promoting WAAS with further enhancements to support such capability.


A.5.2.5.1 Pros:

Based on a concept of “ILS Look-alike”, the availability of GBAS Cat II/IIII would procure significant cost savings (one GBAS CAT I station only would be required per airport –or group of airports- whereas one ILS is required per runway end for CAT-I or two for CAT II/III operations); Since the information is being transferred by a digital datalink and the system accuracy is being measured on the ground and not in the air, flight calibration checks will only be required once during procedure implementation. Further, regular calibration flights will not be required unless the final approach segment is changed or additional procedure changes are implemented, and then these flights are on a one-time basis only. These may be caused by changes in height of applicable obstruction.

If the concept is not limited to “ILS look-alike” and uses curved approaches, RNAV benefits may become possible, although the level of benefit is not believed to be high except at a limited number of airports.

GBAS would address the multipath limitations (linked to the ILS technology), a genuine concern for an increasing number of airports. GBAS also requires less maintainance and therefore less downtimes.

The possibility to use GBAS for Cat II/III landings would accomplish the concept of “GNSS sole service”, thus avoiding the deployment of a patchwork of local solutions and equipage levels.

Dual frequencies and dual GNSS constellations will inrease the robustness of the signal and will degrade the influences of non-intentional radio interferences.

A.5.2.5.2 Cons:

The CAT II/III required time to alert time of 1 second coupled with the integrity monitoring and possible ionospheric interference is a technical challenge which may take some time to overcome.

The risks linked to a sole service GNSS strategy could play against the orderly development of aviation. BA have already started investment for MLS operations at Heathrow. However, MLS is not yet a readily available offering from industry.



GBAS requires the correct operation of the GNSS constellations such as GPS and Galileo. This leads to safety and capacity risks in case of intentional jamming and spoofing.

Financial risks if aviation became fully dependant on one or two multi-modal suppliers of signals in space.

Complexity of the transition (in particular concerning frequency availability).


A.5.2.6.1 Eurocontrol are currently conducting a series of projects on ILS replacements. This work includes cost benefit analysis of a number of options including ILS, MLS and GBAS.

A.5.2.7 Timeline

A.5.2.7.1 The initial assumption was that ICAO standards for CAT II/III would be available by 2005/2006 and 3 years would be needed for validation. This would result in GBAS Cat II/III being available at least three years following the successful implementation of CAT Iby 2009/2010 for first operational use.

A.5.2.7.2 It is noted however, that technical difficulties in the definition of GBAS Cat II/II may lengthen this timeframe. Indeed, if it is confirmed that 2 frequencies are required, it will take until a sufficient number of GPS IIF (or of an improved standard) and/or Galileo satellites are in place and operational before GBAS Cat II/III could enter into operation. This is unlikely to take place before 2011/2012 as a minimum.

A.5.2.8 Conclusion

A.5.2.8.1 In addition to the work on the CS, action could be undertaken to:

Support the concept of GBAS II/IIICAT I and continued R&D in order to determine if two frequencies are indeed required for the performance of GBAS Cat II/III landings. Update the Navigation Strategy and transition plan accordingly.

Support the concept of GBAS II/III and continued R&D in order to determine if two frequencies are indeed required for the performance of GBAS Cat II/III landings. Update the Navigation Strategy and transition plan accordingly.

Review the case for the need of GBAS Cat II/III in the light of the results of Eurocontrol studies on the future business case for ILS replacement technologies.


A.5.2.9.1 It is of predominant importance that for the successful implementation of GBAS CAT II/III, an implementation of GBAS CAT I is required. Experience gained from this first step will lead to a faster transition. Airlines and industry are strongly supporting this stepwise approach.

A.5.2.9.2 Technical requirements for GBAS CAT I exist as Standards and Recommended Practices from ICAO in the form of Signal-in-Space performance requirements and the GBAS signal specification. Corresponding Minimum Operational Performance Requirements for on-board equipment exist from RTCA. It has to be secured that Community Specifications will exist



which transform the existing GBAS standards into European regulations. It has to be secured as well that European standards will be developed for GBAS CAT II / III.



A.5.3 CS on Space Based Augmentation Systems


A.5.3.1.1 This item calls for the development of a CS defining the technical requirements for APV I/II (Approach procedure with vertical guidance) relying on EGNOS. This item was included in the Standardisation Mandate M/354. [15]

A.5.3.2 Objective

A.5.3.2.1 EGNOS is able to support approaches with vertical guidance known as APV I and APV II. These approach types are both considered to be non-precision approaches, but use Decision Height/Decision Altiudes to define their minimas. APV II has lower minima than APV I, and is similar to a slightly higher minima (approximately 50 feet) than Cat 1. Currently, CAT I is not possible using SBAS only.

A.5.3.2.2 A performance similar to APV I can be achieved using Baro-aided VNAV as an alternative to EGNOS. (Note: Baro-VNAV only uses GNSS in an unaugmented state.)

A.5.3.2.3 The objective of this item is to enable the timely implementation of APV procedures.

A.5.3.3 Status

A.5.3.3.1 This subject is completed in ICAO Annex 10. Current work in Eurocontrol is aimed at meeting the EGNOS operational date in 2 years time. ICAO ANC/11 recommended that air navigation service providers move rapidly, in coordination with airspace users, with a view to achieving, as soon as possible, worldwide navigation capability to at least APV I performance. States and airspace users shall take note of the available and upcoming SBAS navigation services providing for APV operations and take necessary steps towards installation and certification of SBAS capable avionics.

A.5.3.3.2 Eurocontrol are currently conducting a business case comparing the need, costs and benefits of APVs and Baro-aided VNAV approaches. Both are considered technically feasible and have been demonstrated as such. Standards exist for both, although regulatory material is still under development.

A.5.3.3.3 APV tends to be supported by ANSPs. Baro-aided VNAV procedures are proposed by Airbus, Boeing and Airlines as an alternative. The alternative is supported because it is a self contained system with no necessity to rely on a non aviation third party service provider. Moreover it is a readily available solution offering vertical guidance without a need to address complex issues such as the certification of databases.


A.5.3.4.1 No technical issues reported.


A.5.3.5.1 Introduction of APV1/2 APV I/II relying on EGNOS would be a first application of EGNOS for aviation. As such it would be a first contribution of Europe for the implementation of the ICAO concept of GNSS.



A.5.3.5.2 Pros

Introducing APV1/2 APV I/II based on EGNOS is a pragmatic approach towards the implementation of the GNSS concept, making use of what is currently available to overlay augment the GPS system.

Provided that interoperability with WAAS and other systems such as GLONASS and MSAS comes at no cost for the airspace users, APV 1&2 APV I/II would be available where suitable Ranging and Integrity Monitoring Stations (RIMS) are availableacross the world. This would significantly enhance safety, mainly for operations in parts of the world where the navigation infrastructure is insufficient.

Use of SBAS increases the capabilities of the airspace users for possibly more demanding future navigation and ATM requirements (e.g. ADS)

A.5.3.5.3 Cons:

Manufacturers (in particular Boeing and Airbus) and a number of users promote Baro VNAV as a preferred alternative which has the merit of offering a self contained non-precision approach solution, since it is already available and at no additional cost (avionics upgrades).

In certain European countries there is such a redundant navigation infrastructure already inplace, questioning the need for additional non-precision approach types.

Proliferation of RNP levels plays against economies of scale and interoperability.

The technical and financial future of EGNOS is and Galileo are still unclear. further to the EU decision to launch Galileo


A.5.3.6.1 Eurocontrol are currently developing a business case for APV and Baro-Aided VNAV approaches. The results are expected in the third quarter of 2005.

A.5.3.6.2 The EGNOS Multi Modal Costs and Benefits Study of 1999 had listed a number of benefits of general interest for the EU:

The institutional concerns within Europe related to the lack of direct influence over GPS will be diminished due to the existence of a Europe-wide monitoring network. This will allow more confidence to be placed on the use of the GPS system;

EGNOS will enable a precision vertical guidance approach capability with lower non-precision approach operational minima at most many airports in Europe. This may open the door to business opportunities for regional airlines to operate routes between these airports, which may not have had any published approach procedures, or only RNAV (GPS), NDB-DME, or VOR-DME approaches availableor feeder routes to main airports. There may be a significant number of routes for which the potential volume of traffic, the prices which may be charged and the operating costs would make such a service a feasible proposition. This would could produce economic benefits for the airlines and the communities served and is of particular significance in the light of the emerging “low-cost” airlines servicing regional centres directly;



A.5.3.6.3 Although difficult to quantify at this stage, it is believed that EGNOS could yield benefits for the environment., such as a greater number of constant power approaches and a reduction in flight time because the improved navigation accuracy will reduce fuel burn which in turn will help to reduce emissions (particularly NOx).

A.5.3.6.4 In addition to the benefits of general interest for the EU (see above) a number of operational and financial benefits have been recorded in the 1999 CBA and are listed below:

Lower non-precision minima: Landing would be possible with lower visibility levels at airports not equipped with ILSa precision approach system, thus reducing delays and diversions to alternative airports and cancelled flights. Estimates of these benefits must take account of any additional costs which would become necessary, such as installing or upgrading runway lighting which can cost the same amount as would an ILS ground station..

Curved/segmented non-precision approaches: EGNOS could enable more flexible non-precision approach procedures which would result in time/fuel savings and benefits from reduced noise impact. However, there may be environmental constraints and problems of increased controller workload which may prevent these benefits from being realised. In some countries these benefits cannot be applied, due to the political and noise constraints put on the traffic routings.

Increased runway capacity: Since EGNOS has a smaller critical/sensitive area, it is considered that runway occupancy time and the time between consecutive approaching aircraft and alternate landings and departures could be reduced.

Operations in areas with insufficient conventional navigation aid infrastructure: EGNOS provides a navigation capability for areas where the installation of conventional navigation aids may not be possible or economically viable.

Safety benefits: Safety benefits are inherently difficult to quantify directly as they result from reducing the risk of an accident where injury and/or loss of life may occur. However, from a purely qualitative viewpoint the vertical guidance provided by EGNOS over the ECAC landmass would improve the level of safety over that of Non Precision Approaches (NPA). Statistics show that a high proportion of accidents due to Controlled Flight Into Terrain (CFIT) occur during NPA, during which there is no accurate vertical guidance.

A.5.3.6.5 The cost benefit analysis of EGNOS, conducted in 1999, did not permit to conclude that benefits exceeded costs nor that an EGNOS scenario would be significantly more beneficial than an “enhanced DME scenario”.

A.5.3.6.6 It is acknowledged that the main beneficiaries of an EGNOS/SBAS service would be the General Aviation and Regional aircraft currently not equipped with an IRS. An indirect benefit for all airspace users may occur when these aircraft will make use of enhanced navigation and approach capabilities.

A.5.3.6.7 Users express concern about the recovery of core costs: EGNOS capital and running costs could be recovered from a community of users where the airspace users are only a minority (IATA claimed that airspace users should pay less than 1% of the cost of a multi-modal system offering close to Cat 1I landing capability). This would require precise legal arrangements to ensure that aviation has to pay no more than its fair share of the service. The running cost of EGNOS would be approximately Euro 35 million per annum. Many airlines do not see an increase in capability, thus they do not want to carry the additional costs.



A.5.3.7 Timeline

A.5.3.7.1 EGNOS signal in space would be available by 2006. Certified WAAS, SBAS non-integrated, stand-alone SO-C145 compliant receivers for General Aviation are available since 2004 in the US and their increase equipage in EU can be expected. However neither BOEING nor AIRBUS seem to have any activity ongoing or plans to support EGNOS certification. They rather promote solutions based on Baro-aided VNAV.

A.5.3.8 Conclusion


Require the early production of detailed commercial and legal arrangements concerning the level of service to be supplied and the agreed amount of core costs that would be charged to the aviation community in Europe for the use of EGNOS.

Review the need for an IR based on the latest business case being conducted by Eurocontrol. It is noted that an IR could cover both APV and Baro-aided VNAV if the intent was to ensure the availability of vertical guidance during the approach phase.


A.5.3.9.1 Technical requirements for Approach with Vertical Guidance I/II exists as Standards and Recomended Practices from ICAO in the form of Signal-in-Space performance requirements and the SBAS signal specification. Corresponding Minimum Operational Perfomance Requriements for on-board equipment exist from RTCA (DO-229C). It has to be secured that Community Specifications will exist which transform these standards into the European regulations. The Community Specification shall also express the processes and responsibities for the certification of SBAS-based services.



A.5.4 CS on Galileo/GNSS


A.5.4.1.1 This items calls for a CS defining standards for aviation use of the Galileo navigation system. The item was included in the Standardisation mandate M/354. [15]

A.5.4.2 Objective

A.5.4.2.1 Galileo, along with EGNOS, is Europe’s contribution to GNSS. By providing a constellation in addition to GPS, Galileo will enhance the availability and continuity of service of GNSS. Integrity will also be enhanced by specific mechanisms being designed into Galileo which were not included in GPS.

A.5.4.2.2 The role of Galileo within aviation is however not certain; While the benefit of increased availability and integrity through Galileo is acknowledged, it is currently impossible to identify a financial value for it. Therefore, no Cost Benefit Analysis demonstrating a high level of benefits has been accepted by the community. This is because Additionally, GPS or GPS plus EGNOS is seen by some as sufficient for existing aviation applications. Further work is therefore required to establish and prove a role for Galileo in aviation; this includes investigation of sole means GNSS.

A.5.4.2.3 Whatever the result of benefits calculations, aviation should be ready to be able to use Galileo signals as a world-wide source of navigation signals independent from, but interoperable with, GPS. This requires the production of avionics standards. The objective of this item is to ensure the timely production of such standards.

A.5.4.3 Status

A.5.4.3.1 Current plans envisage Galileo to be operational by 2008. Allowing for delays, the operational use of Galileo for civil aviation could take place around 2010.

A.5.4.3.2 In support of this:

Standards (SARPS) are currently being produced within the ICAO process.

EUROCAE WG-62 is working on the production of initial MOPS for the first generation of GALILEO airborne receivers.


A.5.4.4.1 Galileo would be either an alternative to GPS or would be operated in combination with GPS.

A.5.4.4.2 As an alternative, Galileo would not offer to the aviation community major advantages above GPS IIF (or improved versions thereof) in particular if GPS is augmented by EGNOS, WAAS, MSAS and other regional overlay systems. Moreover GPS is offered free of charge (at least for the time being).

A.5.4.4.3 Combining GPS and Galileo is promising. This scenario raises a number of technical issues in particular concerning the interoperability of the signals, but is probably key for the implementation of a sole service GNSS across the world (see below).




A.5.4.5.1 Potential benefits for EU

Galileo would be a major European contribution to the ICAO GNSS strategy

The institutional concerns within Europe regarding dependency on GPS would disappear

A.5.4.5.2 Full confidence would be placed on the use of the GPS system due to the combined use of GPS plus Galileo.

A.5.4.5.3 The GOBAN (GNSS Roadmap Study) of 2003 [21] has compared a GNSS scenario with Galileo and a GNSS scenario without Galileo in order to determine what the contributions of Galileo could be.

A.5.4.5.4 It concluded that (subject to confirmation of some technical hypothesis) a combination of GPS II/F, plus SBAS plus GBAS for Cat II/III plus INS/IRS integrating a GPS-derived position update capability would allow for world-wide operations for all phases of flight.

A.5.4.5.5 According to the GOBAN study Galileo potential contribution might then be:

Avoid the deployment of a SBAS infrastructure world-wide, which could prove to be an expensive solution unless SBAS is marketed as a multi-modal product, with aviation paying only a small share of the total cost.

Reduce the number of places where GBAS Cat I would be required in spite of availability of SBAS, due to geometry (mountains).

Offer “better than SBAS Cat I” landing capability, providing that the potential benefits exceed the cost of the lighting systems.

Offer aircraft, other than first level aircraft, an alternative to INS/IRS or to SBAS for NPA if SBAS avionics do not come out cheap.

Reduce the requirements for INS/IRS to two rather than three pieces of equipment for first level aircraft.

A.5.4.5.6 Yet according to the GOBAN study the most beneficial contribution from Galileo is to avoid a political debate centred on sovereignty (USA versus rest of the world) and on civil versus military GNSS ownership. Even where regions would have developed their own SBAS and GBAS systems, such as EGNOS for Europe, GPS dominance could still be seen as excessive and a number of states or groups of states would impose to keep at least one conventional infrastructure (DME or VOR) as back-up. This would seriously impact on the total cost of the navigation infrastructure, both on the ground and in the cockpit.


A.5.4.6.1 Price Water House Coopers conducted a multi-modal CBA of Galileo [24] which indicated significant benefits to the aviation community but this study has been largely discredited by the aviation community for including benefits more appropriately accorded to other improvements including those enabled by the Interoperability Regulation.

A.5.4.6.2 Further detailed analysis of the operational use of Galileo and in particular of new services enabled by Galileo over GPS/EGNOS is required to make the economic case for aviation supporting the costs of Galileo.



A.5.4.7 Timeline

A.5.4.7.1 Based on the above, decisions and implementation are highly dependant on:

plans for the upgrade of GPS (timing of the deployment of the constellation, pricing);

plans for the deployment of a world-wide (or only regional) overlay for GPS offering APV I/II (or possibly Cat I landing capability when GPS II/F is available);

the feasibility of achieving GBAS Cat II/III based on two frequencies;

the availability of a Galileo service for aviation. In this respect it is currently planned that the satellites would be in place in 2008 but a service for aviation would not be available before 2010

A.5.4.8 Conclusion

A.5.4.8.1 Development of this CS should enable commercial air transport, general aviation users and manufacturers: to profit by a window of opportunity for a cost effective migration towards the use of robust GNSS services. These services are based on GPS (partially with SBAS) and Galileo around 2010 when a single receiver for both Galileo and GPSII/F should be available.


Monitor activities on GPS, SBAS and GBAS Cat II/III over in conjunction with GPS because the analysis of Galileo / GNSS cannot be done in isolation from what is done or planned for GPS

Monitor and influence the commercial and legal arrangements surrounding the concession of Galileo to a third party service provider so that the interests of airspace users and air traffic service providers are taken into account. At the same time give the manufacturing industry sufficient comfort as to potential revenue streams.


A.5.4.9.1 Technical requirements for Galileo exist as generic GNSS Standards and Recommended Practices from ICAO in the form of Signal-in-Space performance requirements. The corresponding signal specification will be developed until 2007. Corresponding Minimum Operational Performance Requirements for on-board equipment are currently being developed by EUROCAE (WG62). It has to be secured that Community Specifications will exist which transform these standards into the European regulations. The Community Specification shall also express the processes and responsibilities for the certification of Galileo-based services.



A.6 Surveillance

A.6.1 IR on Surveillance Requirements


A.6.1.1.1 This IR calls for: ‘definition of the surveillance performance and interoperability requirements’. It is understood that the IR is intended to mandate a common level of performance and interoperability for surveillance data. A number of CSs (see below) are required to support the IR.

A.6.1.2 Objective

A.6.1.2.1 For safe ATM operations, reliable, consistent surveillance information concerning the targets is required by the controller and aircrew. The objective of this IR is to define a common framework for defining surveillance throughout the SES area.

A.6.1.2.2 This IR supports the development of a Required Surveillance Performance (RSP) that can be applied, measured and monitored within each SES airspace block. This will enable a set of common ATM operations, procedures and systems throughout Europe.

A.6.1.3 Status

A.6.1.3.1 Standards will be required to form the technical basis for compliance with the IR. The EUROCONTROL Standard Document for Radar Surveillance in En-Route Airspace and Major Terminal Areas is available but this is restricted to mono-radar environment for:

5NM separation in enroute airspace enabled by dual SSR coverage.

3NM in major TMA enabled by single primary radar and dual SSR coverage.

A.6.1.3.2 The ICAO Surveillance and conflict resolution systems panel (SCRSP), Working Group B is tasked to develop ICAO material on RSP for surveillance systems. When completed, updates may be required to ICAO Annexes (5, 10, 11) and Documents 4444, Reg. Supp. Doc 7030 and the EUR ANP Doc 7754.

A.6.1.3.3 Interoperability can be ensured through the standardisation process in ICAO, EUROCAE and ETSI.


A.6.1.4.1 A common framework for defining RSP is required for the whole SES applicability area. The RSP framework could define the quality of the following performance parameters for each target (where a target is anything in the air):

Position accuracy.

Identification.

Mode of flight (such as direction or speed).

The requirements for Aircraft Derived Data.

The Required Communication Performance (RCP) and Required Navigation Performance (RNP) necessary to enable the RSP.



A.6.1.4.2 Different airspace blocks may implement their own RSP based on local operational needs and traffic. It is also anticipated that different RSPs will be required based on the type of ATM operations. For example, the RSP whilst operating parallel approaches will be different from en-route upper airspace or ASAS spacing. Consideration should therefore be given to transition issues when moving from one RSP area to another RSP area.

A.6.1.4.3 In addition, the RSP should take into account the emerging ASAS spacing and separation surveillance requirement in the cockpit. This would include the quality of the information presented to the aircrew and the automated tools which will be used to support the emerging airborne applications.

A.6.1.4.4 The RSP should be independent of surveillance technique and technology in order to permit stakeholders flexibility in the surveillance solutions they implement in their airspace or aircraft. Therefore the "EUROCONTROL Standard Document for Radar Surveillance in En-Route Airspace and Major Terminal Areas” is not the approach to realise this IR. It is too technology oriented and is not linked to the RSP. It is noted that ICAO documentation and the EUROCONTROL surveillance standard is currently being updated to incorporate ADS-B and multi-lateration techniques and RSP considerations should be encouraged in its update.

A.6.1.4.5 If an IR is developed for surveillance then consideration should be given for the continued development of a common set of surveillance tools to validate and monitor the performance of the system. The Eurocontrol surveillance domain currently maintains the SASS toolkit (SASS-S for validation of the sensors and SASS-C for centre SDPD validation). Although these tools would not form part of the IR, the common development by Eurocontrol of such tools would provide a centralised, cost effective support system for RSP.


A.6.1.5.1 No analysis undertaken.


A.6.1.6.1 No CBA has been undertaken for this IR.

A.6.1.7 Timeline

A.6.1.7.1 No Separation standards are defined today by ICAO and guidance is provided for further development. ICAO are in the process of developing an RSP framework. The necessary CSs are required prior to implementing the IR.

A.6.1.8 Conclusion

A.6.1.8.1 The proposed IR defines the quality of the output of the surveillance function (typically at the output of the tracking system) for presentation to the controller, aircrew or automated systems. In order to avoid a prescriptive solution, the IR should not define which techniques are used to develop the surveillance picture (i.e. ANSPs should be permitted flexibility to choose the most appreciate surveillance technique – radar ADS, Multilateration – to meet the RSP). Guidelines with respect to how to achieve the RSP may be developed to accompany the regulation.




A.6.1.9.1 Should be discussed within SESAME (reason: see above ‘Timeline’)

A.6.1.9.2



A.6.2 IR on the Mode S II Interrogator Addressing Plan


A.6.2.1.1 This IR calls for the co-ordination of the allocation of Mode S Interrogator Codes on a European basis. The IR was initially proposed in the ATM-CNS Interoperability Roadmap Study [2].

A.6.2.1.2 Mode S Interrogator Code allocation is currently within the remit Mode S IC Allocation Cell of the EUROCONTROL Communication and Surveillance Business unit.

A.6.2.2 Objective

A.6.2.2.1 The objective of this IR is to mandate a regulatory framework for the allocation of II codes in support of the deployment of Mode S radars.

A.6.2.2.2 The acquisition of Mode S radar installations by Air Navigation Service Providers (ANSPs) and by Military Authorities in several European States has focused attention on the need to establish a single European interrogator code allocation mechanism.

A.6.2.2.3 There is currently no regulatory material relevant to the issue of Mode-S station IC allocation. This IC allocation is performed on a collaborative basis for the time being, as the real needs are limited to some trial and demonstration stations.

A.6.2.3 Status

A.6.2.3.1 On the 1st September 2002, the formal Mode S IC Allocation Cell (MICA) was established. MICA is responsible for the technical allocation of IC codes.

A.6.2.3.2 The Mode-S IC Co-ordination Group is a EUROCONTROL Working Arrangement with official representatives from national and military authorities responsible for the regulation of IFF and SSR sensors operating in the 1030/1090 MHz frequencies.

A.6.2.3.3 The Mode S IC Co-ordination Group is responsible for reviewing allocation proposals, producing allocation procedures and guidelines, handling/resolving disputes and interfacing with the ICAO regional Office for the inclusion of IC Allocations as a supplement to the Air Navigation Plan.

A.6.2.3.4 On 4th February 2005 ICAO formally approved a proposal for amendment of the ICAO EUR Air Navigation Plan which included delegation of the management of the plan from ICAO to EUROCONTROL.


A.6.2.4.1 Mode S sensors or clusters of Mode S sensors require a unique Interrogator Identifier (II) code and/or a Surveillance Identifier (SI) code, collectively referred to as Interrogator Codes (IC). These uniquely identify the Mode S ground station that is interrogating an aircraft at a particular time. If an aircraft in roll call status receives an all call interrogation from two a second Mode S ground stations with the same IC then it cannot distinguish which is which will not response to the all call and there is the potential that an aircraft is not acquired and detected by this Mode S ground station or for information to be lost because it may be received by the wrong Mode S ground station.



A.6.2.4.2 There are only 15 II and 63 SI codes that can be operationally assigned (special use of II Code zero and SI Code zero are not used). Therefore the IC assignment can must be managed to ensure that identical codes are not used in overlapping Mode S coverage areas.

A.6.2.4.3 The Implementing Rule should define the Mode-S stations IC allocation procedures at the European level. This material would therefore be used each time a new Mode-S station is deployed in order to select the appropriate Interrogator Code among the 63 78 available ICs in minimising the interference risks. It has to be taken into consideration that SI codes will not be available prior to 2007. Until SI codes can be used for operation only 15 IC are available.

A.6.2.4.4 Conformity Assessment of these allocation procedures could be defined to ensure that the codes allocated are not creating interference.

A.6.2.4.5 Following these procedures, the codes allocated can then be included in the ICAO Air Navigation Plan as a supplement.

A.6.2.4.6 The procedures to be regulated have already been identified during EUROCONTROL Mode-S Programme, with a formalisation of the IC request and code attribution procedures. The architectural and functional structure is well established and extensively defined in ICAO and EUROCONTROL corresponding documents. It is the Mode-S station IC allocation procedure that shall be ruled, and not the allocation plan itself An initial IC allocation plan and formal procedures for maintenance and change should be ruled.


A.6.2.5.1 The IR would support the correct operation of Mode S elementary and enhanced surveillance. It is noted that the current voluntary arrangements have not been tested.


A.6.2.6.1 No CBA has been performed on the provision of a regulatory framework for IC allocation. The baseline voluntary arrangements have not been tested.

A.6.2.7 Timeline

A.6.2.7.1 A mechanism for Mode S IC allocation is already needed. Eurocontrol already operate such a system. If an IR is to be promulgated it could be done so immediately.

A.6.2.8 Conclusion

A.6.2.8.1 It is noted that Mode S has a well-established framework for European implementation. Support from EUROCONTROL in the transition and implementation phase is operating with the approval of the stakeholder community.

A.6.2.8.2 The need to replace the current co-ordination scheme for Mode S IC allocations has not been demonstrated. It is recognised that a regulatory framework would support the continued success of this process as Mode S deployment increases.




A.6.2.9.1 The procedures to be regulated have already been identified during EUROCONTROL Mode-S Programme, with a formalisation of the IC request and code attribution procedures. The architectural and functional structure is well established and defined in corresponding documents. An initial IC allocation plan and formal procedures for maintenance and change should be ruled.



A.6.3 CS on Surveillance Data Processing ARTAS


A.6.3.1.1 This item was raised as an IR in ICB/2/3 [1]. The purpose of this as an IR is was to mandate ARTAS as a means of ensuring the interoperability of surveillance networks. It has subsequently been concluded that this would be better established as a CS because it concerns the deployment of a standard interface between systems.

A.6.3.2 Objective

A.6.3.2.1 This CS is aimed at the introduction of common surveillance data processing functionality (e.g. ARTAS or equivalent) as a common means for the exchange of surveillance data.

A.6.3.3 Status

A.6.3.3.1 The Eurocontrol ‘Guidelines For An Agreement For The Shared Use Of Radar Sensor Data’ [22] sets out a number of principals for the sharing of radar data. It makes reference to the ASTERIX standard and sets out guidelines for setting up an agreement between the supplier and user of radar data.

A.6.3.3.2 Whilst the deployment of ARTAS is encouraged by EUROCONTROL there are no mandates or ECIPS for ANSP to abide by.

A.6.3.3.3 ECIP SUR03 [6] (which has been formally achieved) requires the Implementation of radar data processing and distribution systems based on radar server technology. Specifically it requires Provision of Multi-radar surveillance data processing and distribution (SDPD) at ACC level.


A.6.3.4.1 ARTAS is the concept of a Europe-wide distributed Surveillance Data Processing and Distribution (SDPD) system which has been developed by EUROCONTROL for implementation in the ECAC area. The system concept relies on the implementation of interoperable SDP Units which all co-ordinate together to act as one region-wide integrated Surveillance system. The elements to build such an SDPD network are the ARTAS Units, or any other SDPD system fulfilling well defined interoperability requirements.

A.6.3.4.2 The interface between ARTAS, the data sources (e.g. radar) and its ATM User systems (e.g. a sensor or other ARTAS units) are based on ASTERIX. There are three standards relating to inter SDPD data exchange, namely:

System track data (ASTERIX Cat 062)

Sensor Status messages (ASTERIX Cat 063)

SDPS Service status messages (ASTERIX Cat 065)


A.6.3.5.1 Whilst the use of ARTAS is encouraged, no regulations exist for the operational use of the system. However because ARTAS is a EUROCONTROL standardised product, supported through CAMOS certain advantages can be recognised. For the stakeholder, the development of ARTAS is essentially ‘free’. As the holder of



all relevant Intellectual Property Rights of the ARTAS Application Software, EUROCONTROL is in a position to offer ARTAS to any of its stakeholders. Additionally, software tools (e.g SASS-C) are available to support site acceptance.

A.6.3.5.2 A Surveillance Data Processing System monopoly should be avoided, since it hinders further development and may raise associated costs. Therefore, a more general CS on SDPS seems more appropriate.


A.6.3.6.1 A CBA was developed for the use of ARTAS. The cumulative net benefit for ARTAS in comparison to the Non-ARTAS scenario ranges between 44 to 184 MEuro.

A.6.3.6.2 The ARTAS CBA has resulted in a number of stakeholders adopting ARTAS however the majority of ACCs in ECAC still have proprietary solutions.

A.6.3.7 Timeline

A.6.3.7.1 ARTAS is already an operational technology.

A.6.3.8 Conclusion

A.6.3.8.1 The wide deployment of ARTAS and the ASTERIX categories, which define its interface, reflect that ARTAS is a well-defined EUROCONTROL product. However, ARTAS is seen as one particular technical solution

A.6.3.8.2 A CS on data exchange, associated protocols and interfaces is much more important to ensure interoperability than a CS on one particular technical solution (see A.6.4 CS on Surveillance Data Exchange).

A.6.3.8.3 In addition to the work on the CS, aAction could be undertaken to ensure that the interoperability provisions of this CS are included in the generic IR on Surveillance DataRequirements.


A.6.3.9.1 A Europe-wide distributed Surveillance Data Processing and Distribution (SDPD) system concept for implementation in the ECAC area should be supported. The system concept relies on the implementation of interoperable SDP Units which all together act as one region-wide integrated Surveillance system.

A.6.3.9.2 The purpose of this CS is to define the elements to build such an SDPD network. It should be specified based on well defined interoperability requirements, which include quality of information and performance requirements as well as specification of interfaces and protocols between the data sources (e.g. radar) and ATM User systems (e.g.SDPS) and/or for inter SDPD data exchange.



A.6.4 CS on Surveillance Data Exchange


A.6.4.1.1 This CS calls for the definition of a common format for the transfer of surveillance information. The intent is that this standard is based on the existing ASTERIX standard. The CS was included in the Standardisation Mandate M/354 [15].

A.6.4.2 Objective

A.6.4.2.1 The objective of this CS is to develop a standardised data format for the exchange of surveillance information between:

components of the surveillance system (e.g. radars, multi-lateration systems, ADS-B receivers and SDPD) and;

between the surveillance function and other ATM functions.

A.6.4.3 Status

A.6.4.3.1 The ASTERIX standard is considered the most appropriate to achieve this CS. It is generic (e.g. not relying on any underlying communication protocol) and is constantly updated to accommodate new surveillance systems and stakeholder needs. The objective of the All Purpose Structured EUROCONTROL suRveillance Information eXchange (ASTERIX) is to develop standards, specifications and guidelines related to the formatting of the surveillance-related data, exchanged between surveillance sensors and surveillance data processing systems.

A.6.4.3.2 The EUROCONTROL Agency has established a number of groups to aid the definition of ASTERIX and related standards. These are:

Surveillance Architecture Focus Group (SAFG) for the maintenance of the Surveillance Functional Architecture and the coordination of ASTERIX standards

Surveillance Task Force for Radar Data Exchange (STFRDE)Surveillance Data Exchange – Focus Group (RDE-FG) for the detailed definition and maintenance of the ASTERIX standard

A.6.4.3.3 The Eurocontrol ‘Guidelines For An Agreement For The Shared Use Of Radar Sensor Data’ [22] sets out a number of principals for the sharing of radar data. It makes reference to the ASTERIX standard and sets out guidelines for setting up an agreement between the supplier and user of radar data.


A.6.4.4.1 ASTERIX is accepted as the standard for data exchange within the Surveillance community. However ASTERIX only defines the data shared between users and the resolution of that data, it does not define the quality of the information (which is considered in section A.6.1 IR).

A.6.4.4.2 ASTERIX can only be of benefit if a common understanding of the operation of the surveillance source is standardised. Therefore EUROCONTROL have developed the Surveillance Functional Architecture (SFA) as guidelines for the functional structure of the surveillance system (which in turn is consistent with OATA). The SFA is the ‘glue’ between each of the ASTERIX categories defining the information flow between surveillance components. The SFA provides guidelines



for the basic surveillance processing of each surveillance component, the input and output of each component and the ASTERIX categories used to exchange information between the components.

A.6.4.4.3 The Surveillance Functional Architecture and the ASTERIX standard are highly dependent upon each other.

A.6.4.4.4 The exchange of surveillance information between ACCs is further complicated by the need to provide ‘seamless’ data (an example of which is the smoothed track handover function in ARTAS) to ensure a smooth handover of aircraft between functional airspace blocks.

A.6.4.4.5 The inclusion of guidelines relating to how the exchange could be established and operated, and thus extend the general principals outlined in [22], would support the implementation of this CS.


A.6.4.5.1 Harmonisation of interface and procedures brings a number of benefits [23] including:

Shorter development times with more off-the-shelf products

Fewer manufacturing product lines, simplification of production and lower costs

Standardised maintenance and training


A.6.4.6.1 No CBA has been undertaken for this CS. However through the definition of common interfaces between surveillance components it is recognised that costs are reduced for implementation.

A.6.4.7 Timeline

A.6.4.7.1 ASTERIX is a mature standard, it is anticipated that a CS could be developed within one calendar year.


A.6.4.8.1 ASTERIX is a mature EUROCONTROL standard for Surveillance data formats which is being widely used within Europe.

A.6.4.8.2 . The purpose of this CS is to define common sets of surveillance data and their formats to be used between surveillance data sources and user/ATM systems and between ATM systems to support seamless surveillance. The CS should adopt the formats already defined in the ASTERIX Standard.



A.7 Aeronautical Information Services

A.7.1 IR on Aeronautical Data Integrity


A.7.1.1.1 The objective of this proposed Implementing Rule is to supplement and strengthen ICAO Annex 15 (Aeronautical Information Service) [24].

A.7.1.1.2 Provision of a legal requirement for Aeronautical information services is currently through ICAO Annex 15, which states:

“The object of the aeronautical information service is to ensure the flow of information necessary for the safety, regularity and efficiency of international air navigation. The role and importance of aeronautical information/data changed significantly with the implementation of area navigation (RNAV), required navigation performance (RNP) and airborne computer-based navigation systems. Corrupt or erroneous aeronautical information/data can potentially affect the safety of air navigation.”

A.7.1.1.3 The requirements for Annex 15 are primarily for publication - origination of data to meet these requirements is not explicitly dealt with. Annexes 4 (Aeronautical Charts) [25], 11 (Flight Information Services) [26] and 14 (Aerodromes) [27] supplement Annex 15 providing requirements for terrain and survey accuracies and resolutions.

A.7.1.2 Objective

A.7.1.2.1 The objective is to mandate practices that enable users and providers of aeronautical information to provide that information with a measurable degree of accuracy and integrity.

A.7.1.2.2 It is noted that some states believe that the ICAO requirements are sufficient regulation and that EUROCONTROL efforts should be to provide guidance on how to achieve those requirements.

A.7.1.2.3 EUROCONTROL presented a paper at the 11th ICAO Air Navigation Conference which resulted in ICAO stating a requirement to:

support a digital, real-time, accredited and secure aeronautical information environment

urgently adopt a common aeronautical information exchange model, taking into account operational systems or concepts of data interchange, including specifically, AICM/AIXM

develop, as a matter of urgency, new specifications for Annexes 4 and 15.

A.7.1.2.4 It is likely that regulation in this area would lead to a more harmonised approach to AIS provision, however, the scope of the IR needs to be carefully negotiated with the user community so that it promotes best practice rather than legislates for the lowest common denominator.

A.7.1.3 Status

A.7.1.3.1 In addition to the ICAO Annexes, industry has also developed standards in the form of RTCA and EUROCAE documents:



RTCA DO-200A / ED -76 Standards for Processing Aeronautical Data [to be added to Appendix C References];

RTCA DO-201A / ED-77 Standards for Aeronautical Information [to be added to Appendix C References];

ED 98 User Requirements for Terrain and Obstacle Data [28];

ED 99 User Requirements for Aerodrome Mapping Information [29].

A.7.1.3.2 In January 2003, EUROCONTROL first issued its proposed Guidance Material for Aeronautical Data Origination. New guidance material is intended to replace the EUROCONTROL Survey Standard (Doc 007) [30] whilst also addressing new aspects such as:

Terrain and obstacles data;

Heighting requirements;

Data management and integrity assurance.

A.7.1.3.3 The guidance material is currently under further development and review within a wider family of documents entitled Aeronautical Data Integrity. These set of documents concerns the entire data integrity chain up to the point of publication by States and is, in itself, the subject of an A-ENPRM (Advanced EUROCONTROL Notice of Proposed Rule Making).

A.7.1.3.4 Currently, however, EURCONTROL does not pursue any activities leading to a standardized European procedure to monitor compliance with these regulations.

A.7.1.3.5 During the course of producing the Aeronautical Data Integrity document set, a number of issues associated with current ICAO standards arose. These issues are not new to the wider navigation and AIM communities and States. Several attempts have been made to resolve them. However, the publication of guidance material that might – in the future - be raised to the status of regulatory material (via an ENPRM or similar action) has now resulted in the need for immediate action.

A.7.1.3.6 Some of the issues pertaining to data origination include:

Discrepancies in scope and requirements for aeronautical data between different ICAO Annexes;

Discrepancies in definitions and subsequent interpretation between ICAO Annexes;

The lack of any suitable guidance with respect to terrain and obstacles data;

The need to establish a common reference frame for vertical surveyed data.

A.7.1.3.7 Many States have begun to identify potential solutions. In particular, the most recent proposals by ICAO (dated 18 July 2003) to update Annex 15 with the consequent amendment to Annexes 4, 11 and 14 with respect to terrain and obstacles data and the introduction of a common vertical datum.

A.7.1.3.8 As a result, EUROCONTROL has identified the need to consolidate all of the recommended changes to ICAO Annexes pertaining to data origination in a single document for submission to the Air Navigation Commission. This will provide an Agency position on:



The resolution of ambiguity in the definition used within different Annexes;

The changes that are necessary to adhere to latest guidance;

Areas in which further work or analysis may be required;

The relationship between data origination and wider AIM issues and amendments.

A.7.1.3.9 As a result of this document, EUROCONTROL will recommend an optimum way forward and a suitable approach towards achieving the required changes. This document has been developed in such a way that it forms an enclosure to a covering letter for communication from the Agency to third parties as required. Any subsequent programme for change shall be managed in conjunction with parallel and co-ordinated efforts from the EUROCONTROL AIM programme.

A.7.1.3.10 Recognising the importance that Aeronautical Information has in aviation, EUROCONTROL is also in the process of implementing the CHAIN (Controlled Harmonised Aeronautical Information Network) programme as a continuation of the AIM work.


A.7.1.4.1 The main issue for aeronautical information is establishment of the required level of integrity throughout the entire data chain. In achieving this level of integrity it will be necessary for all users in the chain to be using the same processes, or processes certified to a common standard.

A.7.1.4.2 The current technical issues associated with the data exchange are being resolved by EUROCONTROL using the AIXM model. The main issues are:

Repeated input at each function, resulting in: Risk of error, Loss of integrity, Lost audit trails, Multiple checking and Media breaks.

Lack of interoperability, specifically: Data exchange, Data formats, Inefficient, fragmented processes and Procedures & Guidance & “tools”.

A.7.1.4.3 The AICM/AIXM model has the support of ICAO and the FAA and documentation on the model is well publicised on the EUROCONTROL AIS website [31].


A.7.1.5.1 The benefits of regulating the provision of aeronautical information can be summarised as follows:

Each user of aeronautical data down the chain can be assured of the quality of the data that they are using;

Aeronautical data that is of the required integrity level is necessary for the navigation applications that require high levels of integrity.

Evidence will exist that the ICAO requirements will/are being achieved.

Safety will be increased – especially with respect to RNAV operations and GNSS based operations.

A.7.1.5.2 The integrity of aeronautical information from the point of publication has been regulated through the use of RTCA DO-200A Standards for Processing



Aeronautical Data. The origination of aeronautical data up to the point of publication is not subject to the same level of inspection.

A.7.1.5.3 Requirements for aeronautical data are provided by ICAO. However, there exist differences between the various ICAO requirements, depending on the Annex in which the information is presented.

A.7.1.5.4 The benefit of providing regulation of Aeronautical Information ensures that all originators provide information to the same level of accuracy and to the same standard. Moving publication of aeronautical information into the electronic format (eg AIXM) will eventually aid in the reduction of costs of processing this data by the data houses and provide end users a quicker way of verifying the data in use. However, issues concerning the legal ownership of aeronautical data will need to be resolved. ICAO is currently developing “Guidelines for the Use of the Public Internet for Aeronautical Applications” where the issue of intellectual property is also raised.

A.7.1.5.5 Further examination is required on the effect that a regional regulation will have on aeronautical information. Aviation is a global business and aircraft tend to be able to fly further than the confines of the regulatory sphere of Europe. To gain the full benefits of the standardisation of processes and regulation, there needs to be a global approach and therefore the support of ICAO gained at all stages. This ensures that those states that recognise the regulation of ICAO will also will have a common standard.

A.7.1.5.6 To be successful, the approach needs to be global. However, even a local regulation will have some benefits in the reduction of the level of inconsistencies and errors within ECAC AIPs.

A.7.1.5.7 However, any regulation that is applied within ECAC must be consistent with ICAO since the data generated with ECAC will be used throughout the world and states not in ECAC must be assured of the integrity of information being supplied.


A.7.1.6.1 CBA activity will be performed in the CHAIN programme to support the IR drafting process.

A.7.1.7 Timeline

A.7.1.7.1 Approval on whether to proceed with the CHAIN programme is likely to be given in Q1 2005. Approval of the programme is very likely. Initial approval will be for PHASE I focusing on Development and Implementation Support for the upstream data chain. PHASE I will last for approximately three years until the end of 2007.

A.7.1.7.2 If it is required and authorisation obtained from EUROCONTROL, a PHASE II is envisaged.

A.7.1.8 Conclusion

A.7.1.8.1 The proposed EUROCONTROL CHAIN program is designed to strengthen AIS provision in Europe. A number of underlying CSs will also need development, for example the AIXM model. AIS is a global service; new standards and regulations must support global interoperability.



A.7.1.8.2 In addition to the work on the necessary CS, action could be undertaken to ensure that the scope of the mandate is carefully controlled to support the widespread adoption of best practice within AIS origination and provision.


A.7.1.9.1 The objective of this Implementing Rule is to ensure that aeronautical information is provided with a measurable degree of accuracy and integrity from origination through to the publication of data. The Implementing Rule should be consistent with existing ICAO standards as well as EUROCONTROL guidance material. It should be carefully negotiated with the user community so that it promotes best practice rather than legislates for the lowest common denominator.



B Acronyms

ACAC Air Control Area Commander

ACARS Aircraft Communications Addressing and Reporting System

ACC Area Control Centre

ACM ATC Communication Management

ADEXP ATS Data Exchange Presentation

AENA Aeropuertos Españoles y Navegación Aérea

A-ENPRM Advanced ENPRM

AGDL Air-Ground Data Link

AHLM ATM/CNS Higher Level Model

AIC Aeronautical Information Circular

AICM Aeronautical Information Conceptual Model (EAD)

AIM Aeronautical Information Management

AIP Aeronautical Information Publication

AIS Aeronautical Information Services

AIXM Aeronautical Information Exchange Model

AMAN Arrival Management

AMC ATCMicrophone Check

AMHS ATS Message Handling System

AMS Aeronautical Mobile Service

ANP Actual Navigation Performance

ANSP Air Navigation Service Provider

ANT Airspace and Navigation Team

AO Airlines Operator

APP Approach Centre / Control

APV Approach with Vertical Guidance

ARTAS ATC Surveillance Tracker and Server

ASA Aircraft Situation Awareness

ASAS Airbourne Separation Assurance Systems

ASD Airspace Design

ASM Airspace Management

ASMGCS Advanced Surface Movement Guidance and Control System

ASTERIX All Purpose Structured Eurocontrol Surveillance Information Exchange

ATC Air Traffic Control

ATCO Air Traffic Controller

ATCU Air Traffic Control Units



ATD Air Traffic Services Development

ATFCM Air Traffic Flow and Capacity Management

ATFM Air Traffic Flow Management / Gestion des courants de trafic aérien (FR)

ATIS Automatic Terminal Information Service

ATN Aeronautical Telecommunication Network / Réseau de télécommunications aéronautiques (FR)

ATS Air Traffic Services

ATSO Air Traffic Services Operator / Organistaion

ATSU Air Traffic Service Unit

BDS Binary Data Stream

B-RNAV Basic Area Navigation / RNAV de base

CAFT CNS/ATM Focus Team

CALM Computer-assisted Approach and Landing Management

CAMOS Central ARTAS Maintenance & Operational Support

CANSO Civil Air Navigation Services Organisation

CAUTRA Automated Computer System for Air Traffic / Coordinateur Automatique de Trafic Aérien (FR)

CBA Cost Benefit Analysis

CDM Collaborate (Cooperative) Decision Making / Prise de décision en Collaboration (FR)

CEN Committee for European Normalisation

CENELEC Committee for European Normalisation in the Electrotechnical Field

CFIT Controlled Flight Into Terrain

CFMU Central Flow Management Unit (Eurocontrol)

CHAIN Controlled Harmonised Aeronautical Information Network

CIMSEL Civil Military SSR Environment Liaison Cell

CMIC Civil/Military Interface Standing Committee

COMM-B Mode S downlink format DF20 or 21

COMPAS Computer Oriented Metering Planning and Advisory System (D)

COTR Co-ordination and Transfer

CPDLC Controller Pilot Data Link Communications

CS Communcation Specification

CTR Controller or Control Zone

DAP Donwlink Airborne Parameters

D-ATIS Downlink ATIS

DCL Departure Clearance

DEMAN Departure Management

DFS Deutsche Flugsicherung (German Air Traffic Services)



DLIC Data Link Initial Capability

DMAN Departure Management

DME Distance Measuring Equipment

DSC Downstream Clearance

EANPG European Air Navigation Planning Group

EATCHIP European ATC Harmonisation and Implementation Programme

EATM European Air Traffic Management (Eurocontrol)

EATMN European Air Traffic Management Network

EATMP Performance Enhancement Programme for European Air Traffic Management (Eurocontrol)

EBBU EBBU - Brussels (FIR)

ECAC European Civil Aviation Conference

ECC Exemption Co-ordination Cell

ECG EATMP Communications Gateway

ECIP European Convergence and Implementation Plan / Plan européen de convergence et de réalisation (FR)

EDFF EDFF - Frankfurt (FIR)

EDLL EDLL - Düsseldorf (FIR)

EDMM EDMM - Munich (FIR)

EDWW EDWW - Bremen (FIR)

eFDP European Flight Data Processing

EFPS Electronic Flight Progress Strip

EGNOS European Geostaionary Navigation Overlay System

EHAA EHAA - Amsterdam (FIR)

ENAV Ente Nazionale di Assistenza al Volo (IT)

ENPRM Eurocontrol Notice of Proposed Rule Making

ETFMS Enhanced Tactical Flow Management System / Système amélioré de gestion tactique des courants de trafic (FR)

ETSI European Telecommunications Standardisation Institute

EU European Union

EUIR European Upper Flight Information Region

EUR European

EUR - RAN European Regional Air Navigation Meeting

EUROCAE EURopean Organisation for Civil Aviation Electronics

FAA Federal Aviation Authority (US)

FAB Functional Airspace Blocks

FDE OLDI/FDE application.

FDM Flight Data Management



FDP Flight Data Processing

FDPS Flight Data Processing System / Système de traitement des données de vol (FR)

FIR Flight Information Region

FIR Flight Information Region

FMTP Flight Message Transfer Protocol

FOM Flight Object Model

FUA Flexible Use of Airspace

FUM Flight Update Message

GBAS Ground Based Augmentation System

GICB Ground Initiated Comm B Protocol (Mode S)

GLONASS Global Navigation Satellite System (Russian based system)

GNSS Global Navigation Satellite System

GOBAN GNSS Roadmap Study

IATA International Air Transport Association

ICAO International Civil Aviation Organisation

ICB Industry Consultative Board

IDTF Interoperability Development Task Force

IFF Identification Friend or Foe

IFPL Initial Flight Plan

IFPS Integrated Initial Flight Plan Processing System

IFPZ Initial Flight Plan Processing System Zone

IFR Instrument Flight Rules * / Règles de vol aux instruments (FR)

II Interrogator Identifier

ILS Instrument Landing System

INS/IRS Inertial Navigation System / Inertial Reference System

IPAX Internet Protocol for Aeronautical Exchange

IR Integrated Receiver

iTEC - FDP Interoperability Through European Collaboration - Flight Data Processing

ITU International Telecommunications Union

JAA Joint Aviation Authorities

LAAS Local Area Augmentation System

LFEE LFEE - Reims (FIR)

LFFF LFFF - Paris (FIR)

MICA Mode S IC Allocation Cell

MILHAG Military Harmonisation Group

MMR Multi-Mode Receiver



MOPS Minimum Operational Performance Standards

MSAS Multi-transport Satellite Augmentation System

MTCD Medium Term Conflict Detection

NATS National Air Traffic Services

NOTAM Notice to Airmen

NOx Nitrogen Oxides

NPA Non Precision Approach

OATA Overall ATM/CNS Target Architecture

OCD Operational Concept Document

OLDI On-Line Data Interchange

OSI Open Systems Interconnection

PANOPS Procedures for Air Navigation Services – Aircraft Operations

P-RNAV Precission Area Navigation

PSR Primary Surveillance Radar

QA Quality Assurance

QoS Quality of Service

RF Radio Frequencies

RNAV Area Navigation

RNP Required Navigation Performance

RPL Repetitive Flight Plan

RSP Required Surveillance Performance

RTSP Real-Time Signal Processor

RVSM Reduced Vertical Separation Minima

SAFG Surveillance Architecture Focus Group

SARPs Standards and Recommended Practices (ICAO)

SASS-C SASS-C Development - Maintenance Support and Services

SASS-S Surveillance Analysis Support System - Sensor

SBAS Satellite Based Augmentation System

SCRSP Surveillance and Conflict Resolution Systems Panel

SDPD Surveillance Data Processing and Distribution

SDPS Surveillance Data Processing System (ICAO)

SFA Surveillance Functional Architecture

SG Safety Group

SI Surveillance Identifier

SMGCS Surface Movement Ground Control Systems

SPACE Eurocontrol SPACE Programme

SSC Single Sky Committee

SSR Secondary Surveillance Radar



STFRDE Surveillance Task Force for Radar Data Exchange

STNA Service Technique de la Navigation Aérienne (Air Traffic Service providers - France)

SUR Surveillance (EATMP Domain)

SYSCO System Supported Coordination

TACT Tactical System

TCP/IP Transmission Control Protocol / Internet Protocol

TIS-B Traffic Information Service - Broadcast

TMA Terminal Manoevring Area

TOBT Target Off Block Time

TP Trajectory Prediction

TWR Tower Control Unit (Aerodrome Control Tower)

UAC Upper Area Control (Centre); Centre de contrôle de l’espace supérieur (FR)

VDL VHF Digital Link

VFR Visual Flight Rules

VNAV Vertical Navigation

VoIP Voice over Internet Protocol

VOR VHF Omni-directional Radio Range (Beacon)

WAAS Wide Area Augmentation System

WG Working Group

WV Wake Vortex



C References

[1] ICB/2/3 Paper, 16th November 2004

[2] ATM-CNS Interoperability Roadmap Final Report, Sofreavia, EC Contract B2001/B2-704B/S12.322054

[3] EUROCONTROL ATM Strategy for the Years 2000+ Volume 1, Released: 23/07/2003 Edition: ed 2003

[4] ECIP for the years 2005-2009 - Executive Summary

[5] ECIP for the years 2005-2009 - Main document

[6] ECIP for the years 2005-2009 - Detailed objective descriptions

[7] Interoperability General Principles Proposed by ICB sub-group, 10th January 2004, version 1.0

[8] ANNEX I, L 96/33, ‘1. Systems and procedures for airspace management’.

[9] Commission Regulation (EC) No 551/2004 of 10/03/04; Art.7; and Regulation (EC) No 551/2004 of 10/03/04; Annex II ‘Essential Requirements’ Part A (4)

[10] Commission Regulation (EC) No 551/2004 of 10/03/04; Art.3, Art.4, Art.6

[11] ECIP Objective ‘AOP05’ - Implement airport collaborative decision making (CDM), 2006, Harmonisation objective

[12] Eurocontrol website: http://www.eurocontrol.int

[13] EUROCONTROL Airport CDM Applications Guide

[14] Regulatory Unit Advanced EUROCONTROL (A-ENPRM) Air Traffic Flow Management, February 2004

[15] Standardisation Mandate M/354 of 9 August 2004

[16] ATS Data Exchange Presentation, ADEXP DPS.ET1.ST09-STD-01-01 2.1, 2001

[17] Commission Regulation (EC) No 2082/2000 of 6 September 2000

[18] Air Traffic Management (ICAO Doc 4444) (PANS-RAC). Formerly the Procedures for Air Navigation Services—Rules of the Air and Air Traffic Services

[19] ‘Draft implementing rule on co-ordination and transfer summary of responses’, document/enprm/04-006/draft edition 0.3, 20 January 2005

[20] FDE ICD Part 2, Flight Data Exchange Interface Control Document

[21] GOBAN: GNSS (CEC133) Roadmap, May 2003

[22] Eurocontrol ‘Guidelines For An Agreement For The Shared Use Of Radar Sensor Data’ (SUR.ET1.ST05.3000-GUI-01-00)

[23] CANSO Yearbook 2005

[24] ICAO Annex 15, Aeronautical Information Service



[25] ICAO Annex 4, Aeronautical Charts

[26] ICAO Annex 11, Air Traffic Services

[27] ICAO Annex 14, Aerodromes

[28] ED 98 User Requirements for Terrain and Obstacle Data

[29] ED 99 User Requirements for Aerodrome Mapping Information

[30] EUROCONTROL Survey Standard (Doc 007)

[31] EUROCONTROL AIS website (http://www.eurocontrol.int/ais)
