文档搜索 > SKELETON
Draft ETSI TR 102 395 V0.1.0 (2005-07)
TD <>
Draft ETSI TR 102 395 V0.1.0 (2005-07)
Technical Report
European Commission Mandate M/354
European Air Traffic Management Network (EATMN);
Phase 1: Inventory of European specification work in progress
Reference
<Workitem>
Keywords
<keywords>
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
Siret N?? 348 623 562 00017 - NAF 742 C
Association ?? but non lucratif enregistr??e ?? la
Sous-Pr??fecture de Grasse (06) N?? 7803/88
Important notice
Individual copies of the
present document can be downloaded from:
http://www.etsi.org
The present document may be made available in more than one electronic version or in print. In any case of existing or perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF). In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status. Information on the current status of this and other ETSI documents is available at http://portal.etsi.org/tb/status/status.asp
If you find errors in
the present document, please send your comment to one of the following
services:
http://portal.etsi.org/chaircor/ETSI_support.asp
Copyright Notification
No part may be reproduced
except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in
all media.
© European Telecommunications Standards Institute 2005.
All rights reserved.
DECTTM,
PLUGTESTSTM and UMTSTM
are Trade Marks of ETSI registered for the benefit of its Members.
TIPHONTM and the TIPHON logo are Trade Marks
currently being registered by ETSI for the benefit of its Members.
3GPPTM is a Trade Mark of ETSI registered for the benefit
of its Members and of the 3GPP Organizational Partners.
Contents
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web server (http://webapp.etsi.org/IPR/home.asp).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become, essential to the present document.
This Technical Report (TR) has been produced by STF 293. This group was strongly supported by the parent organisations of its members. These organisations were (in alphabetical order): AMS, DFS Deutsche Flugsicherung GmbH, EUROCONTROL, Helios Technology Ltd., iNFOSYS-ATM, SOFREAVIA.
This report consists of two parts, Part 1 being the inventory of the European specification work in progress [this issue] and Part 2 the Work Plan [planned to be delivered by October 2005].
At the end of 2003 the European Parliament approved the set of four regulations that comprise the Single European Sky package. In early February 2004 the Council of Ministers endorsed the programme.
The objectives of this regulatory initiative are to improve and reinforce safety, to create additional capacity, to increase the overall efficiency of the air traffic management (ATM) system, and create a European market for ATM systems. This can be achieved e.g. by restructuring the European airspace as a function of traffic flow, rather than according to national borders, by a more effective and integrated air traffic management architecture and by ensuring that this architecture is based on demand driven service provision. The legislation also proposes to significantly enhance international coordination. At the same time it aims to remove many of the administrative and organizational bottlenecks in particular in the area of making regulations and enforcing them.
The European Commission's ATM legislative package, which came into force in April 2004, consists of four regulations covering the essential elements for a seamless European Air Traffic Management System. These four elements are:
This regulation describes the institutional framework for the creation of the Single European Sky.
This regulation aims to promote the safe and efficient provision of air navigation services in a seamless and interoperable manner across the European Community. It ensures functional separation between national regulators and air navigation service providers. This separation is compatible with public and private means of ownership and service provision - whichever model is adopted within individual States. It also allows the revision of the current charging system to encourage the efficient use and the efficient provision of ATM infrastructure.
This regulation will configure a European airspace which will function as a single operating continuum. This will allow common procedures for the planning, structuring, and management of airspace ensuring the safe performance of the entire European Air Traffic Management Network (EATMN). The regulation defines the principles for the organisation and use of the airspace, and for the optimisation of air traffic flows.
A specific regulation defines the conditions to ensure interoperability in the European Union between the different systems of the European Air Traffic Management Network and of their upgrading to new technologies. A fundamental topic of this regulation is the definition and management of the European ATM standardisation processes.
To achieve the above desirable objectives, the organisation, legislation, and the defining principles for the operation of the Single European Sky had to be put in place. To this end, the European Community took specific actions:
The above mentioned regulations foresaw the creation of a Single European Sky Committee (SSC) and an Industry Consultation Body (ICB). Member States were encouraged to send a civil and a military representative to the Single European Sky Committee. The European Commission also launched an industrial and a social dialogue with all relevant actors in order to set the roadmap from research to implementation. The Single European Sky Committee itself consists of representatives of the Member States of the European Community. Countries having bilateral agreements with the European Community may be invited as observers or as full member as foreseen in the specific agreements.
The Single European Sky Committee has powers delegated from the European Parliament and the Council to adopt implementing legislation on its behalf. The legislation ensures that all member states?? needs will be taken into account.
A number of actions are intended to improve the organisation and management of European airspace. These include:
Perhaps the most significant action here is the creation of a European Upper Flight Information Region. This will replace the corresponding existing national zones. It will ensure uniform organisation of the airspace. Necessarily, this will encourage the reconfiguration of the upper airspace into functional airspace blocks, based on safety and efficiency criteria - regardless of national boundaries. It will also be helpful in harmonising the use of airspace classifications.
Military airspace occupies a significant portion of the overall European airspace which could lead to the inefficient use of airspace. Although sharing of airspace does now occur, an action is proposed for the efficient allocation and use of military airspace including the increased use of this airspace to civil flights.
A safeguard clause exists, allowing Member States to apply measures needed to safeguard essential security or defence policy interests.
This action is aimed at the adoption of rules and conditions for the efficient management of air traffic flow in co-operation with service providers, airports and airspace users. Mechanisms will be introduced, allowing for a more comprehensive and disciplined use of the airspace aimed at integrating airports into the Flow Management process.
Interoperability is an issue that has impeded the integration of European airspace in a seamless fashion. Specific actions are proposed to address these problems:
The regulations establish the essential requirements and foresee Implementation Rules (IR) and European Community Specifications (CS) to implement these requirements and secure their compliance, taking account of operational and technical developments. The drafting of European Community specifications implies the consensual agreement of stakeholders on those standards of voluntary application.
It is essential that the development of Implementing Rules and Community Specifications must follow transparent procedures. Community Specifications can be developed either by European Standardization Organisations in co-operation with EUROCAE or by EUROCONTROL. Resulting Community Specifications should be adopted by consensus within a formal public enquiry process. This will enable product manufacturers and service providers to make a declaration of conformity or verification of systems respectively to the essential requirements and the relevant Implementation Rules. This will, in turn, benefit and streamline procurement in ATM and ensure an open market in products and services.
The aim of inviting industry participation flows from many direct and practical needs. Industry has the knowledge and expertise that can help set the roadmap for the development of ATM toward the future European system. Industry expertise is essential to guide the direction taken and to identify those specific steps required to achieve the future European system. Industry can help to define the investment needs for research and technical development (RTD) and its implementation.
Industry can also be particularly helpful in supporting the standardisation process, where much work yet remains to be done. Through the creation of the ICB, industry will be able to advise the European Commission and the Single European Sky Committee. Membership in the ICB will be made up of representatives of the Air Traffic Service Providers, Airspace Users, Manufacturing Industry, Professional Associations, Airports, and RTD Organisations.
The participation and cooperation of EUROCONTROL is an essential element for the successful implementation of the Single European Sky Initiative. EUROCONTROL and the European Commission are working together to ensure an efficient and effective European ATM system. As part of this process, the European Community has become Member of the EUROCONTROL Organisation. The main areas where it is anticipated that more formal cooperation with EUROCONTROL will be most beneficial are:
It is intended that EUROCONTROL will be in charge of the preparation of proposals for European Community legislation through mandates from the European Commission, e.g.:
This is a significant role and includes new and necessary responsibilities for that organisation.
EUROCAE deals with the standardization of ground and airborne systems and equipment for the benefit of the Civil Aviation Community in Europe. EUROCAE acts as a Forum for its 100+ members to collaborate in specific technical tasks (standards, specifications, guidelines, reports??). The EUROCAE membership consists of Manufacturers, Regulators, Services Providers and Users. The membership comprises North American based as well as European based organizations.
EUROCAE works in close cooperation with its US equivalents (RTCA, SAE, ARINC??) and in close relation with the worldwide Aviation authorities (EASA, EUROCONTROL, FAA, ICAO, IATA??).
EUROCAE produces technical standards and other documents in response to operational and functional requirements.
EUROCAE has published over one hundred and thirty documents; several of them developed jointly with US partners. Many are referenced in TSOs and/or referred to in ICAO SARPS and/or EUROCONTROL ESARRs and/or FAA standards.
More recently EUROCAE has established agreements with the European Standardization Organisations (ESOs) to provide technical support where aviation related standards are required to support the SES legislation.
SESAME is a common initiative from the European Commission and EUROCONTROL to achieve the Single European Sky (SES) technical/operational implementation, in complement to the SES regulatory framework.
With SESAME, the EU has launched the European air traffic management modernisation programme. It combines operational, technological, economic, financial and regulatory aspects and will support the Single Sky legislation. It will synchronise the evolution in all European Union member states ensuring that aircraft equipage is consistent with ground evolutions and will include all the steps from research to operation. Most importantly, it will be based on a co-operation involving airspace users, Air Navigation Service Providers, industry airports, and military, and it will implement a commonly agreed operational concept.
The first phase of SESAME, called the ??definition phase?? has been launched: it is co-funded by the European Commission under Trans European Networks and EUROCONTROL, and put under EUROCONTROL??S responsibility. This definition phase will end in 2007. It will deliver an ATM Master Plan, which will include a common goal and vision for the development and implementation of the Single European Sky Air Traffic Management environment.
The second phase of SESAME will be a development and implementation phase based upon the results of the definition phase. This phase will build the next generation of Air Traffic Management system, synchronise their deployment and implementation. This phase will span from 2007 to 2020+.
The European Commission and EUROCONTROL participate to strategic orientation of SESAME. The Commission translates into community legislation the required synchronisation and harmonisation.
As an integral part of the SESAME Definition Phase, specific work packages will address the standardisation needs, will consider under which organisation these standards will have to be developed, and the timeframe for their delivery. The results will be included in the Master Plan (one of the main deliverable of the Definition Phase) providing to the concerned organisations the necessary information to establish their work programme.
For further information consult the website at: http://europa.eu.int/comm/transport/air/single_sky/sesame/index_en.htm
Europe has launched an ambitious but essential programme for the achievement of a Single European Sky. This programme involves significant institutional and legislative changes to overcome the barriers that presently stand in the way of a more unified and efficient Air Traffic System. The Single European Sky programme aims to improve the means and the methods of Air Traffic Management in order to achieve this common goal. Many changes are required to avoid a grid lock in Europe as traffic continues to increase. Existing processes and procedures are simply not sufficient to ensure that safety, capacity and efficiency is maintained in the face of this continuing growth.
On 30 June 2004, the European Commission issued mandate M/354 [1] to CEN/CENELEC/ETSI for the development of European Standards for interoperability of the European Air Traffic Management Network (EATMN).
The description of the mandated work is:
The purpose of this document is to present an inventory of all CNS/ATM system elements and their constituents which may need standardisation to enable the development and implementation of the SES programme. Suitable documentation which might facilitate the definition of such standards and related organisations possessing specific know-how and previously involved in such work were identified. The inventory of the standardisation candidates was provided with the recommended priorities specified by the SES ICB.
This document presents Community Specifications proposed as candidates for development either by the European standardisation organisations in cooperation with Eurocae, or by Eurocontrol, depending on the provisions of Article 4, paragraph 1 of the SES Interoperability Regulation [2].
The European Commission tasked STF 293 to produce a comprehensive inventory of the current status of achieved standardisation, on-going work, and open issues thus giving an overview on the rather wide domain of CNS/ATM. Part two of STF293??s task is the creation of a work plan outlining the duration, manpower and estimated efforts to produce the resulting Community Specifications. The final judgement of allocating priorities to the work plan and initiating the required activities rests with the European Commission.
It is suggested that this work plan be categorised dealing with the issues in the following sequence:
According to REGULATION (EC) No 552/2004; Annex I the EATMN is subdivided into eight systems [2].
1 Systems and procedures for airspace management.
2 Systems and procedures for air traffic flow management.
3 Systems and procedures for air traffic services, in particular flight data processing systems, surveillance data processing systems and human-machine interface systems.
4 Communications systems and procedures for ground-to-ground, air-to-ground and air-to-air communications.
5 Navigation systems and procedures.
6 Surveillance systems and procedures.
7 Systems and procedures for aeronautical information services.
8 Systems and procedures for the use of meteorological information.
For the purposes of this Technical Report (TR), the following references apply:
[1] European Commission, DG-TREN, Mandate to CEN/CENELEC/ETSI for the development of European standards for interoperability of the European Air Traffic Management Network.
[2] Official Journal of the European Union, Regulation (EC) No 552/2004 of the European Parliament and of the Council of 10 March 2004 on the interoperability of the European Air Traffic Management network (the interoperability Regulation). The SES Interoperability Regulation and can be found at: http://europa.eu.int/eur-lex/en/archive/2004/l_09620040331en.html
[3] European Council,
Council Resolution of 7 May 1985
on a new approach to technical harmonization and standards (85/C 136/01).
[4] ATM-CNS Interoperability Roadmap Final Report, Sofreavia, EC Contract B2001/B2-704B/S12.322054
[5] Working paper ICB/2/3
[6] ECIP for the years 2005-2009
[7] Price Waterhouse Coopers, multi-modal CBA of Galileo
[8] Eurocontrol ??Guidelines For An Agreement For The Shared Use Of Radar Sensor Data?? (SUR.ET1.ST05.3000-GUI-01-00)
[9] Official Journal of the European Union L 91, 07.04.1999, Directive 1999/5/EC of the European Parliament and of the Council of 9 March 1999 on radio equipment and telecommunications terminal equipment and the mutual recognition of their conformity
Definition 28 within the SES Framework Regulation defines interoperability as ??a set of functional, technical, and operational properties required of the systems and constituents [hardware or software] of the European Air Traffic Management Network and of the procedures for its operation, in order to enable its safe, seamless and efficient operation??.
The SES Interoperability Regulation provides the framework for the SES interoperability rules and regulations. The goal is to ensure the coordinated and rapid introduction of agreed validated concepts of operation or any associated technology. The scope of the regulation goes far wider than the traditional technical understanding of interoperability.
Rule setting: The Interoperability Regulation provides the framework for the SES interoperability rules and specifications. Very high level requirements, known as ??Essential Requirements??, for each of the 8 systems above have been identified in Annex II of the Regulation. These requirements are mandatory and must be taken into account by all ATM stakeholders. The more detailed technical and procedural rules, which build on the essential requirements, basically define WHAT should be done. These are referred to as ??Implementing Rules?? (IRs). IRs will be developed whenever necessary by EUROCONTROL under mandates from the EC. These rules need to be agreed by the majority of Member States of the EU before becoming mandatory in Community law.
Specification setting: This second level creates the technical specification for the system in question setting out in detail HOW it shall be achieved. These are called ??Community Specifications?? (CS). According to preamble 11 of the Interoperability Regulation, compliance with published CS, which remains voluntary, creates a presumption of conformity with the Essential Requirements and the relevant IRs for interoperability. This is one of the major features of the ??New Approach??: CS remain voluntary and provide flexibility for industry as other solutions may be available. CSs are produced by European standardisation bodies (CEN, CENELEC, ETSI) in conjunction with EUROCAE and by EUROCONTROL in accordance with Community standardisation procedures.
Conformity assessment: The third level relates to the demonstration of compliance to the Essential Requirements and /or Implementing Rules. This is a new mandatory requirement affecting manufacturers of products and air navigation service providers and will result, eventually, in a certification process which declares that the ground ATM system conforms to the interoperability requirements.
Seamless:
This term might seem to be self explanatory. But in the context of the
SES this attribute is generally used by all stakeholders to characterise
the quality of interoperability of the SES ATM system. Therefore,
a closer look is deemed justified.
As seen from the airspace users perspective a seamless system plans
and conducts flight trajectories from end to end without disruptions
due to political boundaries, technical discontinuities or diverging
and incompatible operational procedures.
Also from a service provider??s point of view the term has several aspects: A seamless ATM system is based on operational principles, regulations and procedures which are in line; system algorithms in direct support of the control processed perform identically, interfacing system elements comprehend and apply a common terminology (e.g. based on a common data dictionary) and are thus able to exchange information and services.
Annex II (Essential Requirements) of the REGULATION (EC) No 552/2004 defines seven generic headings for Essential Requirements, which are given below (extracts):
Seamless operation
Air traffic management systems and their constituents shall be designed, built, maintained and operated using the appropriate and validated procedures, in such a way as to ensure the seamless operation of the EATMN at all times and for all phases of flight. 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.
Support for new Concept of Operations
The EATMN, its systems and their constituents shall support, on a coordinated basis, new agreed and validated concepts of operation that improve the quality and effectiveness of air navigation services, in particular in terms of safety and capacity.
The potential of new concepts, such as collaborative decision-making, increasing automation and alternative methods of delegation of separation responsibility, shall be examined taking due account of technological developments and of their safe implementation, following validation.
Safety
In respect of appropriate ground-based systems, or parts thereof, these high levels of safety shall be enhanced by safety nets which shall be subject to agreed common performance characteristics.
A harmonised set of safety requirements for the design, implementation, maintenance and operation of systems and their constituents, both for normal and degraded modes of operation, shall be defined with a view to achieving the agreed safety levels, for all phases of flight and for the entire EATMN.
Systems shall be designed, built, maintained and operated, using the appropriate and validated procedures, in such a way that the tasks assigned to the control staff are compatible with human capabilities, in both the normal and degraded modes of operation, and are consistent with required safety levels.
Systems shall be designed, built, maintained and operated using the appropriate and validated procedures, in such a way as to be free from harmful interference in their normal operational environment.
Civil-Military Co-ordination
The EATMN, its systems and their constituents shall support the progressive implementation of civil/military coordination, to the extent necessary for effective airspace and air traffic flow management, and the safe and efficient use of airspace by all users, through the application of the concept of the flexible use of airspace.
To achieve these objectives, the EATMN, its systems and their constituents shall support the timely sharing of correct and consistent information covering all phases of flight, between civil and military parties.
Environmental Constraints
Systems and operations of the EATMN shall take into account the need to minimise environmental impact in accordance with Community legislation.
Principal governing 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.
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.
For the purposes of the present document, the following abbreviations apply:
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 AT Microphone 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 Airborne 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
ATM Air Traffic Management
ATN Aeronautical Telecommunication Network / R??seau de t??l??communications a??ronautiques (FR)
ATS Air Traffic Services
ATSO Air Traffic Services Operator / Organisation
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 Community Specification
CTR Controller or Control Zone
DAP Downlink 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)
ER Essential requirement
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
IR Implementing Rule
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
VOR VHF Omni-directional Radio Range (Beacon)
WAAS Wide Area Augmentation System
WG Working Group
WV Wake Vortex
The candidate Community Specifications, as resulting from the assessment of the STF 293 have been organised in 3 categories:
When proceeding to its work according to its term of reference, the STF 293 identified the following issues for which it did not identified solution and which need to be reported to the Steering Group:
Considering the world-wide nature of the aviation, Air Traffic Management related standards need to be global. High level standards, describing concepts and functions are developed by the ICAO and are translated into other standards for systems and equipment design by other organisations such as RTCA or EUROCAE. These organisations are co-ordinating their work to ensure the global interoperability.
During its work, the STF 293 highlighted the absence of a process ensuring the consistency between the proposed ESO CSs and the standards as developed by other organisations. The absence of such a process may lead in standards divergence resulting in global non interoperability which is at the opposite of the principle of the Mandate M354.
Therefore the ST 293 stresses the need to identify a mechanism to ensure consistency between future CS and relevant standards as developed by other aviation organisations.
When considering the date (20th October 2005) for declaring conformity of ATM systems, components and procedures with Essential Requirements and Implementing Rules, the STF 293 pointed out the unrealism of producing and approving the necessary European Norms in time.
.
The following sections follow the ATM subject headings as listed in Annex I of the Interoperability Regulation [2].
The modernisation of the European ATM System requires a clear vision of the future operational concept required to absorb the forecast growth in demand, to meet the user??s expectations in terms of improved flexibility, punctuality and reduced costs, and to fully exploit current and emerging technologies, while improving safety.. The Operational Concept Document (OCD, The Vision) Volume I was approved by the Permanent Comission of EUROCONTROL and it served as input to generate global reference through the ICAO ATMCP Concept approved by the 11th Air Navigation Council. The Concept of Operations for 2011 (ConOps 2011) Volume II represents the 1st step in the evolution t of the European ATM system towards the vision set out in the OCD building upon those components and processes of the ATM system that are expected to evolve up to 2011. It is the objective of this CS to determine an agreed overall Concept of Operations to be implemented in the medium term having a formal status under the SES interoperability Regulation.
This CS was neither included in M/354 [1] nor in the document ICB/2/3 [5].
This work is of primary importance for any ATM system definition following a Model Driven Approach (MDA) as defined by Industry standards. It provides the methodology which frameworks ATM operational concepts activities providing a vision to achieve, complemented with a detailed coherent and consistent overview of how the European ATM system works. In addition it provides the traceability context to identify and analyse the impact of any changes within the system.
Ignoring the primary importance of this issue will contribute to maintain a fragmented view of the ATM system trough the proliferation of contradicting concepts and creating the opportunities to fail on implementing interoperable ATM systems.
The OCD Volume I and ConOps Volume II are already completed. ConOps Volume III (ConOps 2020) is under development. All this set of documents will be updated within the framework of the SESAME Definition Phase under Work Package 2.2.
EUROCONTROL has an Operational Concept Document Drafting Group (OCD DG), consisting of internal and external stakeholders, as part of the Operational Concept and Architecture (OCA) activity carried out in the EUROCONTROL ATM Strategy and Concepts Business Division.
The Operational Concept documentation described above will support the Single European Sky ATM Modernisation programme (SESAME), the Definition Phase of which has just been launched by the Commission and EUROCONTROL. The SESAME consortium will provide the necessary working structure to support this development. EUROCONTROL will ensure the means to maintain these reference documentation and corresponding approval process under configuration management.
The operational concept is defined in the EUROCONTROL OCD (a high-level vision for the year 2020) and the ConOps (detailed concepts of operations for the years 2011 and 2020) documents. Both the OCD and the ConOps for the target year 2011 are available on the EUROCONTROL website: http://www.eurocontrol.int/oca/public/standard_page/op_concept.html.
Proposal of the SESAME consortium for the definition phase of SESAME.
SESAME WP 2.2
Number of man-days of effort required to develop the CS. Period of time required. Expertise required.
EUROCONTROL CONOPS 2011 contains an ATM Process Model that shows, inter alia, the interfaces between the ATM components throughout all the ATM planning phases. A full traceability is being established from the ATM Process Model to a set of Requirements (Operational, Functional, Performance and Safaety) leading to the development of Use Cases (description of responsibilities and interactions between ATM personnel and systems). These Use Cases are the basis for the development of the OATA Logical Architecture, which provides back a traceability to the Concept of Opertations by mapping Operational Improvements and Enablers, as defined in the framework Strategic Nertwork Performance activity of EUROCONTROL.
This CS is a transposition of existing EUROCONTROL and Eurocae documents to recognise these documents under the Interoperability regulation.
Software assurance level is based upon the contribution of software to potential failure conditions as determined by the system safety assessment process. Two EUROCONTROL Safety Regulatory Requirement (ESARR) documents are related to system safety assessment and software assurance level : ESARR 4 and ESARR 6.
ESARR4 specifically focuses on the risk assessment requirements applicable to ATM-related systems, stating that: «an ATM service provider shall ensure that hazard identification as well as risk assessment and mitigation are systematically conducted for any changes to those parts of the ATM system and supporting services within his managerial control».
Eurocontrol Safety Assessment Methodology (FHA, PSSA, SSA) is considered as an acceptable means of compliance and provides guidance on the methodology for the assessment of ATM system safety within EUROCONTROL. This methodology is referenced in ESARR4. The methodology covers the Functional Hazard Assessment (FHA), the Preliminary System Safety Assessment (PSSA) and the System Safety Assessment (SSA).
ESARR6 requirements apply to Software Safety Assurance System, as part of Safety Management System, and includes requirements for :
ESARR6 is a Goal-based regulation and states what needs to be done and not how to do it. The ??how?? is covered by potential means of compliance such as:
ED 109 seems to be the means of compliance which fits better with ESARR6.
This CS was neither included in M/354 [1] nor in the document ICB/2/3 [5].
Current or anticipated timescales for development and/or adoption..
EUROCONTROL
EUROCAE
ESARR4 - EUROCONTROL Safety Regulatory Requirement (ESARR), ESARR 4, Risk assessment and mitigation in ATM, Edition 1.0, 5 April 2001,
ESARR6 – EUROCONTROL Safety Regulatory Requirement (ESARR), ESARR 6, Software in ATM systems, Edition 1.0, 6 November 2003,
ED 109 / DO 278 Guidelines for communication, Navigation, Surveillance, and air traffic management (CNS/ATM) systems software integrity assurance, prepared by EUROCAE and RTCA, accepted March 2002.
Relevant documents already known about.
Number of man-days of effort required to develop the CS. Period of time required. Expertise required.
Information not covered by the sub-headings above.
Information sharing is based on the paradigm that applications do not need to care for the required data on which to perform calculations, because it is there in sufficient quality when needed. Information sharing, as opposed to data exchange, where a system has to have peer-to-peer communications paths with all systems it needs to exchange the data with, requires having only one (redundant) access to the infrastructure hosting the information.
All applications use standardised methods to subscribe to, create, store, update, retrieve, forward, delete, archive the data fields in the information model regardless of the domain or technology. The method cares for availability, security, consistency, credibility, synchronism, accessibility, notification about and recovery of the information entered to those who have subscribed.
Interoperability is a native result of information sharing. If all domains use standard methods to access and provide information to be shared between stakeholder systems, interoperability does not need extra effort providing that the operational concepts and procedures leading to the definition of the information model are harmonised.
Such mechanism, which is widely known as System Wide Information Management, can be standardised at the engineering level with little impact on the operational use. However the operational concepts and requirements will put demands on the method in terms of performance and non-functional requirements.
First priority for seamlessness is sharing of information. Secondly it is harmonisation of procedures and commonality of definitions between stakeholders providing information for sharing. The information sharing concept is not limited to Gate-to-Gate, it may be applied for airside as well as landside operation providing the missing link between the two worlds.
Information sharing across domains and at global level is essential to Aircraft operators, who are operating globally. All other stakeholders are only working at regional, national or even local level. It is the global operation of aircraft which demands standards most in order to share information about a flight with all stakeholders involved across the globe eventually.
Standardisation in this context, therefore, must be based on the concept to think global and act local.
Sharing of information enables and requires checking for consistency and resolution for inconsistencies. Consistent, current information at the right time makes operation safe, seamless and efficient. However, it only works if the sharing of information is accepted by the stakeholders in the aviation chain either by voluntary recognition of the benefit it provides to all, or by enforcement through law.
This CS was neither included in M/354 [1] nor in the document ICB/2/3 [5].
A standard for information sharing can be started immediately.
Number of man-days of effort required to develop the CS. Period of time required. Expertise required.
The method shall be transparent to existing legacy implementations. It shall not require changes to continue to interoperate between stakeholder systems already using the methods for information sharing and those still using traditional interoperability based on data exchange. To achieve this proxy services shall be provided by the information sharing environment to interface legacy systems with the new method.
Flexible use of airspace is an airspace management concept which determines that airspace should not be designated as either pure civil or military airspace, but rather considered as one continuum in which all user requirements have to be accommodated to the maximum extent possible. The Single European Sky committee is currently discussing the draft regulation for the Flexible use of Airspace. Pending their decision on the subject, the need for development of community specifications will then be identified and adequately scoped.
EC ICB Recommended Priority: Priority 1; this CS has been included in M/354 [1] as well as in the document ICB/2/3 [5].
Current or anticipated timescales for development and/or adoption.
EUROCONTROL project DMEAN.
Number of man-days of effort required to develop the CS. Period of time required. Expertise required.
Information not covered by the sub-headings above.
Draft regulations on Airspace Design have been submitted to the European Union and are pending discussion at the Single European Sky committee. Any considerations on the scope of community specifications on the subject depend on the final decision of the European Union on that regulation.
EC ICB Recommended Priority: Priority 1; this CS has been included in M/354 [1] as well as in the document ICB/2/3 [5].
Current or anticipated timescales for development and/or adoption.
EUROCONTROL project DMEAN.
Number of man-days of effort required to develop the CS. Period of time required. Expertise required.
Information not covered by the sub-headings above.
The aim of the IFPL implementing rule is to give a formal status to a set of key elements of a flight plan, in order to ensure the flight plan consistency between operators, IFPS and ATS units in the pre-flight phase.
The primary objective of the Initial Flight Plan implementing rule is to ensure that the key elements of the flight plan are kept consistent between operators, IFPS and ATS units in the pre-flight phase. This is be achieved by defining the set of key elements and the associated roles and responsibilities of the above mentioned parties with regard the submission, distribution and reception and all subsequent modifications of key flight plan elements.
As the implementing rule addresses only the procedures associated with its target, there is no particular assumption about the logical architecture or about the technical solution used to implement the information exchanges associated to flight plan submission, distribution and reception or modification of key elements of the flight plan processes between the above mentioned ATM actors, in the pre-flight phase.
The scope of the IFPL implementing rule is limited to the pre-flight phase, defined as the period from the first submission of a flight plan until the first delivery of ATC clearance within the airspace covered by the IFPL implementing rule. Once the first delivery of ATC clearance within the airspace covered by the IFPL implementing rule has taken place, responsibility for the contents and update of the flight plan moves from the parties involved in the initial flight planning process to those directly responsible for the safe conduct of the flight, i.e. the pilot and the Air Traffic Controller.
However, a provision addressing the missing flight plans of the flights entering the area of application of the rule has been included. In order to ensure that a minimum set of key elements on all flights is available to all affected parties as early as possible the rule formalizes the process of notification of data on such flights to IFPS. IFPS will in turn distribute resultant flight plans to all affected ATS units.
The proposed vision for the IFPL implementing rule is to accept the existence of differences and the specific needs of individual actors, whilst ensuring that a sufficiently common basis for flight details exists in order to enable each actor to perform their specific duty in an effective and efficient manner.
The detailed procedures supporting the Regulation will provide all the necessary information to enable the parties within the scope of the rule to submit, modify, accept and distribute the flight plans in the pre-flight phase according with the requirements and provisions of the Regulation. These detailed procedures will be part of an updated IFPS Users Manual developed by EUROCONTROL.
The document will provide all users of the Integrated Initial Flight Plan Processing System with an easy to access reference manual. The manual will be intended to contain all the necessary procedures and information in order for users to be able to construct, transmit or when necessary to correct, flight plan and associated update messages. Procedures for the distribution of such messages after processing by IFPS will be also described.
The document will contain a functional description of the IFPS systems and associated procedures and the following information will be provided:
The document will also describe the procedures to be followed in case of problem and anomaly reporting.
This CS was neither included in M/354 [1] nor in the document ICB/2/3 [5].
Time horizon before SESAME.
EUROCONTROL.
EUROCONTROL IFPS Users Manual.
Relevant documents already known about.
Number of man-days of effort required to develop the CS. Period of time required. Expertise required.
Information not covered by the sub-headings above.
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.The common situational awareness allows each partner to harmonize/optimize ground-handling-procedures at airports concerned.
EC ICB Recommended Priority: Priority 1; this CS has been included in the Standardisation Mandate M/354 [1].
A-CDM is covered by ECIP [6] Objective ??AOP05??.
The potential benefits of A-CDM are:
It is generally accepted that the standardisation of data is required and the advantage of this CS is that it will help prepare industry in the development of any required CDM-products (tools to provide situational awareness and to support decision making).
Most relevant information exists somewhere around the airport in various systems, but is not readily available to all partners:
Data quality: Provision of automated data of sufficient quality.
The potential disadvantages for a rapid A-CDM implementation are:
A CBA has not been produced specifically for this CS.
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).
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.
The following timeline was proposed in the ??ATM-CNS Interoperability Roadmap?? [4]
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:
Further, CDM forms a central part of the ATM 2000+ Strategy. The Strategy foresees:
Within the next five years the Strategy foresees the ??first applications of Collaborative Decision Making (CDM), principally for ATFM and at airports??.
EUROCONTROL has an ongoing A-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??; the Flight Update Message (FUM) and the Departure Planning Information (DPI) message.
DFS (German Air Navigation Services) has an ongoing project to implement CDM at Munich airport.
Number of man-days of effort required to develop the CS. Period of time required. Expertise required.
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)).
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??or as ??secure information??, therefore restricting information sharing3.
The work of the European Airport CDM Project, which is part of the European Airport Operation Programme, 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.
The purpose is to develop a CS of the technical details of the ATS Data Exchange Presentation (ADEXP), i.e. the transposition of EUROCONTROL documents to recognise these documents under the Interoperability regulation. The issue concerning the use (mandatory or not) of ADEXP will be addressed during or after the development of the CS.
The EUROCONTROL Convergence and Implementation Plan (ECIP) [6] contains an agreed objective for the 2006 – 2010 cycle, to implement collaborative flight planning.
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.).
In due course this becomes a key enabler to the broader objectives of Flexible Use of Airspace.
The objective of this CS is to adopt ADEXP as a formal European Standard.
EC ICB Recommended Priority: Priority 1.
This topic was included in the Standardisation Mandate M/354 [1] and ICB/2/3. The CS was initially proposed in the ATM-CNS Interoperability Roadmap Study [4].
The ATS Data Exchange Presentation (ADEXP) is a format for message exchange in the following areas:
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.
ADEXP exists as a EUROCONTROL Standard and was adopted by COMMISSION REGULATION (EC) No 2082/2000 which will be withdrawn by 20th October 2005.
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. ADEXP has a high level of support.
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.
The expected benefits listed in the ECIP [6] are as follows:
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.
The main timescale involved in the collaborative flight planning action should be complete in 2006.
Organisations working on this topic.
Relevant working groups, projects and trials working in this field
Number of man-days of effort required to develop the CS. Period of time required. Expertise required.
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.
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.
This CS is primarily a transposition of existing EUROCONTROL documents to recognise these documents under the Interoperability regulation.
This CS was neither included in M/354 [1] nor in the document ICB/2/3 [5].
CS may be necessary depending on the outcome of EUROCONTROL??s Conformity Assessment Task Force to provide for a basic document on which ANSPs could draw the verification of systems for use of CFMU and IFPS.
Organisations working on this topic.
Relevant documents already known about.
Relevant documents already known about.
Number of man-days of effort required to develop the CS. Period of time required. Expertise required.
Information not covered by the sub-headings above.
IR on Data Link Services
The purpose of the IR on Data Link Services 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 in continental airspace.
The IR will address:
- the list of data link services supported (e.g. DLIC, ACM, ACL, ACM ??),
- the supporting communication infrastructure(s)
- the ATC procedures and CPDLC messages for the provision and use of data link services,
- certification requirements,
- conformity assessment requirements,
- applicability scope and exemption policy.
To support this IR, both operational and technical standards (CSs) are needed. In absence of a clear view on the functional and technical scope of this IR, it is proposed to consider the 3 candidates for CSs that meet at best the activities that are currently undertaken in Europe in the domain of the data link. A first CS could be defined to specify the requirements for data link service in the European continental airspace using the ATN over VDLM2 technology. A second CS could specify the interoperability requirements for the same services but using the FANS1/A over VDLM2. Finally, a CS might be required on the legacy data link services already operational in some airports in Europe.
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. This CS is primarily a transposition of existing EUROCONTROL documents to recognise these documents under the Interoperability regulation.
A mandate has been given to EUROCONTROL by the European Commission for the development of a draft Implementing Rule for Coordination and Transfer (COTR) 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 Transport 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.
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.
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.
EC ICB Recommended Priority: Priority 1.
This CS is not included in the Mandate M/354 [1]. The need for this CS has been identified during the development of the Implementing Rules for COTR and FMTP.
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.
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.
There is no particular mention of the OLDI standard in the current version of the European Convergence and Implementation Plan (2005 – 2009), 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.
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.
The main argument in favour of the course of action is that it recognises and regularises the current de facto situation.
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.
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.
The draft justification document also identifies a variety of capacity benefits, but does not at this stage quantify these in any way.
The current version of the European Convergence and Implementation Plan 2005-2009 aims at implementing ground-ground data exchange and automated co-ordination procedures in the ECAC States. It addresses the further implementation of several OLDI messages.
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 (e.g. 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.
The OLDI Standard in its version 3 should be converted into a CS with high priority, since it will be needed as an officially approved Means of compliance for the IR on Co-ordination and Transfer.
Organisations working on this topic.
Relevant documents already known about.
Number of man-days of effort required to develop the CS. Period of time required. Expertise required.
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.
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.
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.
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??. This CS is a transposition of EUROCONTROL and Eurocae documents (currently under development) to recognise these documents under the Interoperability regulation.
Development of a system architecture which is reviewed and agreed by industry enables the identification of services and interfaces required by future operational concepts.
These services and/or interfaces might also be subject to further standardisation activities.
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.
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).
EC ICB Recommended Priority: Priority 1; the item has been included in the Standardisation Mandate M/354 [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 be completed in summer 2006.
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:
The AHLM Project is funded by EUROCONTROL and administered by the OATA Project Office. It is also due to complete during 2005.
The advantages of the proposed CS are:
The disadvantages of this CS are:
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.
The benefits of the architecture are:
The baseline case would include not developing an Open ATC Architecture. This would lead to increased procurement costs.
The OATA Project and AHLM are likely to produce results during the summer 2006.
The architecture work will be taken up by the SESAME project in 2006. Results from SESAME should be taken into account for the proposed CS.
Therefore the CS should be resolved in parallel to the progress and in liaison with the SESAME project.
OATA Documentation, specific document for AHLM planned for June 2005.
Number of man-days of effort required to develop the CS. Period of time required. Expertise required.
The OATA Project, supported by the AHLM project, is the only significant current high level architecture for ATM for Europe.
The OATA product is a target logical structure for ATC systems. Substantial work is required to define:
The development of a high level architecture of ATM is a significant undertaking requiring a full QA, Review and Consultative processes.
If successful, the high level architecture would enable the identification of:
The development of the required architecture is likely to form part of the SESAME work program.
The existence of an agreed high level architecture is an essential enabler for the systematic identification of CSs and possibly IRs.
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.
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.
The main task of a standard ATS middleware is to provide a unified and standardized interface for the ATS applications.
The key issue is to establish:
EC ICB Recommended Priority: Priority 2 (to be kept under review); a CS requirement for ATC Middleware has not been included in the Mandate M/354 [1].
The issue was raised at the Single Sky Committee meeting on 26th May 2004. There 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. As a consequence the Commission included this topic in the document ICB/2/3.
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.
It is assumed that benefits arising in this area will be largely concerned with cost effectiveness. Categorising of benefits is likely to include:
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.
No CBA has been completed for this CS.
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). This work should start before SESAME.
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 and the findings of the SESAME project.
Work ongoing for the iTEC and Coflight projects should be considered as basis for this CS.
Number of man-days of effort required to develop the CS. Period of time required. Expertise required.
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.
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:
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.
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.
This item concerns the development of a Flight Object Model (FOM) which is based on the definition of a standard flight data model. This CS is primarily a transposition of EUROCONTROL and Eurocae documents to recognise these documents under the Interoperability regulation.
As noted in the ATM-CNS Interoperability Roadmap Study [4] 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 [4] proposes that IR/CS development might:
Furthermore, the IR/CS development program could be split into:
EC ICB Recommended Priority: Priority 1.
This CS has been included in the Standardisation Mandate M/354 [1]. It has also been identified in point 7 of the ??Draft Justification Material – Draft Implementing Rule for Co-ordination and Transfer??.
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.
The benefits of developing a CS in this area include capacity and cost effectiveness.
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.
No formal CBA has been conducted, but studies have shown benefit in interoperable FDPs.
The timescale expected for the development of standard specifications through the mechanism EUROCAE WG 59 is expected to be 2006.
Organisations working on this topic.
Relevant documents already known about.
Number of man-days of effort required to develop the CS. Period of time required. Expertise required.
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, and Aircraft Operator.
The elements of Flight Management have been grouped in a number of modules:
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:
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.
In addition to ongoing work on this CS, other work which could be conducted includes:
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.
The purpose of this item is to develop a community specification covering Advanced Surface Movement Guidance and Control Systems (A-SMGCS). This CS is primarily a transposition of EUROCONTROL and Eurocae documents to recognise these documents under the Interoperability regulation.
CSs for AMAN and DMAN and multilateration are described in other sections of the present document.
Advanced Surface Movement Guidance and Control System, A-SMGCS, will in its initial stages, i.e. the so-called Level 1 and Level 2 implementations with enhanced surveillance and control functionalities, provide a display to controllers with 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.
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.
In addition the system will enhance safety, alerting the controller by detecting potential conflicts between arriving and departing aircraft and other targets on the runways.
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.
EC ICB Recommended Priority: Priority 2.
In the ICB/2/3, this CS was combined with the definition of a standard for arrival management (AMAN) and departure management (DMAN).
This CS is part of Mandate M/354 [1].
Currently basic 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.
The components needed to implement an A-SMGCS Level 1 or Level 2 are already commercially available based on SMR and multilateration technique (and/or ADS-B) and are becoming operational at different levels of maturity on larger airports across Europe.
The advantages of the proposed CS are:
The disadvantages of this CS are:
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 should new investment be required to retrofit current aircraft with the proper avionics to comply with A-SMGCS standards (which will normally not be case for commercial aircraft in A-SMGCS Level 1 or 2 environments).
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. Therefore the development of a CS should take into account the maturity of the different A-SMGCS- Levels:
Existing standards:
EU-funded programme EMMA (operational validation)
Number of man-days of effort required to develop the CS. Period of time required. Expertise required.
A-SMGCS is a key enabler both for the prevention of runway incursions and increased airport capacity, including the maintainability of high capacity in periods of reduced visibility. Significant research has been undertaken by the EC, EUROCONTROL and Industry, leading to a number of ICAO and EUROCAE specifications (listed above).
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.
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 on individual local solutions.
Systems aimed at alerting air traffic controllers about potential 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-SMGCS is generally agreed as the key enabler for maintainable high airport capacity with no infringement of the target level of safety, and implementation is already ongoing at several of the largest airports in Europe.
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.
The prime users of A-SMGCS are both the ANSP providing the local aerodrome control services and the local aerodrome operator generally providing not only apron control but also being responsible for e. g. the runway and taxiway lighting systems (which also form part of an A-SMGCS). Therefore A-SMGCS are usually commonly used by both parties, leading also to a sharing of benefits and costs. It is therefore recommended that close liaison with airport operators is being established and maintained throughout the development of this CS.
Basic material for at least Level 1 and Level 2 A-SMGCS are already available through ICAO, EUROCAE, EUROCONTROL and EC RTD Framework Programmes, which should be sufficiently mature for the development of a CS.
The purpose of the IR on communication is to address Flight Message Transfer protocol and Air-Ground Voice Channel Spacing.
With respect to Flight Message Transfer protocol, one of the main tasks of a Flight Data Processing System (FDPS) is message handling to support the provision of flight data. Indeed, Air Traffic Control Units exchange flight data in order to hand-over the control of an aircraft between two flight information regions.
It is essential to ensure the interoperability between these FDPSs and for this purpose EUROCONTROL had released former EUROCONTROL Standard FDE ICD Part 1 making use of X.25.
In view of the market decline of X.25 technology and services, EUROCONTROL revised the FDE ICD Part 1 to introduce TCP/IP. The revised specification has been developed with several Air Navigation Service Providers and validated through a series of field trials and is named Flight Message Transfer Protocol (FMTP).
The FMTP IR describes a state machine operating over an underlying IP infrastructure for the purposes of applications such as the Co-Ordination and Transfer IR. While being an evolution of the former FDE ICD Part 1 to secure the stakeholders?? past investments in FDE ICD Part 1, it is strictly mandates interoperability provisions between FDPSs.
The FMTP IR is therefore required to:
For Air-Ground Voice Channel Spacing, it is to specify the regulatory provisions for the deployment of air-ground voice communications based on reduced 8.33 kHz channel spacing within the SES area. The deployment will focus on the vertical expansion of 8.33 kHz channel spacing below FL 245 in order to alleviate the VHF congestion in Europe.
The IR will address:
To support this IR, both operational and technical standards (CSs) are expected to be needed. As required by the EC mandate, the CS associated to the IR will be identified during the drafting of the rule.
This CS is primarily a transposition of existing ETSI and EUROCONTROL documents to recognise these documents under the interoperability Regulation.
This CS was neither included in M/354 [1] nor in the document ICB/2/3 [5].
Current or anticipated timescales for development and/or adoption.
Organisations working on this topic.
Relevant documents already known about.
Number of man-days of effort required to develop the CS. Period of time required. Expertise required.
At TCAM#19 it was confirmed that European Commission expects ATM equipment to be compliant with RTTE directive [9] from 20 October 2005 onwards.
This work comprises two parts:
(a) A new EN to cover airborne equipment. (Pending further investigation of legal issues.)
(b) ETSI needs to check that the essential requirements contained in the Interoperability Regulation [2] are fully taken into account in the existing standard for ground equipment EN 300 676.
This CS was neither included in M/354 [1] nor in the document ICB/2/3 [5].
The work on this CS should start as soon as possible, since [2] requires conformity declarations from the 20th October 2005 onward which gives a need for harmonized EN covering all relevant essential requirements.
ETSI ERM TG25.
Relevant documents already known about.
Number of man-days of effort required to develop the CS. Period of time required. Expertise required.
Before work on an airborne standard is started, any legal issues should be resolved.
At TCAM#19 it was confirmed that European Commission expects ATM equipment to be compliant with RTTE directive [9] from 20 October 2005 onwards.
The IR related to Navigation concerns the definition of the horizontal and vertical separation/performance in different airspaces, particularly for Precision RNAV (P-RNAV). It is assumed that the purpose of the proposed IR will be to mandate an RNP capability for application in the European airspace. Whilst P-RNAV is being implemented within the RNAV Integrated Initiative, this is expected to be only an interim step towards meeting the Navigation Strategy whereby RNAV becomes the only means of navigation in ECAC using DME and GNSS as the positioning sources.
There is an ECAC wide mandate for Basic-RNAV (B-RNAV) in European Upper Airspace. B-RNAV requires an adherence to RNP-5 supported by limited additional navigation functionality. B-RNAV is not suited to use in terminal airspace.
P-RNAV is an enhancement to B-RNAV which requires 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.
RNP-RNAV is a further level of area navigation. The required accuracy is set dependant on the current airspace or procedure. Typically RNP-0.1 is required for 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 no operational procedures exist in Europe. RNP-RNAV provides for integrity of operation sufficient for it to become the sole means of navigation on the flight deck enabling ground based VOR and NDB to be decommissioned. The need for Dual RNAV on Air Transport aircraft to provide sufficient continuity of service will determine the effective implementation date since many aircraft are today only equipped with single systems
Required Navigation Performance is only one parameter in the determination of separation standards. RNP levels should not be set in isolation but take into account other requirements including relevant communication and surveillance requirements.
B-RNAV (RNAV equipment meeting the RNP5 accuracy requirement) became mandatory for en-route in 1998.
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 2005 in Sweden, Italy, Austria, Switzerland, Belgium, the Netherlands, Greece, France and Spain.
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. A typical example is the statement that most of aircraft are already capable of P-RNAV but cannot use it.
IR on the Required Navigation Performance
This IR concerns the definition of the horizontal and vertical separation/performance in different airspaces, particularly for Precision RNAV (P-RNAV). It is assumed that the purpose of the proposed IR will be to mandate an RNP capability for application in the European airspace. Whilst P-RNAV is being implemented within the RNAV Integrated Initiative, this is expected to be only an interim step towards meeting the Navigation Strategy whereby RNAV becomes the only means of navigation in ECAC using DME and GNSS as the positioning sources.
There is an ECAC wide mandate for Basic-RNAV (B-RNAV) in European Upper Airspace. B-RNAV requires an adherence to RNP-5 supported by limited additional navigation functionality. B-RNAV is not suited to use in terminal airspace.
P-RNAV is an enhancement to B-RNAV which requires 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.
RNP-RNAV is a further level of area navigation. The required accuracy is set dependant on the current airspace or procedure. Typically RNP-0.1 is required for 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 no operational procedures exist in Europe. RNP-RNAV provides for integrity of operation sufficient for it to become the sole means of navigation on the flight deck enabling ground based VOR and NDB to be decommissioned. The need for Dual RNAV on Air Transport aircraft to provide sufficient continuity of service will determine the effective implementation date since many aircraft are today only equipped with single systems
Required Navigation Performance is only one parameter in the determination of separation standards. RNP levels should not be set in isolation but take into account other requirements including relevant communication and surveillance requirements.
B-RNAV (RNAV equipment meeting the RNP5 accuracy requirement) became mandatory for en-route in 1998.
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 2005 in Sweden, Italy, Austria, Switzerland, Belgium, the Netherlands, Greece, France and Spain.
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. A typical example is the statement that most of aircraft are already capable of P-RNAV but cannot use it.
In addition to the work on the IR, action could be undertaken to:
This CS derives appropriate technical requirements from the essential requirements contained in the Interoperability Regulation [2] and the RTTE directive [9] including appropriate procedures for testing of non-directional beacons (NDB) to replace existing national practices (which may have been notified to the European Commission) by a harmonized one.
This CS was neither included in M/354 [1] nor in the document ICB/2/3 [5].
The work on this CS should start as soon as possible, since [2] requires conformity declarations from the 20th October 2005 onward which gives a need for harmonized EN covering all relevant essential requirements. On the other hand NDB is considered as legacy system (lower priority).
Organisations working on this topic.
Relevant documents already known about.
Number of man-days of effort required to develop the CS. Period of time required. Expertise required.
At TCAM#19 it was confirmed that European Commission expects ATM equipment to be compliant with RTTE directive [9] from 20 October 2005 onwards.
An additional CS on Automatic Direction Finder may be necessary if legal investigation shows applicability of interoperability regulation to airborne constituents of the EATMN.
This CS derives appropriate technical requirements from the essential requirements contained in the Interoperability Regulation [2] and the RTTE directive [9] including appropriate procedures for testing of omni-directional radio range equipment (VOR, D-VOR) to replace existing national practices (which may have been notified to the European Commission) by a harmonized one.
This CS was neither included in M/354 [1] nor in the document ICB/2/3 [5].
The work on this CS should start as soon as possible, since [2] requires conformity declarations from the 20th October 2005 onward which gives a need for harmonized EN covering all relevant essential requirements. On the other hand VOR/D-VOR could be considered as legacy systems (lower priority).
Organisations working on this topic.
Relevant documents already known about.
Number of man-days of effort required to develop the CS. Period of time required. Expertise required.
At TCAM#19 it was confirmed that European Commission expects ATM equipment to be compliant with RTTE directive [9] from 20 October 2005 onwards.
An additional CS on corresponding airborne equipment may be necessary if legal investigation shows applicability of interoperability regulation to airborne constituents of the EATMN.
This CS derives appropriate technical requirements from the essential requirements contained in the Interoperability Regulation [2] and the RTTE directive [9] including appropriate procedures for testing of distance measuring equipment (DME) to replace existing national practices (which may have been notified to the European Commission) by a harmonized one.
This CS was neither included in M/354 [1] nor in the document ICB/2/3 [5].
The work on this CS should start as soon as possible, since [2] requires conformity declarations from the 20th October 2005 onward which gives a need for harmonized EN covering all relevant essential requirements. On the other hand DME could be considered as legacy systems (lower priority).
Organisations working on this topic.
Relevant documents already known about.
Number of man-days of effort required to develop the CS. Period of time required. Expertise required.
At TCAM#19 it was confirmed that European Commission expects ATM equipment to be compliant with RTTE directive [9] from 20 October 2005 onwards.
An additional CS on corresponding airborne equipment may be necessary if legal investigation shows applicability of interoperability regulation to airborne constituents of the EATMN.
This CS derives appropriate technical requirements from the essential requirements contained in the Interoperability Regulation [2] and the RTTE directive [9] including appropriate procedures for testing of localizer radio equipment to replace existing national practices (which may have been notified to the European Commission) by a harmonized one.
This CS was neither included in M/354 [1] nor in the document ICB/2/3 [5].
The work on this CS should start as soon as possible, since [2] requires conformity declarations from the 20th October 2005 onward which gives a need for harmonized EN covering all relevant essential requirements. On the other hand ILS could be considered as legacy systems (lower priority).
Organisations working on this topic.
Relevant documents already known about.
Number of man-days of effort required to develop the CS. Period of time required. Expertise required.
At TCAM#19 it was confirmed that European Commission expects ATM equipment to be compliant with RTTE directive [9] from 20 October 2005 onwards.
An additional CS on corresponding airborne equipment may be necessary if legal investigation shows applicability of interoperability regulation to airborne constituents of the EATMN.
This CS derives appropriate technical requirements from the essential requirements contained in the Interoperability Regulation [2] and the RTTE directive [9] including appropriate procedures for testing of glide path transmitter systems to replace existing national practices (which may have been notified to the European Commission) by a harmonized one.
This CS was neither included in M/354 [1] nor in the document ICB/2/3 [5].
The work on this CS should start as soon as possible, since [2] requires conformity declarations from the 20th October 2005 onward which gives a need for harmonized EN covering all relevant essential requirements. On the other hand VHF Marker Beacon could be considered as legacy systems (lower priority).
Organisations working on this topic.
Relevant documents already known about.
Number of man-days of effort required to develop the CS. Period of time required. Expertise required.
At TCAM#19 it was confirmed that European Commission expects ATM equipment to be compliant with RTTE directive [9] from 20 October 2005 onwards.
An additional CS on corresponding airborne equipment may be necessary if legal investigation shows applicability of interoperability regulation to airborne constituents of the EATMN.
This CS derives appropriate technical requirements from the essential requirements contained in the Interoperability Regulation [2] and the RTTE directive [9] including appropriate procedures for testing of localizer radio equipment to replace existing national practices (which may have been notified to the European Commission) by a harmonized one.
This CS was neither included in M/354 [1] nor in the document ICB/2/3 [5].
The work on this CS should start as soon as possible, since [2] requires conformity declarations from the 20th October 2005 onward which gives a need for harmonized EN covering all relevant essential requirements..
Organisations working on this topic.
Relevant documents already known about.
Number of man-days of effort required to develop the CS. Period of time required. Expertise required.
At TCAM#19 it was confirmed that European Commission expects ATM equipment to be compliant with RTTE directive [9] from 20 October 2005 onwards.
An additional CS on corresponding airborne equipment may be necessary if legal investigation shows applicability of interoperability regulation to airborne constituents of the EATMN.
This item calls for the development of a CS to define the technical requirements for Category I precision approaches relying on GBAS.
Ground Based Augmentation System (GBAS) is a candidate for replacement for the current Instrument Landing System (ILS) where ILS limitations exist. 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 segment. GBAS requires the correct operation of the GNSS constellation.
The objective of this item is to ensure that the necessary standards exist for the timely deployment of GBAS systems supporting Cat I operations.
EC ICB Recommended Priority: Priority 3 (no differentiation for CAT I – III).
It was included in the Standardisation Mandate M/354 [1].
Pros:
Cons:
EUROCONTROL is 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.
In 2003, EUROCONTROL produced an xLS cost study (SEFALA) comparing the 3 following scenarios over the 2004-2023 period:
Scenario 1 is a scenario in which ILS ground infrastructure remains the main approach and landing system deployed in ECAC; some MLS or GLS systems are deployed locally on a case by case basis in addition to the ILS systems
Scenario 2 is a scenario in which MLS is retained as the ultimate system, i.e. MLS ground equipment will be widely deployed to replace current ILS equipment or to fulfil new precision approach needs.
Scenario 3 is a scenario in which GLS is retained as the ultimate system, i.e. GLS ground equipment will be widely deployed and will finally replace ILS. Scenario 3 assumed the transition period will start from the beginning of 2012 and last only 8 years. Before the transition period, it is assumed a few MLS systems will be deployed in Europe on a case by case basis in addition to the ILS systems.
The results from this study showed that the "ILS scenario" was less costly by far than the other scenarios.
EURONCONTROL then made an evaluation of the benefits of each scenario, to put them in perspective of the costs. Results shows that the additional benefits brought either in the MLS scenario or in the GLS scenario (in straight-in operations) do not compensate for the additional costs they generate; in other words, MLS and GLS scenarios appeared as less cost-effective than the ILS scenario.
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 is in place since 25 November 2004.
Reference Material
Related Material
Number of man-days of effort required to develop the CS. Period of time required. Expertise required.
GBAS developments in Europe have followed those in the US (the FAA LAAS programme).
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.
No comprehensive plan seems to be in place in Europe for the deployment of GBAS Cat I ground stations. 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 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 Safe prototype standard by AENA.
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 un-compromised Cat II/III capabilities. Regarding Cat I operations, the FAA is promoting WAAS with further enhancements to support such capability.
In addition to the work on the CS, action could be undertaken to:
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.
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 to transform the existing GBAS standards into instruments foreseen in [2].
It has to be secured as well that European standards will be developed for GBAS CAT II / III.
It is the purpose of this CS to describe the PROCEDURES for the use of GPS (not GPS itself).
This CS was neither included in M/354 [1] nor in the document ICB/2/3 [5].
Current or anticipated timescales for development and/or adoption.
Organisations working on this topic.
EUROCAE ED-72A (MOPS for GPS).
Relevant documents already known about.
Number of man-days of effort required to develop the CS. Period of time required. Expertise required.
It has to be ensured that GPS in combination with onboard augmentation techniques like Receiver Autonomous Integrity Monitoring (RAIM) or equivalent can continue to be used as accepted stand alone navigational source for en-route operations (B-RNAV, P-RNAV) and for non precision approach operations.
Additionally, it has to be ensured that GPS+RAIM (or equivalent) in combination with barometric guidance (??BARO VNAV??) can be used for APV operations.
Currently in this area, there is a proposed IR on surveillance, the purpose of which would be to define a single European process for allocating Mode S Interrogator Codes. This will address the need for the co-ordination of Mode S Interrogator Codes on a European basis in support of the deployment of Mode S radars.
The IR will address:
Once the regulatory approach for developing the IR has been defined and agreed, it will be possible to determine the relationship between mandatory provisions and any supporting CS and other material that is felt necessary.
This CS derives appropriate technical requirements from the essential requirements contained in the Interoperability Regulation [2] and the RTTE directive [9] including appropriate procedures for testing of ground-based primary radar equipment to replace existing national practices (which may have been notified to the European Commission) by a harmonized one.
This CS was neither included in M/354 [1] nor in the document ICB/2/3 [5].
The work on this CS should start as soon as possible, since [2] requires conformity declarations from the 20th October 2005 onward which gives a need for harmonized EN covering all relevant essential requirements. On the other hand primary radar could be considered as legacy systems (lower priority).
Organisations working on this topic.
National practices, e.g. DEU: Reg TP SSB FL 001 (notified to the European Commission); see as well: http://europa.eu.int/comm/enterprise/tris/pisa/app/search/index.cfm?fuseaction=pisa_search_results&iStart=1&iYear=2004&sCountry=D&sProdType=V00T&LANG=EN&STYPE=STRUCTURED&iBack=2&iBack=3
Relevant documents already known about.
Number of man-days of effort required to develop the CS. Period of time required. Expertise required.
At TCAM#19 it was confirmed that European Commission expects ATM equipment to be compliant with RTTE directive [9] from 20 October 2005 onwards.
This CS derives appropriate technical requirements from the essential requirements contained in the Interoperability Regulation [2] and the RTTE directive [9] including appropriate procedures for testing of ground-based secondary radar systems to replace existing national practices (which may have been notified to the European Commission) by a harmonized one.
This CS was neither included in M/354 [1] nor in the document ICB/2/3 [5].
The work on this CS should start as soon as possible, since [2] requires conformity declarations from the 20th October 2005 onward which gives a need for harmonized EN covering all relevant essential requirements. On the other hand secondary radar could be considered as legacy systems (lower priority).
Eurocontrol Working Group (Appraisal Programme).
Relevant documents already known about.
Number of man-days of effort required to develop the CS. Period of time required. Expertise required.
At TCAM#19 it was confirmed that European Commission expects ATM equipment to be compliant with RTTE directive [9] from 20 October 2005 onwards.
An additional CS on corresponding airborne equipment may be necessary if legal investigation shows applicability of interoperability regulation to airborne constituents of the EATMN.
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 objective of this CS is to develop a standardised data format for the exchange of surveillance information between:
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.
The EUROCONTROL Agency has established a number of groups to aid the definition of ASTERIX and related standards. These are:
The EUROCONTROL ??Guidelines For An Agreement For The Shared Use Of Radar Sensor Data?? [8] 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.
EC ICB Recommended Priority: Priority 2.
The CS was included in the Standardisation Mandate M/354 [1].
Harmonisation of interface and procedures brings a number of benefits including:
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.
ASTERIX is a mature standard, it is anticipated that a CS could be developed within one calendar year. Considering that ASTERIX is a EUROCONTROL Standard binding EUROCONTROL member states and in order to avoid contradictory provisions, work on this CS should start before SESAME.
EUROCONTROL.
EUROCONTROL Standard Asterix Vsn 1.29 and related documents for ASTERIX categories.
Relevant documents already known about.
Number of man-days of effort required to develop the CS. Period of time required. Expertise required.
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.
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.
The Surveillance Functional Architecture and the ASTERIX standard are highly dependent upon each other.
The exchange of surveillance information between ACCs is further complicated by the need to provide ??seamless?? data to ensure a smooth handover of aircraft between functional airspace blocks.
The inclusion of guidelines relating to how the exchange could be established and operated would support the implementation of this CS.
ASTERIX is a mature EUROCONTROL standard for Surveillance data formats which is being widely used within Europe.
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.
The purpose of the IR on Aeronautical Information Services will be to ensure aeronautical information of sufficient quality, accuracy, timeliness and granularity as a key enabler of the present and future Air Traffic Management (ATM) systems. This implementing rule will bring forward provisions which ensure compliance to existing ICAO Annex 15 data integrity requirements and complement them by describing performance requirements for data origination, transfer and processing. Close cooperation will be achieved with the JAA/EASA and take account of the provisions of EUROCAE Document ED76 (Industry Standards for the Processing of Aeronautical Data) to ensure that the part of the process from publication to end-use is addressed in parallel.
The IR will address:
Community Specifications and guidance material required for ensuring compliance with regulatory provisions will also be identified, taking into account current activities to develop appropriate Means of Compliance, software tools and other guidance/procedural material as appropriate and plans to provide support to training and implementation. It may not be possible to define the exact specification and content of the related mandatory, CS and guidance materials until the regulatory approach has been defined and agreed.
The following sections follow the ATM subject headings as listed in Annex I of the Interoperability Regulation [2]
This entry is the extension of the medium term Reference Concept of Operation (see above) to include the long term perspective based both on the EUROCONTROL Concept of Operations for 2020 (ConOps 2020) Volume III which represents the 2nd step in the evolution of the European ATM system towards the vision expressed in the OCD as well as on the findings of the SESAME definition phase. It is the objective of this CS to determine an agreed overall Concept of Operations to be implemented in the long term (2011-2020)having a formal status under the SES interoperability Regulation.
This CS was neither included in M/354 [1] nor in the document ICB/2/3 [5].
This work is of primary importance for any ATM system definition following a Model Driven Approach (MDA) as defined by Industry standards. It provides the methodology which frameworks ATM operational concepts activities providing a vision to achieve, complemented with a detailed coherent and consistent overview of how the European ATM system works. In addition it provides the traceability context to identify and analyse the impact of any changes within the system.
Ignoring the primary importance of this issue will contribute to maintain a fragmented view of the ATM system trough the proliferation of contradicting concepts and creating the opportunities to fail on implementing interoperable ATM systems.
The OCD Volume I and ConOps Volume II are already completed. ConOps Volume III is under development. All this set of documents will be updated within the framework of the SESAME Definition Phase under Work Package 2.2.
EUROCONTROL has an Operational Concept Document Drafting Group (OCD DG), consisting of internal and external stakeholders, as part of the Operational Concept and Architecture (OCA) activity carried out in the EUROCONTROL ATM Strategy and Concepts Business Division.
The Operational Concept documentation described above will support the Single European Sky ATM Modernisation programme (SESAME), the Definition Phase of which has just been launched by theCommission and EUROCONTROL, The SESAME consortium will provide the necessary working structure to support this development. EUROCONTROL will ensure the means to maintain these reference documentation and corresponding approval process under configuration management.
The operational concept is defined in the EUROCONTROL OCD (a high-level vision for the year 2020) and the ConOps (detailed concepts of operations for the years 2011 and 2020) documents. Both the OCD and the ConOps for the target year 2011 are available on the EUROCONTROL website: http://www.eurocontrol.int/oca/public/standard_page/op_concept.html.
Proposal of the SESAME consortium for the definition phase of SESAME.
SESAME WP 2.2
Number of man-days of effort required to develop the CS. Period of time required. Expertise required.
EUROCONTROL CONOPS 2011 contains an ATM Process Model that shows, inter alia, the interfaces between the ATM components throughout all the ATM planning phases. A full traceability is being established from the ATM Process Model to a set of Requirements (Operational, Functional, Performance and Safaety) leading to the development of Use Cases (description of responsibilities and interactions between ATM personnel and systems). These Use Cases are the basis for the development of the OATA Logical Architecture, which provides back a traceability to the Concept of Opertations by mapping Operational Improvements and Enablers, as defined in the framework Strategic Nertwork Performance activity of EUROCONTROL.
At present UAV Systems are used extensively for military and state applications in more than 50 countries around the world. However, it is foreseen that in the near future UAV Systems will be used globally in civil and commercial applications as well. Initial civil users may include customs, police, environmental and metrological institutions, research organisations etc.. Initial commercial applications may include e.g. freight & parcel delivery, structural & environmental inspection, aerial photography & mapping, agricultural applications, pipeline & power line inspection.
The Euro UAV ICB has the objective to provide its views and recommendations towards the routine, safe and reliable operation of UAV Systems in European Airspace. It is widely recognized that the key for successful introduction of UAV Systems in the European Airspace lies with obtaining an ??Equivalent Level of Safety?? for UAV System operations compared to the present (manned) Airspace use.
The Euro UAV ICB, together with a number of important Airspace Management stakeholders, such as EUROCONTROL, EASA and ETSI, have identified priorities in (technological and operational) objectives with respect to, amongst others airworthiness, system-worthiness, safety and security allowing flexible UAV System operations and interoperability in European Airspace and its ATM Network.
This CS has not specifically been included in the Standardisation Mandate M/354.
The below timeline is foreseen for the definition of
Members: ADSE, The Netherlands, Boeing R&T, Spain, Dassault Aviation, France, Diehl BGT Defence, Germany, EADS DCS, France, EADS GmbH, Germany, Galileo Avionica, Italy, QinetiQ, United Kingdom, S2-ATM Ltd, United Kingdom, Saab, Sweden, Sagem Defence & Security, France, Sinovia, France, Stork Fokker, The Netherlands, Thales Airborne Systems, France, Thales Avionics, France, Thales Aerospace, United Kingdom, Ultra Electronics SCS, United Kingdom.
Observers: IAI-Malat Division, Israel, Elbil Systems, Israel, UAV DACH, UVS International.
Below a list of some existing documentation (not exhaustive):
With reference to paragraph 1.3., the effort estimated for the two identified phases are:
This mandate addresses the development of Community Specifications for efficient operation of UAV Systems in European Airspace and its ATM environment, and involves specifications required to ensure safe, secure, interoperable and efficient use of UAV Systems.
The work is divided into two phases: the first phase concentrates on the development of draft CS, while the second involves modifications and completion of the CS following broad stakeholder consultation and validation.
In addition to the work on this CS the availability of frequencies for the remote piloting of UAVs has to be ensured. If not included in this CS, a CS on the remote control system and the information downlink system may be necessary.
Note: Depending on the contents of the final IR on DL it may be necessary to re-scope the following three CSs on DL.
The CS on DL Services over ATN in continental airspace defines the technical and operational conditions necessary to provide data link services over an ATN communication infrastructure in compliance with the DL Services Implementing Rule (under development).
This CS was neither included in M/354 [1] nor in the document ICB/2/3 [5]. No CS has been formally identified with the European Commission??s mandate to EUROCONTROL to draft an IR on DL Services. This CS is proposed as a potential means of compliance pertaining to the Link Baseline 1 DL services over ATN/VDLM2, in case the final IR on DL services encompasses such services.
2003-2007. Introduction phase mandate above FL285 planned starting 1.1.2009 for new aircraft and 2012 for all aircraft.
These documents are de facto standards for which compliance will be required. They do not require additional standardization work.
Compliance to [EUROCAE_ED120] and [EUROCAE_ED110A/B] ensures global interoperability and satisfies the regulatory requirements that will be expressed in the IR on Data Link Services for DL services over ATN/VDLM2 in continental airspace.
These two documents must be developed as European standards.
A European standard might be required for recording.
No additional standards are necessary.
Information not covered by the sub-headings above.
The CS on DL Services over FANS-1/A in continental airspace defines the technical and operational conditions necessary to provide data link services over a FANS-1/A communication infrastructure in compliance with the DL Services Implementing Rule (under development).
This CS addresses the way the FANS-1/A services are expected to be used and also the way FANS-1/A equipped aircraft will be accommodated in the ATN airspace.
This CS was neither included in M/354 [1] nor in the document ICB/2/3 [5]; no CS has been formally identified with the European Commission??s mandate to EUROCONTROL to draft an IR on DL Services. This CS is proposed as a potential means of compliance pertaining to the Baseline-1 DL services over FANS1-A/ACARS, in case the final IR on DL services encompasses such services.
FANS-1/A accommodation will be performed in Link 2000+ on a voluntary basis.
Organisations working on this topic
Reference Material
Relevant documents already known about.
Compliance to [EUROCAE_ED120], [EUROCAE_ED100A] and [EUROCAE_PU40] will ensure global interoperability and satisfy the regulatory requirements that will be expressed in the IR on Data Link Services for DL services over FANS-1/A/VDLM2 in an ATN continental airspace.
These three documents must be developed as European standards.
A European standard might be required for recording.
No additional standards are necessary.
Information not covered by the sub-headings above.
The CS on DL Services over ACARS in continental airspace defines the technical and operational conditions necessary to provide data link services over an ACARS network in compliance with the DL Services Implementing Rule (under development).
This CS was neither included in M/354 [1] nor in the document ICB/2/3 [5]; no CS has been formally identified with the European Commission??s mandate to EUROCONTROL to draft an IR on DL Services. This CS is proposed as a potential means of compliance pertaining to the DL services over ACARS/VDLM2, in case the final IR on DL services encompasses such applications.
DCL and DATIS available today over ACARS.
Organisations working on these topics
Reference Material
Covered by the Link 2000+ Programme.
Compliance to [EUROCAE_ED85A] and [EUROCAE_ED89A] will ensure global interoperability and satisfy the regulatory requirements that will be expressed in the IR on Data Link Services for DL services over ACARS.
These two documents must be developed as European standards.
A European standard is required for recording.
No additional standards are necessary.
Information not covered by the sub-headings above.
.
The main task of a standard ATS middleware is to provide a unified and standardized interface for the ATS applications.
The key issue is to establish:
EC ICB Recommended Priority: Priority 2 (to be kept under review); a CS requirement for ATC Middleware has not been included in the Mandate M/354 [1].
The issue was raised at the Single Sky Committee meeting on 26th May 2004. There 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. As a consequence the Commission included this topic in the document ICB/2/3.
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.
It is assumed that benefits arising in this area will be largely concerned with cost effectiveness. Categorising of benefits is likely to include:
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.
No CBA has been completed for this CS.
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). This work should start before SESAME.
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 and the findings of the SESAME project.
Work ongoing for the iTEC and Coflight projects should be considered as basis for this CS.
Number of man-days of effort required to develop the CS. Period of time required. Expertise required.
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.
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:
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.
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.
The purpose of this item is to develop a community specification covering Advanced Surface Movement Guidance and Control Systems (A-SMGCS).
In the ICB/2/3, this CS was combined with the definition of a standard for arrival management (AMAN) and departure management (DMAN). CSs for AMAN and DMAN are described below.
Advanced Surface Movement Guidance and Control System, A-SMGCS, will in its initial stages, i.e. e. the so-called Level 1 and Level 2 implementations with enhanced surveillance and control functionalities, provide a display to controllers with 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.
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.
In addition the system will enhance safety, alerting the controller by detecting potential conflicts between arriving and departing aircraft and other targets on the runways.
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.
EC ICB Recommended Priority: Priority 2.
This CS is part of Mandate M/354 [1].
Currently basic 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.
The components needed to implement an A-SMGCS Level 1 or Level 2 are already commercially available based on SMR and multilateration technique (and/or ADS-B) and are becoming operational at different levels of maturity on larger airports across Europe.
The advantages of the proposed CS are:
The disadvantages of this CS are:
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 foresees an assessment for the benefit of the aircraft operators, who may need clear reasons should new investment be required to retrofit current aircraft with the proper avionics to comply with A-SMGCS standards (which will normally not be case for commercial aircraft in A-SMGCS Level 1 or 2 environments).
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. Therefore the development of a CS should take into account the maturity of the different A-SMGCS- Levels:
Existing standards:
EU-funded programme EMMA (operational validation)
Number of man-days of effort required to develop the CS. Period of time required. Expertise required.
A-SMGCS is a key enabler both for the prevention of runway incursions and increased airport capacity, including the maintainability of high capacity in periods of reduced visibility. Significant research has been undertaken by the EC, EUROCONTROL and Industry, leading to a number of ICAO and EUROCAE specifications (listed above).
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.
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 on individual local solutions.
Systems aimed at alerting air traffic controllers about potential 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-SMGCS is generally agreed as the key enabler for maintainable high airport capacity with no infringement of the target level of safety, and implementation is already ongoing at several of the largest airports in Europe.
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.
The prime users of A-SMGCS are both the ANSP providing the local aerodrome control services and the local aerodrome operator generally providing not only apron control but also being responsible for e. g. the runway and taxiway lighting systems (which also form part of an A-SMGCS). Therefore A-SMGCS are usually commonly used by both parties, leading also to a sharing of benefits and costs. It is therefore recommended that close liaison with airport operators is being established and maintained throughout the development of this CS.
Basic material for at least Level 1 and Level 2 A-SMGCS are already available through ICAO, EUROCAE, EUROCONTROL and EC RTD Framework Programmes, which should be sufficiently mature for the development of a CS.
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.
This will allow the more efficient use of departure and arrival runaways without increasing the current strain on holding stacks.
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.
EC ICB Recommended Priority: Priority 2.
This item is covered by the Standardisation Mandate M/354 [1]. It was initially proposed in the ATM-CNS Interoperability Roadmap Study [4] and included DMAN as well as A-SMGCS which are covered in separate CSs.
This CS and the CS on Airport CDM are closely related.
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
Advantages of AMAN are:
AMAN is a mature application and the procedures for its 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.
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.
Several Air Navigation Service Providers (see below).
Basic Arrival Management systems are already in use in several European airports. For example the 4D Planner 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.
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.
Number of man-days of effort required to develop the CS. Period of time required. Expertise required.
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.
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.
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.
EUROCONTROL is currently undertaking a Cost Benefit Analysis of AMAN and DMAN.
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.
This will allow the more efficient use of departure and arrival runaways without increasing the current strain on holding stacks.
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.
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.
EC ICB Recommended Priority: Priority 2.
This item is covered by the Standardisation Mandate M/354 [1]. It was initially proposed in the ATM-CNS Interoperability Roadmap Study [4] and included AMAN and A-SMGCS which are covered in separate CSs.
This CS and the CS on Airport CDM are closely related and it should be considered to combine both into one CS.
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.
The advantages of DMAN are:
(Remark: in order to fully optimise the traffic sequence the First Come – First Served principle could not strictly be applied)
DMAN implementation timescale starts 2005.
DMAN is less mature than AMAN. Skyguide has 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 joint AMAN and DMAN trial is planned for Stockholm Arlanda in Autumn 2005
Number of man-days of effort required to develop the CS. Period of time required. Expertise required.
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.
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.
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.
EUROCONTROL is currently undertaking a Cost Benefit Analysis of AMAN and DMAN.
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.
EC ICB Recommended Priority: Priority 2.
The EUROCONTROL ??Guidelines For An Agreement For The Shared Use Of Radar Sensor Data?? 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.
Whilst the deployment of ARTAS is encouraged by EUROCONTROL there are no mandates or ECIPs for ANSPs to abide by.
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.
One existing SDPD product is ARTAS. However, no regulations exist for the operational use of the system. 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...
However, 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 than a special CS on ARTAS.
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.
The ARTAS CBA has resulted in a number of stakeholders adopting ARTAS however the majority of ACCs in ECAC still have proprietary solutions.
Said SDPD units (e.g. ARTAS and others) are already in operation.
Organisations working on this topic.
Number of man-days of effort required to develop the CS. Period of time required. Expertise required.
A 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 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.
The interface between the SDPD units, the data sources (e.g. radar) and its ATM User systems (e.g. a sensor or other SDPD units) are based on ASTERIX. There are three standards relating to inter SDPD data exchange, namely:
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 among many others.
A CS on data exchange, associated protocols and interfaces is much more important to ensure interoperability than a CS on one particular technical solution.
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.
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.
This CS is primarily a transposition of existing EUROCONTROL documents to recognise these documents under the Interoperability regulation
This CS was neither included in M/354 [1] nor in the document ICB/2/3 [5].
Current or anticipated timescales for development and/or adoption.
Organisations working on this topic.
Number of man-days of effort required to develop the CS. Period of time required. Expertise required.
Previous projects included EUROCONTROL projects SPACE and ECG.
This entry should be an update of the CS for the voice telephony CS (ground-ground).
This CS was neither included in M/354 [1] nor in the document ICB/2/3 [5].
Current or anticipated timescales for development and/or adoption.
EUROCAE WG-67.
Relevant documents already known about.
EUROCAE WG-67:
• Technical specifications (mid 2006)
• Operational specifications
• Manual on RCP (2006/2007)
• Guidelines on validation.
Number of man-days of effort required to develop the CS. Period of time required. Expertise required.
Information not covered by the sub-headings above
This CS will contain information beyond that given in Annex 10 concerning HF radio equipment and give it recognition unter the interoperability Regulation.
This CS was neither included in M/354 [1] nor in the document ICB/2/3 [5].
The work on this CS should start as soon as possible, since [2] requires conformity declarations from the 20th October 2005 onward which gives a need for harmonized EN covering all relevant essential requirements.
None, as the system is mature.
Relevant documents already known about.
Number of man-days of effort required to develop the CS. Period of time required. Expertise required.
This CS may have lower priority compared to other CSs.
At TCAM#19 it was confirmed that European Commission expects ATM equipment to be compliant with RTTE directive [9] from 20 October 2005 onwards.t
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 and to enable the timely implementation of APV procedures.
Note: The scope of this CS is not precisely defined yet, a distinction should be made between SBAS system issues and Application issues. SBAS system issues refer to the Signal-In-Space specifications. Applications concern the way the signal in Space is used, including the way it is processed (receiver + other avionics systems) and the way the aircraft used the processed information.
Approach and landing operations with vertical guidance are defined as follows: An instrument approach and landing which utilises lateral and vertical guidance but does not meet the requirements established for precision approach and landing operations.
Approach and landing operations with vertical guidance (APV) have then been introduced in Annex 6 in between Non-Precision Approach (without vertical guidance) and Precision Approach: more precisely, they are defined as instrument approaches which utilise lateral and vertical guidance but do not meet the requirements established for precision approach and landing operations.
APV-I and APV-II are initially performance-based approaches, rather than system based. That means that approach procedures developed based on the performance of APV-I or II could theoretically be used by any aircraft navigation system that complies with the associated performance requirements. However, the operational situation is more complex, in particular, practically, obstacle assessment surfaces and procedures have to be designed based on an operational concept for the elaboration and provision to the pilot of the navigation information during the approach and landing phase of flight (including missed approach). Currently, only the SBAS MOPS [X] provides such a description and this why in the current ICAO OCP work programme, procedure design activities are limited to APV I and II for a particular system, the SBAS.
APV II has lower minima than APV I, and a slightly higher minima (approximately 50 feet) than Cat I. Currently, CAT I is not possible using SBAS only.
.
Space-based Augmentation Systems
have similar needs in the standardisation environment as Ground-Based
Augmentation Systems: In both cases, international standards exist from
ICAO for the Signal-in-Space from the (ground- or ground-controlled)
infrastructure, and from RTCA for the associated avionics.
In the case of SBAS, a European standard should define which exact configuration
is required for the implementation in ECAC. This detail shall cover
the properties of the technical system (e.g. use of message types to
cover adjacent areas, future use of augmentations on L5 frequency) and
the identification of roles, responsibilities and processes for the
certification of such a pan-European system.
If it should transpire that this rulemaking does NOT fall into the
responsibility of EASA, a CS should be put in place.
This item was included in the Standardisation Mandate M/354 [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.
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. Criteria exist for both, although regulatory material is still under development. It should be applicable by November 2006.
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.
The work on APV (Approach with vertical guidance) requirements is ongoing within EUROCONTROL, in line with ANC/11 conclusions. It is expected to be available after necessary validation by 2007. A CS could therefore be completed by that time. CS may be also appropriate for APV that is not necessarily based on SBAS/EGNOS.
Introduction of 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.
Pros:
Cons:
EUROCONTROL are currently developing a business case for APV and Baro-Aided VNAV approaches. The results are expected in the third quarter of 2005.
The EGNOS Multi Modal Costs and Benefits Study of 1999 had listed a number of benefits of general interest for the EU:
Although difficult to quantify at this stage, it is believed that EGNOS could yield benefits for the environment.
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:
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??.
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.
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 I 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.
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.
The work on APV (Approach with vertical guidance) requirements is ongoing within EUROCONTROL, in line with ANC/11 conclusions. It is expected to be available after necessary validation by 2007. A CS could therefore be completed by that time. CS may be also appropriate for APV that is not necessarily based on SBAS/EGNOS.
Reference Material
Related Material
Number of man-days of effort required to develop the CS. Period of time required. Expertise required.
In addition to the work on the CS, action could be undertaken to:
Technical requirements for Approach with Vertical Guidance I/II exist as Standards and Recommended Practices from ICAO in the form of Signal-in-Space performance requirements and the SBAS signal specification. Corresponding Minimum Operational Performance Requirements for on-board equipment exist from RTCA (DO-229C). It has to be secured that Community Specifications will exist to
This items calls for a CS defining standards for aviation use of the Galileo navigation system, but the exact nature of this CS/these CSs should be reviewed
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.
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. Additionally, GPS or GPS plus EGNOS are seen by some as sufficient for existing aviation applications. Further work is therefore required to establish and prove a role for Galileo in aviation.
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.
The item was included in the Standardisation mandate M/354 [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.
In support of this:
Potential benefits for EU
Full confidence would be placed on the use of the GPS system due to the combined use of GPS plus Galileo.
The GOBAN (GNSS Roadmap Study) of 2003 has compared a GNSS scenario with Galileo and a GNSS scenario without Galileo in order to determine what the contributions of Galileo could be.
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.
According to the GOBAN study Galileo potential contribution might then be:
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.
Price Waterhouse Coopers conducted a multi-modal CBA of Galileo [7] 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.
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.
Based on the above, decisions and implementation are highly dependant on:
A Community Specification for Galileo should be pursued in the mid-term, in order to permit that the system can be certificated to a European Standard immediately following its initial operational capability. In case that this could not be secured, the future commercial operator runs a risk of not being able to serve the safety critical markets without delay which may jeopardise the industrial success of the system. Relevant standards should therefore be in place by 2008 to support the system entry into service by 2009.
Related Material
EUROCAE WG 28 Global Navigation Satellite System (GNSS)
Background:
The group is responsible for standards in the area of the Global Navigation Satellite System and MLS
WG-28 co-ordinates its activity with RTCA SC 159 and the ICAO GNSS Panel
Objectives:
WG-28 is has recently been tasked with:
Deliverables:
Recently completed documents:
ED-95 ??MASPS for a GNSS/GBAS System to support Cat I Operations??
ED-114 ??MOPS for GNSS/GBAS Ground System to support Cat I Operations??
ED-88A ??MOPS for a Multimode Receiver including ILS, MLS and GNSS??
Continuing work:
EUROCAE WG62 GALILEO
Background:
GALILEO is the future European navigation satellite system including ground, space and airborne elements. Operations should start from 2008. In the same timeframe, GPS will be modernized, SBAS is expected to evolve to incorporate the GPS modernizations, and airborne receivers will need to evolve in order to incorporate the additional frequency (L5). The airborne GNSS function will be significantly impacted by multiple constellations and the new signals context.
As a consequence there is a need for a representative group of airborne and ground stakeholders able to interact during this process and specifically during the GALILEO definition phase. WG 62 is created to fill this need.
Objectives:
WG62 is a forum to discuss and make recommendations to the Galileo project on issues of concern to civil aviation airborne and ground equipment. To achieve efficiently this task, close relationship with Galileo project management has been established.
Deliverables:
Number of man-days of effort required to develop the CS. Period of time required. Expertise required.
Galileo would be either an alternative to GPS or would be operated in combination with GPS.
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).
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.
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.
In addition to the work on the CS, action could be undertaken to:
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 to
This CS derives appropriate technical requirements from the essential requirements contained in the Interoperability Regulation [2] and the RTTE directive [9] including appropriate procedures for testing of multilateration equipment.
This CS was neither included in M/354 [1] nor in the document ICB/2/3 [5].
The work on this CS should start as soon as possible, since [2] requires conformity declarations from the 20th October 2005 onward which gives a need for harmonized EN covering all relevant essential requirements.
EUROCAE WG-70
Eurocontrol (sub-group of the surveillance team)
Relevant documents already known about.
Number of man-days of effort required to develop the CS. Period of time required. Expertise required.
At TCAM#19 it was confirmed that European Commission expects ATM equipment to be compliant with RTTE directive [9] from 20 October 2005 onwards.
In order to cater for the increased capacity demands, the ATM systems must undergo significant changes over the next few years. Key to the development will be the introduction of new data link applications to support communications, navigation and surveillance. The planned introduction of new data link technologies and services will provide safety, capacity and efficiency benefits. Most significantly, the introduction of an ADS-B system capable of providing aircraft derived Trajectory or Intent information will provide substantial benefits both to the ground and airborne segments of ATM. Through periodic broadcast of aircraft identification, position and trajectory (intent) data both to the ground systems and to other aircraft, ADS-B will provide new means for ATC surveillance supplementing current radars and offer surveillance capabilities in regions with no radar infrastructure. It is also a key element for the introduction of ??Time Navigation?? into European airspace and airports. ADS-B will also provide a new level of pilot situational awareness, and support the detection of conflicts, not only for airborne traffic, but also on the airport surface.
Availability of surveillance data in the cockpit will allow the aircrew to take a more active role in the ATM process and allow pilots and controllers to share separation tasks. Data links will provide new opportunities for downlink of additional aircraft derived data to support enhanced ATC surveillance and uplink of information for use on aircraft..
This CS was neither included in M/354 [1] nor in the document ICB/2/3 [5].
Current or anticipated timescales for development and/or adoption.
First indication: Maintenance of ICAO SARPs, ETSI ENs, definition of new FMS functions and development of CS for onboard displays (CDTI) with ASAS functionality estimated at 300 man/days during 6 calendar/months.
Provide a short description.
This CS was included in M/354 [1] in general terms, but not in the document ICB/2/3 [5]
Current or anticipated timescales for development and/or adoption.
Organisations working on this topic.
ICAO Annex 15 (4, 11, 14)
EUROCAE ED 76 – Industry Standards for the processing of Aeronautical Data.
Relevant documents already known about.
Number of man-days of effort required to develop the CS. Period of time required. Expertise required.
Information not covered by the sub-headings above.
Provide a short description.
This CS was included in M/354 [1] in general terms, but not in the document ICB/2/3 [5]
Current or anticipated timescales for development and/or adoption.
ICAO
EUROCONTROL
Relevant documents already known about.
EUROCONTROL Guidance Material under development.
Number of man-days of effort required to develop the CS. Period of time required. Expertise required.
Information not covered by the sub-headings above.
Provide a short description.
This CS was included in M/354 [1] in general terms, but not in the document ICB/2/3 [5]
Current or anticipated timescales for development and/or adoption.
ICAO
EUROCONTROL.
EUROCONTROL Guidance Material under development.
Relevant documents already known about.
Number of man-days of effort required to develop the CS. Period of time required. Expertise required.
Information not covered by the sub-headings above.
Meteorological information is already well defined within a ICAO and World Meteorological Organisation (WMO) framework. Both for the products itself as for the distribution and use of the information. However, the distribution of information between MET and ATM domain systems could benefit from a community specification, especially in an CDM environment.
These domain systems are:
This CS was neither included in M/354 [1] nor in the document ICB/2/3 [5]; it has been proposed by an MET expert group.
Current or anticipated timescales for development and/or adoption.
In many European states non-standard solution are implemented for the interface between ATM and MET systems;
currently projects under development within the MUAC and the CEATS in co-operation with MET service providers.
Number of man-days of effort required to develop the CS: for each of the systems within the domain systems (raw estimation) 3 men month
Period of time required: 2007-2009
Expertise required: MET and ATM systems experts and technical experts.
Information not covered by the sub-headings above.
The following sections follow the ATM subject headings as listed in Annex I of the Interoperability Regulation [2]
Introductory text to be written by EUROCONTROL. Brief discussion of IR on Airspace Design and Flexible use of Airspace
Provide a short description.
This CS was neither included in M/354 [1] nor in the document ICB/2/3 [5].
Important field, but not yet mature for standardisation; standardisation should be assessed within SESAME...
Organisations working on this topic.
Relevant documents already known about.
Relevant documents already known about.
Number of man-days of effort required to develop the CS. Period of time required. Expertise required.
Information not covered by the sub-headings above.
Provide a short description.
This CS was neither included in M/354 [1] nor in the document ICB/2/3 [5]
Standardisation should be assessed within SESAME, when needs on advanced Data Exchange Formats are more mature.
Organisations working on this topic.
Relevant documents already known about.
Relevant documents already known about.
Number of man-days of effort required to develop the CS. Period of time required. Expertise required.
Information not covered by the sub-headings above.
Provide a short description.
This CS was neither included in M/354 [1] nor in the document ICB/2/3 [5].
Current or anticipated timescales for development and/or adoption.
Organisations working on this topic.
Relevant documents already known about.
Relevant documents already known about.
Number of man-days of effort required to develop the CS. Period of time required. Expertise required.
Information not covered by the sub-headings above.
Provide a short description.
This CS was neither included in M/354 [1] nor in the document ICB/2/3 [5].
Current or anticipated timescales for development and/or adoption.
Organisations working on this topic.
Relevant documents already known about.
Relevant documents already known about.
Number of man-days of effort required to develop the CS. Period of time required. Expertise required.
Information not covered by the sub-headings above.
Provide a short description.
This CS was neither included in M/354 [1] nor in the document ICB/2/3 [5].
Current or anticipated timescales for development and/or adoption.
Organisations working on this topic.
Relevant documents already known about.
Relevant documents already known about.
Number of man-days of effort required to develop the CS. Period of time required. Expertise required.
Information not covered by the sub-headings above.
Provide a short description.
This CS was neither included in M/354 [1] nor in the document ICB/2/3 [5].
Current or anticipated timescales for development and/or adoption.
Organisations working on this topic.
Relevant documents already known about.
Relevant documents already known about.
Number of man-days of effort required to develop the CS. Period of time required. Expertise required.
Information not covered by the sub-headings above.
Provide a short description.
This CS was neither included in M/354 [1] nor in the document ICB/2/3 [5].
Current or anticipated timescales for development and/or adoption.
Organisations working on this topic.
Relevant documents already known about.
Relevant documents already known about.
Number of man-days of effort required to develop the CS. Period of time required. Expertise required.
Information not covered by the sub-headings above.
This entry is a further update of the CS for the voice telephony CS (ground-ground) to include air-ground voice over IP/ethernet.
This CS was neither included in M/354 [1] nor in the document ICB/2/3 [5]; An inventory of Ground/Ground applications and a proposed list of derived CSs should be discussed and agreed by a stakeholder expert group.
Current or anticipated timescales for development and/or adoption.
EUROCAE WG-67.
Action Plan 17 (Eurocontrol/FAA for air/ground com)
7.5.5.5 Existing documentation
Relevant documents already known about.
EUROCAE WG-67:
• Technical specifications (mid 2006)
• Operational specifications
• Manual on RCP (2006/2007)
• Guidelines on validation.
Number of man-days of effort required to develop the CS. Period of time required. Expertise required.
Information not covered by the sub-headings above.
This item calls for the development of a CS to define the technical requirements for Category II / III precision approaches relying on GBAS.
Ground Based Augmentation System (GBAS) is a candidate for 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 segment. GBAS requires the correct operation of the GNSS constellation.
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.
EC ICB Recommended Priority: Priority 3 (no differentiation for CAT I – III).
It was included in the Standardisation Mandate M/354 [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 is in place since 25 November 2004.
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.
It is understood that significant technical obstacles are still to be overcome before standardisation of GBAS Cat II/III can be finalised.
Pros:
Cons:
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.
In 2003, EUROCONTROL produced an xLS cost study (SEFALA) comparing the 3 following scenarios over the 2004-2023 period:
Scenario 1 is a scenario in which ILS ground infrastructure remains the main approach and landing system deployed in ECAC; some MLS or GLS systems are deployed locally on a case by case basis in addition to the ILS systems
Scenario 2 is a scenario in which MLS is retained as the ultimate system, i.e. MLS ground equipment will be widely deployed to replace current ILS equipment or to fulfil new precision approach needs.
Scenario 3 is a scenario in which GLS is retained as the ultimate system, i.e. GLS ground equipment will be widely deployed and will finally replace ILS. Scenario 3 assumed the transition period will start from the beginning of 2012 and last only 8 years. Before the transition period, it is assumed a few MLS systems will be deployed in Europe on a case by case basis in addition to the ILS systems.
The results from this study showed that the "ILS scenario" was less costly by far than the other scenarios.
EURONCONTROL then made an evaluation of the benefits of each scenario, to put them in perspective of the costs. Results shows that the additional benefits brought either in the MLS scenario or in the GLS scenario (in straight-in operations) do not compensate for the additional costs they generate; in other words, MLS and GLS scenarios appeared as less cost-effective than the ILS scenario.
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 I.
It is noted however, that technical difficulties in the definition of GBAS Cat II/II may lengthen this timeframe. The earliest that (restricted) Cat I operations would be possible is 2008. 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.
Reference Material
Related Material
Number of man-days of effort required to develop the CS. Period of time required. Expertise required.
GBAS developments in Europe have followed those in the US (the FAA LAAS programme).
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.
No comprehensive plan seems to be in place in Europe for the deployment of GBAS Cat I ground stations. 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 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 Safe prototype standard by AENA.
Performing GBAS Cat II/III landings 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 may underlie certain restrictions before such date when a sufficient number of GPS Block IIF and/or Galileo satellites are operational.
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 un-compromised Cat II/III capabilities. Regarding Cat I operations, the FAA is promoting WAAS with further enhancements to support such capability.
In addition to the work on the CS, action could be undertaken to:
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.
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.
Provide a short description.
Was it listed in Mandate M/354 [1] and/or ICB/2/3 [5]?
Current or anticipated timescales for development and/or adoption.
Organisations working on this topic.
Relevant documents already known about.
Relevant documents already known about.
Number of man-days of effort required to develop the CS. Period of time required. Expertise required.
Information not covered by the sub-headings above.
Annex N (informative):
Bibliography
As Technical Reports are by definition informative deliverable, all the references are mentioned in clause 2 (see clause 12.1 of EDRs).
| Document history | ||
| V1.1.1 | June2005 | First draft |
1 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]).
2 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]).
3 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.
All Rights Reserved Powered by 文档下载网
Copyright © 2011