Getting to Grips With FANS

AN EADS JOINT COMPANY WITH BAE SYSTEMS

AIRBUS S.A.S.31707 BLAGNAC CEDEX, FRANCE

CONCEPT DESIGN GDCOSREFERENCE GDCOS21 -

DECEMBER 2003PRINTED IN FRANCE

© AIRBUS S.A.S. 2003 ALL RIGHTS RESERVED

The statements made herein do not constitute anoffer. They are based on the assumptions shown andare expressed in good faith. Where the supportinggrounds for these statements are not shown, theCompany will be pleased to explain the basis thereof.This document is the property of Airbus and issupplied on the express condition that it is to betreated as confidential. No use of reproduction maybe made thereof other than that expresselyauthorised.

Flight Operations Support & Line Assistance

getting to grips with

FANSFuture Air Navigation System

Issue II - September 2003

Flight Operations Support & Line AssistanceFuture Air Navigation SystemIssueII - September 2003

Flig

ht O

pera

tions

Sup

port

& L

ine

Ass

ista

nce

g

ettin

g to

grip

s w

ithFA

NS

Is

sue

II -

Sep

tem

ber

200

3

getting to grips with

FANSFuture Air Navigation System

Issue II - September 2003

Flight Operations Support & Line AssistanceCustomer Services

1, rond-point Maurice Bellonte, BP 3331707 BLAGNAC Cedex FRANCE

Telephone (+33) 5 61 93 33 33 Telefax (+33) 5 61 93 29 68

Telex AIRBU 530526FSITA TLSBI7X

Flight Operations Support & Line Assistance Getting to grips with FANS – Ref STL 945.7011/03 3

STEP 3

FANS Future Air Navigation System

Communication Navigation Surveillance (CNS)

Air Traffic Management (ATM)

AIM-FANS (Airbus Interoperable Modular-FANS)

FANS A • Air Traffic Services Data link based on

ACARS network

FANS B • Introduction of ATN (Aeronautical Telecommunication Network)

• ICAO approved (CNS/ATM-1 standards)

FULL FANS • "Free Flight" concept supported

STEP 2

STEP 1

To allow for efficient:

Aircraft upgrade of:

Airbus product:


FOREWORD


FOREWORD The purpose of this brochure is to provide Airbus aircraft operators with the agreed interpretations of the currently applicable CNS/ATM (i.e. FANS) regulations. The intent is thus to provide guidance material on CNS/ATM operations, which satisfy airworthiness requirements in order for an airline to obtain operational approval from its national operational authorities. All recommendations conform to the current regulatory requirements and are intended to assist the operators in maximising the cost effectiveness of their operations. The content of this second edition is limited to the FANS A system, which is in use at the date of publication (Step 1, ref. p3). New feature have been added to the 1st edition, such as a description of the Airbus FANS A+ package, new FANS application procedures, and a FANS world status. Future editions will include information on further systems, e.g. ATN (or CNS/ATM-1; Step 2, ref. p3) based systems and ADS-B, once these are certified and there are definite plans to introduce them in some areas. As detailed hereafter, CNS/ATM is a global system concept, which is based on global navigation, communications and automatic dependent surveillance systems. Although FANS air spaces or routes are usually defined in terms of all the three C, N and S aspects, this brochure mainly addresses the Data Link Communications and Automatic Dependent Surveillance issues only. Recommendations for RNP (Required Navigation Performance) and RVSM (Reduced Vertical Separation Minima) operational approval are given in the brochure “Getting to grips with modern navigation” - A flight operations view - (reference: STL 945.0415/99). Whenever needed, the reader will be invited to refer to this document. Any questions with respect to information contained herein should be directed to:

AIRBUS SAS

Flight Operations Support Customer Services Directorate

1, Rond Point Maurice Bellonte, BP 33 31707 BLAGNAC Cedex- FRANCE

TELEX: AIRBU 530526F

SITA: TLSBI7X Telefax: 33 5 61 93 29 68 or 33 5 61 93 44 65

TABLE OF CONTENTS


TABLE OF CONTENTS EXECUTIVE SUMMARY.............................................................................................. 10 ABBREVIATIONS ........................................................................................................ 18 1. CNS/ATM CONCEPT............................................................................................ 22

1.1. Historical background ..................................................................................... 22

1.2. CNS/ATM global concept ................................................................................ 22

1.3. Communications.............................................................................................. 23

1.4. Navigation......................................................................................................... 24

1.5. Surveillance...................................................................................................... 24

1.6. Air Traffic Management ................................................................................... 24 2. CNS/ATM COMPONENTS DESCRIPTION .......................................................... 26

2.1. FANS A architecture ........................................................................................ 26

2.2. Datalink media.................................................................................................. 27 2.2.1. Air/Ground datalink ..................................................................................... 27 2.2.2. Ground/Ground datalink.............................................................................. 29

2.3. CNS/ATM ATC applications ............................................................................ 31 2.3.1. ATS Facility Notification (AFN).................................................................... 31 2.3.2. Controller Pilot Data link Communications (CPDLC) .................................. 31 2.3.3. Automatic Dependent Surveillance (ADS) .................................................. 32 2.3.4. AEEC623 .................................................................................................... 33

2.4. Performance requirements ............................................................................. 33 2.4.1. General ....................................................................................................... 33 2.4.2. Required Navigation Performance (RNP) ................................................... 33 2.4.3. Required Communication performance (RCP)............................................ 34 2.4.4. Required Surveillance Performance (RSP)................................................. 34

3. AIM-FANS DESCRIPTION.................................................................................... 38

3.1. General: the need for flexibility....................................................................... 38

3.2. AIM-FANS architecture .................................................................................... 40 3.2.1. The ATSU ................................................................................................... 40 3.2.2. The new FMS (2nd generation FMS).......................................................... 41 3.2.3. Crew interfaces ........................................................................................... 42

3.3. Human Machine Interface................................................................................ 42 3.3.1. Basic operational principles ........................................................................ 44 3.3.2. Main HMI rules............................................................................................ 44

TABLE OF CONTENTS


4. OPERATIONAL PROCEDURES ...........................................................................50

4.1. Introduction.......................................................................................................50

4.2. Pre-flight phase.................................................................................................50

4.3. ATS Facilities Notification (AFN) .....................................................................51

4.4. CPDLC procedures...........................................................................................55 4.4.1. CPDLC connection ......................................................................................55 4.4.2. CPDLC connection transfer .........................................................................56 4.4.3. End of service..............................................................................................59 4.4.4. Failures of the CPDLC connection...............................................................60 4.4.5. CPDLC shutdown ........................................................................................60 4.4.6. Abnormal cases at the time of transfer of connection..................................61 4.4.7. Recommendations for exchange of CPDLC messages...............................61

4.5. ADS procedures................................................................................................68 4.5.1. ATS notification and ADS connection ..........................................................68 4.5.2. ADS connections management ...................................................................71 4.5.3. Position reporting with ADS .........................................................................72 4.5.4. ADS connections closure.............................................................................72 4.5.5. Route offset .................................................................................................73 4.5.6. ADS shutdown.............................................................................................73 4.5.7. Emergency procedures................................................................................73

4.6. ATS623 applications.........................................................................................74 5. FANS A EVOLUTION ............................................................................................78

5.1. FANS A enhanced ADS ....................................................................................78

5.2. FANS A+ (FANS A system evolution) .............................................................78 5.2.1. FANS A+ basics ..........................................................................................79

5.2.1.1. Enhancements to the Human-Machine Interface (HMI) ...........................79 5.2.1.2. Improvements related to the CPDLC service. ..........................................80 5.2.1.3. DataLink Service Provider (DSP) worldmap ............................................81 5.2.1.4. ATSU router customisation via loadable database...................................81 5.2.1.5. BITE (Built-In Test Equipment) improvement...........................................81

5.2.2. FANS A+ options .........................................................................................82 5.2.2.1. HF dataLink (HFDL) .................................................................................82 5.2.2.2. High speed VHF datalink (VDL mode2) ...................................................83 5.2.2.3. Wired high speed dataloading capability (AEEC 615a)............................83 5.2.2.4. Clearances and digital ATIS applications (ATS623).................................84

5.2.3. FANS A+ Retrofits .......................................................................................84

TABLE OF CONTENTS


6. FANS A WORLD STATUS ................................................................................... 88

6.1. Status of Fans A implementation ................................................................... 88

6.2. North Atlantic (NAT)......................................................................................... 89

6.3. South Atlantic................................................................................................... 90

6.4. North Canada.................................................................................................... 91

6.5. Pacific Ocean.................................................................................................... 91

6.6. Indian Ocean : South Africa ............................................................................ 94

6.7. Indian Ocean : Australia .................................................................................. 95

6.8. Singapore ......................................................................................................... 96

6.9. Bay of Bengal ................................................................................................... 96

6.10. China ................................................................................................................. 97 7. STARTING FANS OPERATIONS....................................................................... 100

7.1. General............................................................................................................ 100

7.2. DataLink: contracts and declarations .......................................................... 100 7.2.1. Contracts with Datalink Service Providers (DSP)...................................... 100 7.2.2. Aircraft declaration to DataLink Service Providers and ATC centres ........ 101 7.2.3. Recommendations .................................................................................... 101

7.3. Impact on aircraft configuration ................................................................... 101 7.3.1. ATSU scan mask ...................................................................................... 101 7.3.2. SATCOM user ORT .................................................................................. 101 7.3.3. AMI database of the FMS ......................................................................... 102

7.4. Get the operational approval......................................................................... 102 7.4.1. General requirements ............................................................................... 102 7.4.2. Aircraft configuration ................................................................................. 103 7.4.3. Flight crew training / qualification .............................................................. 103 7.4.4. Maintenance training................................................................................. 111 7.4.5. Approved documentation .......................................................................... 111

TABLE OF CONTENTS


APPENDIX A : LIST OF CPDLC MESSAGES WITH THEIR MEANING....................116 APPENDIX B : ADS REPORT DATA .........................................................................133 APPENDIX C : DATA COMMUNICATIONS SERVICE PROVIDERS ........................135 APPENDIX D : SATCOM OPERATORS ....................................................................144 APPENDIX E : FANS OPERATIONAL PROCEDURES.............................................144 1 - Pacific FANS operations......................................................................................145 2 - Indian ocean FANS operations ...........................................................................148 3 - North Atlantic FANS operations..........................................................................150 4 - South Atlantic FANS operations (trials) .............................................................159 5 - New York oceanic (KZWY) CPDLC service area................................................165 APPENDIX F : DYNAMIC AIRBORNE ROUTE PLANNING......................................167 APPENDIX G : OPERATIONAL SCENARIOS FANS A.............................................169 1 - Initial notification..................................................................................................169 2 - CPDLC logon ........................................................................................................172 3 - Logon to next ATC ...............................................................................................174 4 - Clearance ..............................................................................................................178 5 - When can you… ...................................................................................................181 APPENDIX H : OPERATIONAL SCENARIOS FANS A+...........................................186 1 - Initial notification..................................................................................................186 2 - CPDLC logon ........................................................................................................189 3 - Connection to next ATC.......................................................................................191 4 - Clearance ..............................................................................................................195 5 - When can you .......................................................................................................195 APPENDIX I : OPERATIONAL SCENARIOS ATS623...............................................200 APPENDIX J : OIT/FOT NEW ATSU AIRCRAFT INTERFACE .................................212 APPENDIX K : FANS A AIRWORTHINESS SUMMARY ...........................................216

EXECUTIVE SUMMARY


EXECUTIVE SUMMARY

1 – CNS/ATM CONCEPT CNS/ATM global concept • Increasing the airspace capacity, enhancing the operational efficiency while ensuring

the best safety level of the air traffic cannot be done without a combined use of the air and ground entities. Following this statement, the concept of CNS/ATM (Communication, Navigation and Surveillance for Air Traffic Management) has been defined.

• Numerous actors play in this global end-to-end concept, which can be seen as a chain linking a pilot and a controller. Although most of these actors are independent entities, the proper interoperability of all of them is the key factor for the right operation of the system.

Communications • Operationally speaking, the biggest change provided by FANS is the way pilot and

controllers communicate. In addition to the classical VHF and HF voice, and to the more recent satellite voice, digital CPDLC (Controller Pilot Data Link Communications) will now become the primary means to communicate.

• CPDLC is a powerful means to sustain ATC communications in oceanic or remote areas first, and it is expected to become, in a near future, an additional tool to overcome VHF congestion in some busy TMAs.

Navigation • FANS routes or air spaces are associated with a given RNP (Required Navigation

Performance) value. This RNP is a statement on the navigation performance accuracy necessary for operation in this air space.

Surveillance • Different types of surveillance may be founded. Wherever radar coverage is

possible, SSR modes A and C are still used (mode S is soon expected to be used in such areas).

• In oceanic and remote FANS air spaces, procedurally controlled surveillance is progressively replaced by Automatic Dependent Surveillance, which is expected to allow for reduced lateral and longitudinal separation. It is also expected that there will be no need for HF voice reporting any longer.

Air Traffic Management • Under this term is grouped a large set of methods to improve the management of all

the parts of the air traffic, e.g. traffic flow management, strategic (long term) and tactical (short term) control or air traffic services. New methods are developed and progressively implemented to provide greater airspace capacity to cope with the large increase of air traffic demand.

EXECUTIVE SUMMARY


2 - CNS/ATM COMPONENT DESCRIPTION Pending the new Aeronautical Telecommunication Network (ATN) availability for FANS B, the current FANS A step uses the ACARS network to exchange data between aircraft and ground systems. FANS A data link architecture

• The airborne part: the ATSU which manages all the communications and automatically chooses the best available medium (e.g. VHF, Satcom and HF, in that order).

• The air/ground datalink: used to transmit AOC or ATC data to the ground through VDL modeA, VDL mode2, Satcom and HFDL.

• The ground/ground datalink: to ensure the connection to the ground parts through either satellites Ground Earth Stations (GES), VHF and HF Remote Ground Stations (RGS), air-ground processors (which route and handle the messages).

• DSP operating with national service providers are currently interconnected to provide a global interoperability of ATS data link applications.

FANS A applications

• ATS Facility Notification (AFN) Through this application, an ATC knows whether an aircraft is capable of using data link communications. This exchange of the data link context is needed prior to any CPDLC or ADS connection.

• Controller Pilot Data Link Communications (CPDLC) CPDLC is a powerful tool to sustain data link communications between a pilot and the controller of the relevant flight region. It is particularly adapted to such areas where voice communications are difficult (e.g. HF voice over oceans or remote part of the world), and is expected to become very convenient to alleviate congested VHF of some busy TMAs when utilised for routine dialogue (e.g. frequency transfer).

• Automatic Dependent Surveillance (ADS) Through the ADS application, the ATSU automatically sends aircraft surveillance data to the connected ATC centres (up to 4). This is done automatically and remains transparent to the crew. Different types of ADS "contracts" exist: periodic, on demand and on event

• AEEC623 The AEEC623 specification defines the application text formats for character-oriented Air Traffic Services messages (e.g. departure or oceanic clearances), that can be transmitted over the ACARS data link.

Performance requirements

The three concepts of Required Navigation Performance (RNP), Required Communications Performance (RCP) and Required Surveillance Performance (RSP) are all parts of a general CNS/ATM performance concept and independent of the technologies used.

EXECUTIVE SUMMARY


3 - AIM-FANS DESCRIPTION The transition to CNS/ATM requires both flexibility and growth capability. For the airplane, flexibility is the essential requirement, but requires computer power. This was tackled right from the beginning with the AIM-FANS avionics package: indeed, the power and flexibility of a dedicated communications unit (the ATSU) combined with the power of a new FMS. AIM-FANS avionics

• This new avionics unit (ATSU) has been developed to cope with data link

communications. Its functions are: - To manage the HMI, the display and warning systems. - To enable the access to all available communications media. - To sustain the communications tasks.

• The FMS is a key element of the AIM-FANS system for which :

- It provides data to the ATSU - It monitors the ATC messages and their subsequent implications - It handles and processes some of the ATC messages

Crew interface

• The main crew interface used for the FANS applications is based on the two

DCDUs. All ATC messages, clearances (uplink message), requests or answers (downlink messages) are displayed on the DCDU. In addition to the DCDU, the MCDU is mainly used to prepare a request.

4 - OPERATIONAL PROCEDURES

Pre-flight phase ICAO F-PLN filing The CNS/ATM capabilities of the aircraft will be notified when filing in the ICAO flight plan.

• The data link capability is notified by a letter "J" to be entered in the field 10. • The letter "D" is also entered in the surveillance part of that field, if ADS is

available. • The other capabilities are given in the field 18 (Other Information) under the

DAT/ information. The following code is used: S (Satellite data link), H (HFDL), V (VHF data link), M (SSR Mode S data link)

Pre-flight checks Prior to departing for a FANS flight, the crew will check that the required equipment is operative. The following items are recommended to be included in those checks:

- GPS availability - UTC time settings - RNP capability - Data link communications availability - Flight Id. (on the MCDU “COMM INIT“ page) - Airlines’ priority list of contracted DSP for FANS operations with this aircraft

EXECUTIVE SUMMARY


ATS Facilities Notification (AFN) The aim of the ATS Facilities Notification is to:

- notify the appropriate ATC centre of the capabilities and specifics of the aircraft data link communication applications

- give the flight identification and the aircraft registration number When no other CPDLC or ADS connections have been established with a previous ATC centre, the AFN must be exercised (e.g. prior to departure, prior to entering a data link airspace). The AFN can be initiated:

- manually by the pilot, or - automatically by the ATSU using the address forwarding process.

The AFN must be successfully completed prior to any connection is being established. CPDLC procedures CPDLC Connection

• Once the AFN has been successfully done, the ATC centre can initiate a CPDLC connection (transparent to the crew).

• Checks are automatically done by the ATSU to validate or reject the connection: - Connection is accepted if no previous connection already exists or, it is

relative to the next data link ATC to control the aircraft - Connection is rejected in all other cases

• Once connection is established, the active connected ATC centre is then displayed on the DCDU, and on the CONNECTION STATUS page of the MCDU.

Failures of the CPDLC connection

• As soon as a failure of the CPDLC connection is noticed by either the crew or the ground controller, voice will be used to inform the other part of the failure and to co-ordinate further actions.

• Once a connection has been lost, a complete LOGON procedure (AFN + Connection) must be done.

Transfer to the next ATC

• To inform the aircraft avionics (i.e. ATSU) that a transfer of control will occurred, the current active ATC sends a so-called NDA message (Next Data Authority) to the aircraft. This is the only way for the ATSU to be aware of and to accept the connection with the next ATC centre.

• Once a NDA message has been received, the aircraft is waiting for the connection with the next ATC centre.

• Under normal circumstances the CPDLC connection should be established with the Next Data Authority prior to the connection between the aircraft and the current data authority being terminated

EXECUTIVE SUMMARY


To be noticed Pending the ATN, as long as the FANS A ACARS based protocols is used, both pilot and controllers cannot know whether a message has been delivered to their right counterpart. ADS procedures

ADS connections • An ATC centre can establish ADS contracts once the AFN has been performed. • FANS A equipped aircraft can have up to five ADS connections.

One of these is reserved to the AOC. The aircraft has the capability to report to four different ATC centres simultaneously using ADS.

• Different types of ADS "contracts" exist: - periodic: the data are sent at periodic time intervals. - on demand: the data are sent only when asked for. - on event: the data are sent whenever a specified event occurs.

• ADS is transparent to the crew. In particular, contracts can not be modified from the aircraft. A connection may be stopped from the ground or manually by the crew through the CONNECTION STATUS page of the MCDU ATC menu

• ADS contracts and connections should normally be terminated by the ground system when the: - Aircraft has crossed a FIR boundary - Aircraft's flight plan has been cancelled or has finished

• A Waypoint will not be sequenced if the position is offset by more 7NM aside from this point. When an offset is flown, it is recommended that the crew keeps updated his FMS flight plan, and that he uses the FMS Offset function.

ADS shutdown When a shutdown occurs the controller will advise the crew of the requirements for the position reports (by voice or CPDLC). ADS emergency • The emergency mode can be activated either by the pilot or the controller, and is

normally cancelled by the pilot. When selected on the MCDU ATC page, the FMS immediately sends a message to all ATC centres that currently have contracts established with that aircraft.

• The controller in charge of the flight shall acknowledge any ADS emergency message.

ATS623 applications Pending for a greater maturity of standardised services, Airbus has decided to implement only three AEEC623 applications:

- Departure Clearance (DCL) - Oceanic Clearance (OCL) - Digital – Automatic Terminal Information Service (D-ATIS)

EXECUTIVE SUMMARY


• In case similar applications have been customised through AOC (ACARS) contracts,

these will no longer be available should the ATS623 package be chosen (e.g. AOC DCL or OCL will no longer be sent from a customised AOC page).

• However, ,customised AOC functions such as Pre-Departure Clearance (PDC),

which is not compliant with the AEEC 623 specifications, will remain possible through the ACARS.

5 - FANS A EVOLUTION Enhance ADS Current FANS A ADS system can be enhanced through the updates of the ATSU software (CLR3.6b) and FMS Pegasus 2 software (as detailed in Appendix G). FANS A+ standard To improve the current FANS A package and extend the use of data link services, a new standard, called FANS A+, has been developed.

♦ Improvements address points coming from: - operational / in service feedback from operators - interoperability and standardization objectives - improvement of Human Machine Interface (HMI) - functional evolutions

♦ New data link services have also been added with the introduction of : - VDL mode 2, so as to increase the capacity for ATC communications - HFDL capability for ATC (once this service is approved) - ATS623 (Departure and Oceanic clearances, Digital-ATIS applications) - High speed dataloading capability (AEEC 615a)

FANS A+ retrofits

To upgrade aircraft systems from FANS A to FANS A+ standards, only a software update is necessary (no hardware components need to be changed).

FANS A ACARS Router ATSU Software CLR3.5

FANS A with enhanced ADSACARS Router ATSU Software CLR3.6

FANS A+ ACARS Router ATSU Software CLR4.5

Jan-2004

Enhanced ADS automatically provided with FANS A+ standards

1Q-2003

EXECUTIVE SUMMARY


6 - STATUS OF FANS A IMPLEMENTATION • For the time being only remote areas such as oceanic or desert areas are

implemented with FANS. In these areas ATC radar cannot be used to control Air Traffic and HF radio is used for voice communication with ATC.

• All FIRs which are FANS equipped, do not provide the same services.

These FIRs may provide the following FANS functions - Both ADS and CPDLC. - ADS only - CPDLC only

7 - STARTING FANS OPERATIONS To ensure proper operations of FANS A aircraft on FANS routes, the operator needs to ensure the following before starting operations:

1. Sign contract(s) with Datalink Service Provider(s) (DSP) 2. Declare aircraft to these Datalink Services Providers 3. Declare aircraft and its FANS capability to ATC centres of the operated routes 4. Configure adequately the aircraft avionics 5. Obtain the operational approval

Contracts with Datalink Service Providers • To operate in FANS environment, it is necessary to have a contract with at least one

of the major service providers (ARINC or SITA) for SATCOM and VDL datalink • For ATC datalink, each individual aircraft must be declared, and identified namely

through its Aircraft Registration Number in DSP tables. • In addition, the SATCOM AES (Aircraft Earth Station) identification, i.e. the aircraft

ICAO address, must be declared to the GES (Ground Earth Station) the aircraft will operate. This is achieved through the SATCOM commissioning procedure.

Impact on aircraft configuration Once the airline has selected the datalink service providers, the aircraft configuration needs to be adapted accordingly. This can be achieved through customization of:

- The ATSU (Air Traffic Services Unit) scan mask for VHF DataLink - The SATCOM user ORT for SATCOM datalink

Operational approval Rules are not yet fully available and individual operational authority may choose the "means of compliance" stating what the applicant airline may have to demonstrate. However, the following items will have to be complied with:

- Aircraft configuration The aircraft should be configured in accordance with the approved certification configuration for FANS A operations

- Flight crew training/qualification Operating an aircraft in a FANS type environment requires from the crew understanding, knowledge and operational use of the three C, N and S dimensions of the CNS/ATM concept.

EXECUTIVE SUMMARY


- Maintenance training

An appropriate maintenance training program relative to the digital communications, must be given to maintenance people

- Approved operational documentation The applicant airline should present to its relevant authority the FANS A Airworthiness Approval Summary, the MEL and the AFM to be approved.

It is strongly recommended not to make spontaneous FANS testing with ATCcentres when they have not been previously made aware of a given aircraftintention to operate in FANS mode.

ABBREVIATIONS


ACARS Airline Communications, Addressing, and Reporting System ADF Automatic Direction Finder ADIRS Air Data Inertial Reference System ADNS Arinc Data Network Service ADS Automatic Dependent Surveillance ADS-B Automatic Dependent Surveillance- Broadcast AEEC Airlines Electronics Engineering Committee AES Aircraft Earth Station AFN ATS Facility Notification AFTN Aeronautical Fixed Telecommunication Network AIDC ATC Inter-facility ground/ground Data Communications AIM-FANS Airbus Interoperable Modular- Future Air Navigation System AIP Aeronautical Information Publication AMI Airline Modifiable Information AMU Audio Management Unit AOC Airline Operations Communications (or Centre) ARINC Aeronautical Radio INC ATC Air Traffic Control ATM Air Traffic Management ATN Aeronautical Telecommunication Network ATS Air Traffic Services ATSU Air Traffic Services Unit CDTI Cockpit Display of Traffic Information CFDIU Centralised Fault Display Interface Unit CMC Central Maintenance Computer CNS/ATM Communication Navigation Surveillance/Air Traffic Management CPDLC Controller Pilot Data Link Communications CTA Control Area DARP(S) Dynamic Airborne Route Planning (System) DCDU Data Communications Display Unit DFIS Digital Flight Information Services DGPS Differential GPS DL Down Link DM Downlink Message DSP Data Service Providers (or Processor) EATMS European Air Traffic Management System ECAM Electronic Centralised Aircraft Monitoring EFIS Electronic Flight Information System EIS Electronic Instrument System ERSA En-Route Supplement Australia EUROCAE European Organisation for Civil Aviation Equipment FANS Future Air Navigation System FHA Functional Hazard Analysis FIR Flight Information Region FIS Flight Information Services FIT FANS Inter operability Team FMS Flight Management System

ABBREVIATIONS


FWC Flight Warning Computer GES Ground Earth Station GNSS Global Navigation Satellite System GLS GPS Landing System GPS Global Positioning System HFDL High Frequency Data Link HFDR High Frequency Data Radio HMI Human Machine Interface ICAO International Civil Aviation Organisation IFALPA International Federation of Airline Pilot Associations ISPACG Informal South Pacific ATC Co-ordinating Group LSK Line Select Key MASPS Minimum Aviation Systems Performance Standards MCDU Multifunction Control and Display Unit MDDU Multi Disk Drive Unit MMR Multi Mode Receiver Mode S Radar Mode S NAS National Airspace System NDA Next Data Authority NOTAM NOtice To Air Men NPA Non Precision Approach OCA Oceanic Control Area ORT Owner Requirements Table PACOTS Pacific Organised Track System RAIM Receiver Autonomous Integrity Monitoring RCP Required Communications Performance RGS Remote Ground Station RNAV Area Navigation RNP Required Navigation Performance RSP Required Surveillance Performance RTCA Requirements and Technical Concepts for Aviation RVSM Reduced Vertical Separation Minima SATCOM Satellite Communications SITA Société Internationale de Télécommunications Aéronautiques SOP Standard Operating Procedures SOR System Objectives and Requirements SPOM South Pacific Operating Manual SSR Secondary Surveillance Radar TDM Track Definition Message TMA Terminal Area TMU Traffic Management Unit UL Up Link UM Uplink Message V/DME VHF/Distance Measurement Equipment VDL VHF Data Link VDR VHF Data Radio WPR WayPoint Reporting

ABBREVIATIONS


1 - CNS/ATM CONCEPT


1. CNS/ATM CONCEPT.............................................................................................22 1.1. Historical background ...............................................................................22 1.2. CNS/ATM global concept ..........................................................................22 1.3. Communications........................................................................................23 1.4. Navigation ..................................................................................................24 1.5. Surveillance................................................................................................24 1.6. Air Traffic Management .............................................................................24

1 – CNS/ATM CONCEPT


1. CNS/ATM CONCEPT

1.1. HISTORICAL BACKGROUND In 1983 the ICAO council tasked its special committee on Future Air Navigation Systems (FANS) to make recommendations to upgrade the communications, navigation and surveillance systems so as to cope with the evolution of the world wide air traffic. In 1989, based on the previous work, a second committee was created aiming at the implementation of the CNS/ATM (Communication, Navigation, Surveillance / Air Traffic Management) concept. This concept was endorsed by the Tenth Air Navigation Conference in 1991. It is mainly built on satellite technology and digital communications and aims at increasing the air space capacity, enhancing the operational flexibility and global safety of the air traffic.

1.2. CNS/ATM GLOBAL CONCEPT The CNS/ATM acronym states what is behind its concept. Increasing the airspace capacity, enhancing the operational efficiency while ensuring the best safety level of the air traffic cannot be done without a combined use of the air and ground elements. Numerous actors play in this global end-to-end concept, which can be seen as a chain linking a pilot and a controller. Although most of these actors are independent entities (e.g. Air Traffic Services organisations, communication service providers or ATC) the proper interoperability of all of them is the key factor for the right operation of the system.

Figure 1.1 CNS/ATM global concept

Navigation satellites (GNSS)

ATC Information Service

Airline Host

Ground-based Radio (VHF & HF)

Satcom Transponder Ground Network for

DDaattaa CCoommmmuunniiccaattiioonnss

AAiirr

GGrroouunndd

SSppaaccee

Differential GNSS station

Communication satellites (SATCOM)

1 - CNS/ATM CONCEPT


1.3. COMMUNICATIONS Operationally speaking, the biggest change provided by FANS is the way pilot and controllers communicate. In addition to the classical VHF and HF voice, and to the more recent satellite voice, digital CPDLC (Controller Pilot Data Link Communications) will now become the primary means to communicate. CPDLC is a powerful means to sustain ATC communications in oceanic or remote areas first, and it is expected to become, in a near future, an additional tool to overcome VHF congestion in some busy TMAs. On board, CPDLC messages are displayed to the crew on the dedicated DCDU (Data Communication Display Unit) screens. They can also be printed. Ground-ground communications are also part of the concept. They serve to link and to co-ordinate in between different ATC service organisations (or services of the same ATC) and AOC (Airline Operational Centre). AFTN, voice or AIDC (ATS Interfacility Data Communications) ensure these communications. Under commercial and financial pressures, the airlines have asked for FANS benefits without waiting for complete availability of all the appropriate tools (such as a better Aeronautical Telecommunications Network: the ATN). That is why FANS A operations have already started using the existing communications networks and protocols (ACARS / ARINC 622) which are of less performance than the ATN, but were endorsed by the ICAO as a valuable step towards an early introduction of ATM applications. ATN is implemented and successfully operated both in Miami and Maastricht FIRs. These ATC are currently used as test centres. First implementation phases are scheduled for 2005, with the CPDLC Build1A program (for Miami) and Link2000+ program (for Europe). The objective of those programs is to plan and co-ordinate the implementation of operational Air/Ground Data-Link services for Air Traffic Management.

1 – CNS/ATM CONCEPT


1.4. NAVIGATION To fully benefit from the CNS/ATM concept, aircraft will need to attain a certain level of navigation performance in terms of accuracy, availability, integrity and service continuity. Required Navigation Performance (RNP) is a navigation element, which is expected to affect currently existing airspace structures and lead to a whole new concept in air navigation. Another modern navigation trend involves the development of instrument procedures that are not based on conventional radio Navaids. This type of navigation is called Area Navigation or RNAV. It can be used En-route, in association with the RNP concept, but also for terminal area navigation and instrument approach procedures. Refer to the “Getting to grips with modern navigation” document for detailed explanations. 1.5. SURVEILLANCE Different types of surveillance may be found. Wherever radar coverage is possible, SSR modes A and C are still used. Mode S is expected to be used in such areas where traffic densities are high enough to warrant it. In oceanic and remote FANS air spaces, procedurally controlled surveillance is progressively replaced by Automatic Dependent Surveillance, which allows the aircraft to automatically send position data and F-PLN intents to up to four different ATC centres. It is expected that there will be no need for HF voice reporting any longer. With the possibilities offered to the controllers to select the rate and mode of reporting (at specified time intervals or on the occurrence of a special event such as a heading or attitude change), ADS is expected to allow for reduced lateral and longitudinal separation. 1.6. AIR TRAFFIC MANAGEMENT Under this term is grouped a large set of methods to improve the management of all the parts of the air traffic, e.g. traffic flow management, strategic (long term) and tactical (short term) control or air traffic services. New methods are developed and progressively implemented to provide greater airspace capacity to cope with the large increase of air traffic demand. A close co-operation of ATS, crews and airline operational centres, is expected to be reached through data communications, and automated sharing of real-time information. CPDLC, ADS and AOC/ATC inter-facility link are some of the tools used to support new ATM methods such as Collaborative Decision Making (CDM). The aim of CDM is to enable the corresponding actors (crews, controllers and airline operations) involved in ATM system, to improve mutual knowledge of the forecast/current situations, of each other constraints, preferences and capabilities, so as to resolve potential problems.


2. CNS/ATM COMPONENTS DESCRIPTION...........................................................26 2.1 FANS A architecture ...................................................................................26 2.2. Datalink media............................................................................................27

2.2.1. Air/Ground datalink ............................................................................27 2.2.2. Ground/Ground datalink ....................................................................29

2.3. CNS/ATM ATC applications ......................................................................31

2.3.1. ATS Facility Notification (AFN) ..........................................................31 2.3.2. Controller Pilot Data link Communications (CPDLC) .........................32 2.3.3. Automatic Dependent Surveillance (ADS) .........................................33 2.3.4. AEEC623...........................................................................................34

2.4. Performance requirements .......................................................................33

2.4.1. General ..............................................................................................33 2.4.2. Required Navigation Performance (RNP)..........................................33 2.4.3. Required Communication performance (RCP) ..................................34 2.4.4. Required Surveillance Performance (RSP)........................................34

2 – CNS/ATM COMPONENTS DESCRIPTION


2. CNS/ATM COMPONENTS DESCRIPTION

2.1. FANS A ARCHITECTURE Pending the new Aeronautical Telecommunication Network (ATN) availability (for FANS B implementation), the current FANS A step uses the ACARS network to exchange data between aircraft and ground systems. This ACARS network can be accessed through either satellite, HF or VHF media, and various ground networks are inter-connected to provide the ATC/ATM services to all FANS A equipped aircraft. These data communications are supported by the aircraft's ATSU (Air Traffic Service Unit), which manages all the communications and automatically chooses the best available media (for example VHF, Satcom and HF, in that order). The FANS A data link architecture is given in figure 2.1. It is made of the following components: • The airborne part, with the ATSU, which is a modular hosting platform that

centralises all data communications (ATC and AOC) and manages the dedicated Human Machine Interface (HMI).

• The air/ground datalink, VDL modeA/2, Satcom or HFDL are used to transmit AOC or ATC data to the ground.

• The ground/ground datalink, which ensure the connection to the ground part through either : - Satellite Ground Earth Stations (GES) whenever VHF coverage is not available - VHF and HF Remote Ground Stations (RGS) if within the line of sight of the aircraft - Air-Ground processors, which route and handle the messages

Figure 2.1 FANS A architecture

ACARS networks

Global Positioning Satellites (GPS)

Airline Operations Control

Communication satellites (SATCOM)

VDL Mode A ground station

SATCOM ground station

VDL Mode 2ground station

Air Traffic Control

HFDL ground station

ATSU



2.2. DATALINK MEDIA 2.2.1. AIR/GROUND DATALINK

2.2.1.1. VHF DATALINK

2.2.1.1.1. VDL mode A Data Link transmission over ACARS (so-called VDL mode A) has been used for years for AOC data purpose and for FANS A. 2.2.1.1.2. VDL-2 capability The VDL Mode 2 (VHF Data Link Mode 2) function provides improved air-ground VHF digital communications link. As the data link traffic over ACARS continues to increase, and congestion of the current ground networks is soon to be expected, the VDL-2 standard happens to be as a good interim solution. Waiting for the ATN development (for FANS B implementation), the VDL-2 is the only way to improve the current performance of data link applications, and to increase the capacity (which implies a reduction of communication charges by service providers). Compared to the current ATSU data link capabilities through the ACARS networks, the VDL-2 increases the rate of data transmission from 2.4Kbits per second to 31.5Kbits per second. 2.2.1.1.3. VDL-2 description VDL-2 is a communication protocol between the aircraft and VHF ground stations of the networks of service providers. Obviously, both the aircraft and the recipient (VHF station) must be equipped. With VDL-2, the ACARS messages are transmitted into packets of bits rather than in blocks of characters. This provides a gain in transmission efficiency. 2.2.1.1.4. VDL-2 over ACARS network VDL2 was originally designed to be used with an ATN router. As delays have been experienced in an ATN development and deployment on ground, and ACARS is soon to be congested, the VDL-2 function has first been adapted to the ACARS environment. This solution is known as the VDL-2/AOA (AOA: ACARS over AVLC: Aviation VHF Link Control). It is expected to cover the gap between the current ACARS system and the future ATN capabilities. Whenever referred to in this document, VDL-2 stands for VDL2/AOA.



2.2.1.2. SATCOM Until Satcom, radio-communications suffered from VHF line-of-sight limitations along with the unreliability and variable quality of HF. Satellite links overcome these weaknesses, being unaffected by distance or ionospheric conditions. Satcom are thus playing a major role in the implementation of ICAO’s CNS/ATM concept for Air Traffic Control in the 21st century, supporting both ADS and CPDLC applications over the oceans and wilderness areas. Whatever the applications (passenger services, airline operational communications or air traffic communications), the voice/data are transmitted via satellite, from the aircraft to the Ground Earth Stations (GES) and then switched through international telecommunications networks (ARINC, SITA, …) to anywhere in the world (airline hosts, ATC centres,…). Currently, only Inmarsat constellation is able to provide communication services (voice or data) to the whole globe, except to the extreme polar regions (above 80°N and below 80°S) with a bit rate up to 64kbps for Swift64 services. Note: MTSAT satellite is to be launched in early 2004 to provide communication services over Asia.

2.2.1.3. HF DATALINK (HFDL) HF Data Link (HFDL) has been certified only for an AOC purpose in April 2002, and should be certified for an ATC purpose in early 2004 with the FANS A+ package. HFDL allows data transmission at a rate of 1.8 Kbits per second. Today, ARINC is the only DSP providing HFDL. The proposed coverage is world-wide (refer to Appendix C). Operational trials have started in some parts of the world to demonstrate that HFDL could be used for ATC. Good results have so far been gathered. HFDL performance happens to be better than current HF voice. It is not as good as VDL or Satcom, but in some areas such as Polar regions where neither VDL nor Satcom are available, HFDL for ADS or CPDLC is expected to be used efficiently.



2.2.2. GROUND/GROUND DATALINK

2.2.2.1. THE DATA LINK COMMUNICATIONS NETWORKS Several communications service providers, in addition to the AOC messages, ensure today the routing of ATC messages between the aircraft and the ATC centre. These are growing steadily, thus raising some issues for future interoperability. Among the main ones the following may be listed: • INMARSAT: covers the space segment through its satellite constellation, which is

accessed by numerous GES operators (most of them being sub-contracted). • MTSAT: to be launched in early 2004, it will provides communication services aver

Asia. • ARINC: through its so-called ADNS network, ensures the SATCOM, VHF and HFDL

(High Frequency Data Link) air-ground processing through numerous GESs and RGSs.

• SITA: through its so-called AIRCOM system, ensures the SATCOM and VHF air-

ground processing through numerous GESs and RGSs. • AVICOM: this Japanese provider ensures a VHF air-ground processing within Japan • DATACOM: this Brazilian provider ensures a VHF air-ground processing within

Brazil region. Both ARINC and SITA networks operate with national service providers and are currently interconnected to provide a global interoperability of ATS data link applications. This means for instance, that an aircraft using a VHF data link under a SITA agreement can nevertheless operate in a FANS ATC area using an ARINC contract (refer to § 2.2.2.2). Given in Appendix D is general information relative to some of these service providers.

2.2.2.2. THE INTEROPERABILITY OF THE NETWORKS The interoperability between the Data Service Processors of the two main communications service providers (ARINC and SITA) is a key element in the overall performance of the system, and ensures that each relevant ATC centre has access to all FANS aircraft within its region. Whenever there is a switching for instance from VHF to Satcom (or vice versa), the ATSU sends a Medium Advisory (MA) message to the DSP indicating the status of the communications with each medium. Such an automatic function is needed to fulfil the logic that determines the routing of any uplink message. It is transparent to both the pilot and the controller and ensures that uplink messages can be sent to the aircraft irrespective of the medium or communications service providers used.



2.2.2.3. AIDC COMMUNICATIONS The ATS Inter-facility Data Communications (AIDC) defines the data link between ATC centres. This link is used for notification, co-ordination and phases for transfer of control. AIDC functions will be progressively introduced as ATC centres along routes and air spaces are equipped with CNS/ATM systems. This is not an aircraft issue.

2.2.2.4. FUTURE NETWORK With the current FANS A, the Air Traffic Services datalink is based on the ACARS network, which will not be able to handle the increasing volumes of AOC and ATC communications. Therefore, a network dedicated to aeronautical communications is being developed to act as a backbone of the ICAO’s CNS/ATM concept. This Aeronautical Telecommunication Network (ATN) will seamlessly connect aircraft, air traffic control centres, airline operations facilities and communication service providers with enhanced efficiency, capability and security.

Figure 2.2Network interoperability

ATC 1 ATC 2

ARINC Network SITA Network

Network Interoperability

Network Interoperability

ARINC communication domain SITA communication domain



2.3. CNS/ATM ATC APPLICATIONS 2.3.1. ATS FACILITY NOTIFICATION (AFN) Through this application, an ATC knows whether an aircraft is capable of using data link communications. This serves to exchange the address information between the aircraft and the ATC centre. This exchange of the data link context is needed prior to any CPDLC or ADS connection. The AFN log on is initiated by the pilot to notify the ATC of its data link capability and characteristics. Whenever there is no automatic transfer of control from one ATC centre to another, the active one may request the pilot to make a log on procedure to the next centre. 2.3.2. CONTROLLER PILOT DATA LINK COMMUNICATIONS (CPDLC) CPDLC is a powerful tool to sustain data link communications between a pilot and the controller of the relevant flight region. It is particularly adapted to such areas where voice communications are difficult (e.g. HF voice over oceans or remote part of the world), and is expected to become very convenient to alleviate congested VHF of some busy TMAs when utilised for routine dialogue (e.g. frequency transfer). CPDLC consists in the exchange of messages, which can be formed by the use of individual (or combination) elements chosen within a set of internationally agreed preformatted ATC ones. These elements are in agreement with the existing ICAO phraseology, and serve to exchange nominal clearances, requests, reports, negotiations or miscellaneous ATC information (e.g. emergency notifications, transfer of ATC centre or frequency). Appendix A lists all the messages (around 180) that are supported by FANS A and FANS A+ airborne and ground systems. Advantages and drawbacks of CPDLC have been discussed at length for some years. Among the main ones, CPDLC is a remedy to shortcomings of the existing systems: • significant reduction of the transmission time • suppression of the errors or misunderstandings pertaining to poor voice quality,

fading, language • suppression of mistakenly actions on ATC messages intended for another flight • suppression of the tiring listening watch of the radio traffic • possibility for an immediate access to previously recorded messages • automatic loading within the FMS of route or F-PLN clearances, thus avoiding

transcription errors, long and fastidious manual keystrokes. The following points however must be well understood and will have to be underlined in training: • handling of CPDLC messages requires time:

- reading and interpreting a written clearance was found to be less immediate than hearing the same one

- preparing and sending a request through the combination of the MCDU and DCDU is longer than directly using the mike.

• the party line is lost (the pilot can no longer listen to the surrounding transmissions)



2.3.3. AUTOMATIC DEPENDENT SURVEILLANCE (ADS) Through the ADS application, the ATSU automatically sends aircraft surveillance data to the connected ATC centres and/or to the airline host. FANS A equipped aircraft can have up to five ADS connections. One of the five connections is reserved for use of the AOC. The aircraft has the capability to report to four different ATC simultaneously using ADS. This is done automatically and remains transparent to the crew. These are air-ground downlink messages. Different types of ADS "contracts" exist:

• periodic: the data are sent at periodic time intervals • on demand: the data are sent only when asked for • on event: the data are sent whenever a specified event occurs (e.g. altitude or

heading change, vertical rate change, waypoint change) In the FANS A system, the ADS is based on these contracts, which are set by the ATC centres to satisfy their operational needs for surveillance, as dictated by circumstances (e.g. traffic density). The crew cannot modify these contracts, but the controller can. And so can he specify the parameters of the contract. Optional data groups may thus be added in the contract request. Obviously, at anyone ATC centre, only one contract may exist at any one time, and whenever a modification is asked by the controller, a new contract is set, which cancels the previous one. Another type of contract may be found: the emergency mode. When the crew activates this mode, the data are automatically sent at a high rate (every 64 seconds), independently of the previous contract. Appendix B lists the various elements and groups of data of the ADS messages, and provides some details on the different contracts. Based on these contracts, directly addressed between an ATC centre and a given aircraft, ADS is then usually called ADS-C (where C stands for Contract), or ADS-A (where A stands for Addressed). Both these designations are equivalent. In a future step, the aircraft are expected to have the capability to broadcast their positions and intents not only to the ground, but also to other aircraft in their vicinity. Trials of this ADS-B (B stands for Broadcast) have already started. Associated with Cockpit Display of Traffic Information (CDTI), ADS-B is intended to be an enabler to free flight concepts.



2.3.4. AEEC623 The AEEC623 specification defines the application text formats for character-oriented Air Traffic Services messages that can be transmitted over the ACARS data link. The main AEEC623 applications are the followings:

- D-ATIS (Digital – Automatic Terminal Information Service) - Oceanic Clearance (OCL) - Departure Clearance (DCL) - Terminal Weather Information for Pilots - Pushback Clearance - Taxi Clearance

These applications will enhanced the existing customised AOC applications as transaction messages will no more go through the airline host but directly from the ATC to the aircraft (via DSP). 2.4. PERFORMANCE REQUIREMENTS 2.4.1. GENERAL The requirements for operation in a specified airspace may be defined in terms of each of the three "C", "N" and "S" aspects. As such, the three concepts of Required Navigation Performance (RNP), Required Communications Performance (RCP) and Required Surveillance Performance (RSP) are all parts of a general CNS/ATM performance concept and are complementary. They all address the functionality and performance of the system for their relevant aspect and may be defined in terms of availability, accuracy and integrity. Each of these three performance requirements is independent of the technologies used to ensure either of the three Navigation, Communications or Surveillance functions. 2.4.2. REQUIRED NAVIGATION PERFORMANCE (RNP) FANS routes or air spaces are associated with a given RNP (Required Navigation Performance) value. This RNP is a statement on the navigation performance accuracy necessary for operation in this air space. The ATC centres define the RNP criteria to be fulfilled prior to the utilisation of their FANS routes. RNP 10 is the current requirement for oceanic FANS air spaces, however specific areas (e.g. Tasman sea) require RNP4 for 30/30 lateral and longitudinal separations. Each aircraft operating in RNP airspace shall have a total system navigation position error equal to, or less than, the RNP value for 95 % of the flight time. See Figure 2.3 illustrating the track error accuracy.



The RNP concept together with the FANS A navigation capabilities of the Airbus aircraft are fully described in the "Getting to grips with modern navigation" brochure.

Remark: over North Atlantic, MNPS airspace has been defined before the RNP concept. It is assumed that MNPS is equivalent to RNP11.

2.4.3. REQUIRED COMMUNICATION PERFORMANCE (RCP) The RCP concept defines the end to end communications performance which is required to operate in a specified airspace or under specified procedures of operation. It is determined by the relevant authorities for the considered area, taking account of various parameters such as targets level of safety, separation assurance criteria or functional hazard analysis. Human factors considerations are also taken into account to reflect the human performance to complete an exchange of communication by initiating a reply. The RCP is independent of the technology used and is applicable to both voice and data communications.

It is now commonly agreed upon that the prime parameter in assessing the technical performance of the communications, is the delay experienced by the exchange of data between the end users (e.g. pilot / controller). According to the latest work of the RTCA/EUROCAE groups, the following terms have been defined to characterise the RCP statement: • Delay: is a measure of the time required for an information element to transit

between two identifiable points. • Integrity: is expressed as the probability of an undetected system-induced failure of

message transmission (i.e. undetected message error, wrong address, lost message transmission).

• Availability: is the ratio of actual operating time to specified operating time.

When such a concept is endorsed by the relevant airworthiness authorities and is applicable to some CNS/ATM operations, it is intended that further details will be added in this chapter to help the airline in defining its operational context.

2.4.4. REQUIRED SURVEILLANCE PERFORMANCE (RSP) The RSP concept, at the time of this edition, is not mature enough to be described here. It is intended that further editions give here the expected level of information to help the airline in defining its operational criteria.

X (RNP value)

X

2X

2X

Containment

Containment

Accuracy limit

Accuracy limit

Desired Flight Path

Figure 2.3RNP concept



Please, bear in mind… Pending the new Aeronautical Telecommunication Network (ATN) availability for FANS B, the current FANS A step uses the ACARS network to exchange data between aircraft and ground systems. FANS A data link architecture

• The airborne part: the ATSU which manages all the communications andautomatically chooses the best available medium (e.g. VHF, Satcom and HF,in that order).

• The air/ground datalink: used to transmit AOC or ATC data to the ground through VDL modeA, VDL mode2, Satcom and HFDL.

• The ground/ground datalink: to ensure the connection to the ground partsthrough either satellites Ground Earth Stations (GES), VHF and HF RemoteGround Stations (RGS), air-ground processors (which route and handle themessages).

• DSP operating with national service providers are currently interconnected toprovide a global interoperability of ATS data link applications.

FANS A applications

• ATS Facility Notification (AFN) Through this application, an ATC knows whether an aircraft is capable of usingdata link communications. This exchange of the data link context is needed priorto any CPDLC or ADS connection.

• Controller Pilot Data Link Communications (CPDLC) CPDLC is a powerful tool to sustain data link communications between a pilot andthe controller of the relevant flight region. It is particularly adapted to such areas where voice communications are difficult(e.g. HF voice over oceans or remote part of the world), and is expected to become very convenient to alleviate congested VHF of some busy TMAs whenutilised for routine dialogue (e.g. frequency transfer).

• Automatic Dependent Surveillance (ADS) Through the ADS application, the ATSU automatically sends aircraft surveillance data to the connected ATC centres (up to 4). This is done automatically andremains transparent to the crew. Different types of ADS "contracts" exist: periodic, on demand and on event

• AEEC623 The AEEC623 specification defines the application text formats for character-oriented Air Traffic Services messages (e.g. departure or oceanic clearances),that can be transmitted over the ACARS data link.

Performance Requirements

The three concepts of Required Navigation Performance (RNP), Required Communications Performance (RCP) and Required Surveillance Performance (RSP) are all parts of a general CNS/ATM performance concept and independent of the technologies used.



3. AIM-FANS DESCRIPTION ....................................................................................38 3.1. Need for flexibility......................................................................................38 3.2. AIM-FANS architecture..............................................................................40

3.2.1. The ATSU..........................................................................................40 3.2.2. The new FMS (2nd generation FMS).................................................41 3.2.3. Crew interfaces..................................................................................42

3.3. Human Machine Interface .........................................................................42

3.3.1. Basic operational principles ...............................................................44 3.3.2. Main HMI rules...................................................................................44

3 – AIM-FANS DESCRIPTION


3. AIM-FANS DESCRIPTION

3.1. GENERAL: THE NEED FOR FLEXIBILITY Air spaces greatly vary from one part of the world to another: some are already congested (e.g. Europe region at some peak hours) whereas others are still relatively empty (e.g. Pacific Ocean). The requirements to change the way we operate in such different areas are not the same. Implementing the latest technologies, which are now available to support these awaited changes, cannot be done without the involvement of numerous parties. States, ATS, communications service providers are affected in the same way as airlines, airframers or avionics equipment manufacturers. That is why the CNS-ATM concept can only be developed regionally or even on a route by route basis. The Airbus forecast for future CNS-ATM implementation envisions three main phases: • On a short term basis, FANS A routings are being opened (e.g. Europe / Asia

through the Bay of Bengal, Europe / North America or Australia / South Africa in complement to the current operative Pacific area).

• On a mid term basis (2007- 2010), ICAO SARPS*-compliant ATN development

should allow FANS B to spread around the world, thus enabling a full-performance data link. Regions of low traffic density may plan to then leapfrog the FANS A step and go directly to FANS B. The potential economic benefits however, lie mainly in the high traffic density areas for which FANS B is designed.

• On a long term basis (starting around 2015), a generalisation of FANS B is expected, since the search for the best economic benefits and the tremendous increase of traffic should then lead to a world-wide generalisation of this concept. Other operational concepts and technologies, such as ADS-B, are expected to come into service.

The following figure summarises the Airbus implementation of CNS/ATM (four main steps leading to global implementation of ICAO standards). * : The SARPs are international “Standards And Recommended Practices” published by ICAO. National aeronautical regulations of countries member of ICAO shall comply with the content of these SARPS.



It is considered that FANS A, FANS B and non-FANS environments will co-exist for many years. The aircraft's ability to go seamlessly from one environment to another is a fundamental asset, which was one of the prime design objectives of the Airbus architecture. Further extensions to FANS B, such as free flight concepts (as described either in the NAS - US National Air Space - program or mentioned in the EATMS - European Air Traffic Management System - operational concept for instance), are also already considered: the provisional capacity for data broadcast operations (e.g. ADS-B) have been secured in the proposed system. Longer term philosophy aiming at defining whether or not and to which extent, the crew will be responsible for their own separation is beyond the scope of the aircraft manufacturers alone. As a conclusion to this brief overview of the implications of CNS-ATM we can say that the transition to this new way of operating requires both flexibility and growth capability. For the airplane, flexibility is the essential requirement:

• Flexibility to grow as the CNS-ATM concept evolves • Flexibility to adapt to inevitable unforeseen developments of the environment • Flexibility to operate in mixed ATC environments

But flexibility requires computer power. This was tackled right from the beginning with the AIM-FANS (Airbus Interoperable Modular -FANS) avionics package: indeed, the power and flexibility of a dedicated communications unit (the ATSU) combined with the power of a new FMS.

Figure 3.1 Airbus implementation of CNS/ATM

Four main steps leading to global implementation of ICAO standards

2015

Pre-FANS Airline Datalink C: AOC by ACARS N: Classical means S: Transponder ATM: Air Traffic Control procedures

Retain on-board ACARS functionality for AOC purpose

1998

FANS A Oceanic/Remote airspace - Low density C & S: ATC/AOC datalink over ACARS N: GPS-based ATM: Air Traffic Control Procedures enhancement

2000

2007

Ground accommodation of FANS A legacy systems

FANS B High Density airspace C: Over ATN S: Over ADS-B N: GNSS/RNP ATM: Air Traffic Control (enhanced procedures, starts transition towards Free Flight)

FANS B High and Low density airspace C & S: Over ATN and ADS-B N: Extended Satellite. Nav.-based (GNSS)/RNP ATM: Air Traffic Management using ICAO standards

Extension of FANSB to low density areas



3.2. AIM-FANS ARCHITECTURE The Airbus objectives in defining its system are:

• To adapt the aircraft to the various CNS-ATM environments • To cope with a moving FANS world • To minimise the burden of the airlines in their moving to CNS-ATM • To introduce a user-friendly Human Machine Interface for the data link • To ensure the Airbus family concept

The following figure shows the architecture used:

Figure 3.2

AIM-FANS architecture

3.2.1. THE ATSU This new avionics unit, called Air Traffic Services Unit (ATSU), has been developed to cope with data link communications. Its functions are: • To manage the HMI, the display and warning systems. It warns the crew of any up-

coming message, displays it, and also sends the appropriate data to the peripherals • To enable the access to all available communications media (current and future).

The selection of the media is made automatically and without any pilot action. • To sustain the communications tasks (e.g. selection of the appropriate ATC centre

for data link all along the flight). Part of this, is the management of all the messages (up/down link) whatever their types (ATC clearance, ADS, pilot requests, AOC, flight information). Today's ACARS functions are included in the ATSU. There is no longer a need for an ACARS management unit.



In the frame of FANS A and B, only one ATSU is used. But for later steps, two ATSUs can be installed, dealing with all the expected evolutions, as aircraft operation and safety become more dependent on data link communications. Furthermore, to answer the airlines' expectations, Airbus has committed to be responsible for the responsiveness and quality of their entire FANS system. Just like the Flight Warning System for example, the ATSU becomes an essential equipment for the flight safety, and thus must be controlled accordingly throughout its design realisation and implementation on board. The ATSU is a hosting platform, which has been designed so as to take provision of all foreseen evolutions. This modularity concept for both software and hardware permits to ease a quick and dependable introduction of all the ATC data link capability during the transition to the ultimate full FANS. The following figure depicts the modularity concept of the ATSU.

Figure 3.3

3.2.2. THE NEW FMS (2ND GENERATION FMS) An overall description of the new FMS functions can be found in the FCOM volume 4 (FMGS Pilot's guide). The following chapter describes the role of the FMS within the FANS A operations. The FMS is a key element of the AIM-FANS system for which it ensures three main functions:

• it provides data to the ATSU • it monitors the ATC messages and their subsequent implications • it handles and processes some of the ATC messages



The FMS can first be seen as a data provider for both ADS and CPDLC messages. As such, it periodically sends all the ADS parameters, whether for the basic group (position, altitude, cross track...), the predicted route frame or the intent group. The predicted position, altitude, speed or sequencing time for up to the next 2 waypoints of the flight plan are thus sent by the FMS to the ADS application of the ATSU. Position reports messages whether for manual CPDLC messages or for automatic ADS are processed by the FMS. The FMS monitors the ATC conditional or deferred clearances that are linked to the navigation (e.g. "AT ALCOA CLIMB TO AND MAINTAIN FL 350"). It triggers the signal to warn the pilot of the completion of the clearance. Whenever confirmation messages are received (e.g. "CONFIRM ASSIGNED SPEED") it automatically proposes the answer to the pilot. This is true for both current data (e.g. altitude, speed, route...) or target data (e.g. altitude, speed, heading...) Route requests or route clearances are processed by the FMS. Once prepared in the secondary F-PLN, a route request is sent by the FMS to the ATSU/DCDU prior to being sent. Similarly, once a route clearance (or a re-route proposed by the AOC) is received, it is loaded into the FMS, which acknowledges or rejects this new routing. The reasons for a rejection (for instance proposed waypoint not in database) are indicated to the pilots so that they can solve the issue. Co-ordination and exchange of F-PLN between ATC, AOC and the aircraft is processed with the FMS. 3.2.3. CREW INTERFACES The main crew interface used for the FANS applications is based on the two Data Communications Display Unit (DCDU), which are LCD screens dedicated to the ATC data link messages. All ATC messages, whether clearances (uplink message), requests or answers (downlink messages) are displayed on the DCDU. The two DCDUs are located in the main deck, just above each MCDU. The retained principles for an operational use of the DCDU are described in the following chapter. In addition to the DCDU, the MCDU is mainly used to prepare a request. Any ATC message can also be printed on the printer, at any time. 3.3. HUMAN MACHINE INTERFACE The following figure gives a general view of the cockpit with the main elements of the interface. The Human Factors considerations were particularly addressed all along the development of this interface. From the initial capture of the operational needs at the very beginning of the design phase, to the operational flight test evaluation and certification, numerous pilots from various origins such as flight test, training instructors and airline pilots, were involved in the definition of this interface. The whole Human Factors plan, as defined and presented to the airworthiness authorities, was also applied.



Figure 3.4 FANS HMI

The retained interface, with the two DCDUs in the core part of the cockpit, provides for a minimum perturbation of the existing procedures. This allows for a simple reversion to backup voice-based procedures when needed. Colour coding and/or reverse video on the DCDU have been used to differentiate between titles, text, main parameters in the text, uplink or downlink messages. The DCDU provides for full time accessibility and readability for both crew, which requires only limited head-down time.



3.3.1. BASIC OPERATIONAL PRINCIPLES

The flight crew is alerted to an incoming message by means of a flashing blue "ATC MSG" light in two pushbuttons on the glareshield (i.e. visual), as well as by a dedicated audio sound. The alert is stopped by pressing one of these two pushbuttons or by answering the message, directly on the DCDU. For normal messages the buttons flash, and the audio signal is repeated about every 15 seconds (with the first signal delayed by 15 seconds, so as not to multiply audio warnings). The message will appear on the DCDU if the screen is empty. If the screen is not empty, a flashing cue (e.g. "MSG 1/2") reminds the crew of the arrival of the message. For urgent messages the buttons flash, the audio signal is repeated about every 5 seconds, and the message is displayed on the DCDU regardless of the state of the screen.

Note: The audio sound is similar to a old telephone sound. It was elected by a great majority of the consulted pilots.

To reply to a message, the flight crew either uses the standard replies on the DCDU or composes a reply on a menu-page from the MCDU. After composing the message on the MCDU it is transferred to the DCDU for sending (refer to scenarios in Appendix G, H and I).

3.3.2. MAIN HMI RULES The following lists the main principles retained for the HMI:

a) DCDU • The two DCDUs are the compulsory data link communications focal point for either

type of messages (up or down link).

• It is recommended to keep both DCDUs without anything displayed. This, to allow for an immediate display of a new message. Consequently, it will be recommended to clean up the screens whenever a message has been completely treated and does no longer require to be displayed.

• Both DCDUs are identical, are interconnected and have the same displays. Any operation on either DCDU is valid for both of them.

ATC Centre Identification and message

time

Message Slew key

Function keys

Function keys

Information Field

Page Slew key

Print key

Current message

Message Status

Brightness key

Figure 3.5 : DCDU HMI



b) MCDU • The MCDUs are also part of the ATS data link system. They are used to prepare the

request type of messages or free text messages. They also provide for an access to the file of the stored messages.

• The "ATC COMM" key of the MCDU gives access to the various pages of the ATS

data link system

c) Alert • The alert function is triggered each time a new uplink message arrives or whenever

a deferred report or clearance expires. • Both the "ATC MSG" pushbuttons on the glareshield are lighted and flash until a

positive action of the crew (either by pressing one of the pushbuttons or by answering the uplinked message on the DCDU) is done to stop the alert.

• The specific ATC audio sound may also be activated (15 sec delay)

d) Messages • As soon as the alert is triggered, the associated ATC message may be accessed

and viewed on both DCDUs. It is automatically displayed (whether the screens of the DCDUs are free or not) if it is an "urgent" or "distress" message.

• Request messages can be brought to the DCDU as soon as the crew has activated

the corresponding command ("ATC REQ DISPL"). • Pending messages can be brought (one at a time) to the DCDU by the crew who

can review them in the order they want. • The crew can (and is recommended to do so) clean up the DCDU through a specific

function key ("CLOSE") once the displayed message has been entirely treated.

e) Printer • A print function is available on the DCDU to print the currently displayed message in

whole. This can be done at any time. • It is recommended to print long messages (e.g. F-PLN clearance) or reports.

f) FMS/DCDU interface • An ATC F-PLN can be loaded in the secondary F-PLN of the FMS. This is done

through the "LOAD" key of the DCDU. The crew is kept aware of the result of this loading by an indication located on the DCDU (e.g. "LOAD OK", or "LOAD PARTIAL"). Whenever this loading cannot be done entirely (for instance waypoint not in data base, runway/ILS mismatch,..) the pilots can access the MCDU secondary F-PLN pages to assess the reasons for the rejected parameters, and take appropriate actions.



• ATC messages requiring navigation parameters (e.g. "Confirm speed") are

processed by the FMS. An answering message is automatically proposed on the DCDU with the FMS value. The crew can nevertheless modify this message before being sent.

• A monitoring process is launched by the FMS whenever "Report" messages are

received (e.g. "Report Passing..."). The message is automatically recalled and the answer is proposed on the DCDU, once it is time to report.

• A monitoring process is launched by the FMS whenever deferred or conditional

clearances (e.g. "AT ALCOA CLB TO FL350") are received. 30 seconds before it expires, the message is triggered again to remind the crew of this clearance.

g) ADS • ADS reports are automatically sent to the ground without any possibility for the crew

to either see or modify them. • A CPDLC emergency message (e.g. "MAY DAY") automatically activates the ADS

emergency mode.

h) Colour coding The following colour coding philosophy is used for the DCDU: • The title is always displayed in GREEN. • Uplink messages are displayed with the text in WHITE and the main parameters are

highlighted in CYAN • Closed actions are always in GREEN • Configuration or failure requiring awareness but not immediate action are displayed

in AMBER • NORMAL VIDEO is used for uplink • REVERSE VIDEO is used for downlink



i) Miscellaneous

• A star. “ * ” in front of a LSK means the key is activated. • New messages coming from the controller are displayed immediately if they are

‘Distress’ or ‘Emergency’ or if the message file is empty. Else they are filed and can be displayed through dedicated flight crew actions (MSG keys of the DCDUs). The flight crew can process (i.e. answer or send) the filed message in any order.

The message access principle is based on the following figure:

Figure 3.6 Messages and pages management

Any next or previous page for a currently displayed message can be accessed through a press on DCDU commands ‘PGE+’ and ‘PGE-’. Any next or previous message of the file can be accessed though a press on DCDU commands ‘MSG+’ and ‘MSG-’. Note: Several scenarios are provided in Appendix G, H and I to develop the handling of both DCDU and MCDU

MSG 1/4 MSG 2/4

MSG 3/4 MSG 4/4

PGE 2/3

PGE 3/3

PGE 1/3

MSG-

MSG+

PGE-

PGE+



Please, bear in mind… The transition to CNS/ATM requires both flexibility and growth capability. For theairplane, flexibility is the essential requirement, but requires computer power. This was tackled right from the beginning with the AIM-FANS avionics package: indeed, the power and flexibility of a dedicated communications unit (the ATSU)combined with the power of a new FMS. AIM-FANS Avionics

• This new avionics unit (ATSU) has been developed to cope with data link

communications. Its functions are: - To manage the HMI, the display and warning systems. - To enable the access to all available communications media. - To sustain the communications tasks.

• The FMS is a key element of the AIM-FANS system for which :

- It provides data to the ATSU - It monitors the ATC messages and their subsequent implications - It handles and processes some of the ATC messages

Crew Interface

• The main crew interface used for the FANS applications is based on the two

DCDUs. All ATC messages, clearances (uplink message), requests oranswers (downlink messages) are displayed on the DCDU. In addition to the DCDU, the MCDU is mainly used to prepare a request.


4. OPERATIONAL PROCEDURES ...........................................................................50 4.1. Introduction................................................................................................50 4.2. Pre-flight phase..........................................................................................50 4.3. ATS Facilities Notification (AFN) ..............................................................51 4.4. CPDLC procedures ....................................................................................55

4.4.1. CPDLC connection ............................................................................55 4.4.2. CPDLC Connection transfer ..............................................................56 4.4.3. End of service ....................................................................................59 4.4.4. Failures of the CPDLC connection.....................................................60 4.4.5. CPDLC shutdown ..............................................................................60 4.4.6. Abnormal cases at the time of transfer of connection ........................61 4.4.7. Recommendations for exchange of CPDLC messages.....................61

4.5. ADS procedures.........................................................................................68

4.5.1. ATS notification and ADS connection ................................................68 4.5.2. ADS connections management .........................................................71 4.5.3. Position reporting with ADS ...............................................................72 4.5.4. ADS connections closure...................................................................72 4.5.5. Route offset .......................................................................................73 4.5.6. ADS shutdown ...................................................................................73 4.5.7. Emergency procedures......................................................................73

4.6. ATS623 applications..................................................................................74

4 – OPERATIONAL PROCEDURES

Flight Operations Support & Line Assistance Getting to grips with FANS – Ref STL 945.7011/03

50

4. OPERATIONAL PROCEDURES

4.1. INTRODUCTION The following chapter depicts some important and general procedures for an operational use of CNS/ATM systems. As already explained FANS routes are, and will be, regionally opened, based on the availability of ground equipment and technologies. Operational procedures are defined for each area and published in “Operations Manuals” such as POM (Pacific Operations Manual) or IOOM (Indian Ocean Operations Manual). The here-below recommendations are based on these manuals. 4.2. PRE-FLIGHT PHASE As for any flight, it is the commander's responsibility to ensure that crew FANS training qualifications, aircraft and operational approval are satisfied for the intended flight (refer to §7.4.3). • ICAO F-PLN filing The CNS/ATM capabilities of the aircraft will be notified when filing in the ICAO flight plan. A letter code has been defined for this information. The data link capability is notified by a letter "J" to be entered in the field 10 (Equipment). The letter "D" is also entered in the surveillance part of that field, if ADS is available. The other capabilities are given in the field 18 (Other Information) under the DAT/ information.

10 - EQUIPMENT J / D

18 - OTHER INFORMATION DAT / S V In this example, the data link is ensured by both Satellite and VHF, and ADS is available. The following code is used:

- S...........Satellite data link - H...........HF data link - V...........VHF data link - M...........SSR Mode S data link



If RNP is expected, field 18 will also mention: NAV/RNP. (Refer to “Getting to grips with modern navigation” brochure). The aircraft registration is also to be notified in the Field 18. This will be used for correlation purposes by the ATC through a comparison of it with the one contained in the AFN logon (see here-after). • Pre-flight checks Prior to departing for a FANS flight, the crew will check that the required equipment is operative. The following items are recommended to be included in those checks:

- GPS availability - UTC time settings - RNP capability - Data link communications availability (e.g. Satcom logged) - Flight Id. (on the MCDU “COMM INIT“ page) - Airlines’ priority list of contracted DSP for FANS operations with this aircraft (refer

to §7.3.1). If the data link is to be used a short time after the departure, the ATS Facilities Notification (AFN) function (described here after) will have to be completed prior to take off. As a general rule, it is worth noting that the AFN should be completed 30 to 45 minutes before entering the CPDLC/ADS air space.

4.3. ATS FACILITIES NOTIFICATION (AFN) • Why such a function? The aim of the ATS Facilities Notification is to tell (to notify) an ATC centre that your aircraft is able to sustain digital communications and that you are ready to connect. It is thus two folds:

- To inform the appropriate ATC centre of the capabilities and specifics of the aircraft data link communications (e.g. CPDLC and/or ADS available applications, ACARS address)

- To give the ATC centre the flight identification and aircraft registration number to allow for a correlation with the filed flight plan.

The AFN must be successfully completed prior to any connection is being established. The AFN can be initiated:

- Manually by the pilot (e.g. the first notification which is always manual); or - Automatically by an ATC using the address forwarding process transparent to the

crew (refer to §4.4.2). In case this process fails, a manual connection should be done.

The table below emphasises the ways to initiate an AFN depending on the services provided by the “Current Data Authority” (FROM) and the “Next Data Authority” (TO).

TOFROM

CPDLC only Automatically Automatically Automatically

ADS only Manually Manually Manually

CPDLC & ADS Automatically Automatically Automatically

CPDLC only ADS only CPDLC & ADS



• Manual AFN When no other CPDLC or ADS connections have been established with a previous ATC centre, the AFN must be exercised (e.g. prior to departure, prior to entering a data link airspace, or following a failure to re-initiate a connection) To this end, the pilot sends a first AFN CONTACT message (FN_CON). This is done through the NOTIFICATION page of the ATC pages on the MCDU, when the crew enters the ICAO 4 letter code of the ATC centre and the automatic exchange of messages between the ground and the aircraft is correctly done. The ATC centre replies to the FN_CON by an AFN ACKNOWLEDGE (FN_ACK). This can be monitored on the NOTIFICATION pages where the sequence "NOTIFYING", "NOTIFIED" is displayed. (See picture 4.1). This AFN procedure is more or less transparent to the crew, but must be understood. Remark: Pending the appropriate FANS stations installation in the next coming year in both Nav Canada (Gander Oceanic) and UK NATS (Shanwick Oceanic), ADS is not true ADS. The connection is NOT done with either of these centres, but to the ARINC Central ADS (CADS) computer in Annapolis, which then transforms the received ADS reports into position reports as if received by the aeradio operators and then transmitted to the controllers via AFTN (Aero Fixed Telecom Network). So, although the "logon" is apparently performed to the Gander or Shanwick centres (when the crew type the 4-letter address on the NOTIFICATION page) it is indeed connected to the CADS. ADS, or pseudo ADS, is however not a CPDLC. There is no connection between a controller and the aircraft. The original goal of ADS was to reduce horizontal separation, and as such ADS is transparent to the crew: this choice of design has been done because ADS is a surveillance tool, to be used in conjunction with communications media (CPDLC).


Manual Notification

MCDU

MCDU

The pilot sends an AFN CONTACT message to the appropriate ATCthrough the NOTIFICATION page of the MCDU (selecting “NOTIFY” LineSelect Key). When the ATC centre receives the “AFN Contact” message, it replies byan “AFN Acknowledge”. When this acknowledgement is received on board, "NOTIFIED" is displayed on the NOTIFICATION page. This meansthe ATC has been correctly informed of the aircraft’ datalink capabilities. This AFN procedure is more or less transparent to the crew, but must be understood.

Figure 4.1




Please, bear in mind…

Pre-flight phase

ICAO F-PLN filing The CNS/ATM capabilities of the aircraft will be notified when filing in the ICAO flight plan.

• The data link capability is notified by a letter "J" to be entered in the field 10.• The letter "D" is also entered in the surveillance part of that field, if ADS is

available. • The other capabilities are given in the field 18 (Other Information) under the

DAT/ information. The following code is used: S (Satellite data link), H (HFDL), V (VHF data link), M (SSR Mode S data link)

Pre-flight checks Prior to departing for a FANS flight, the crew will check that the required equipment is operative. The following items are recommended to be included in those checks:

- GPS availability - UTC time settings - RNP capability - Data link communications availability - Flight Id. (on the MCDU “COMM INIT“ page) - Airlines’ priority list of contracted DSP for FANS operations with this

aircraft

ATS Facilities Notification (AFN) The aim of the ATS Facilities Notification is to:

- notify the appropriate ATC centre of the capabilities and specifics of theaircraft data link communication applications

- give the flight identification and the aircraft registration number When no other CPDLC or ADS connections have been established with a previousATC centre, the AFN must be exercised (e.g. prior to departure, prior to entering adata link airspace). The AFN can be initiated:

- manually by the pilot, or - automatically by the ATSU using the address forwarding process.

The AFN must be successfully completed prior to any connection is being established.



4.4. CPDLC PROCEDURES 4.4.1. CPDLC CONNECTION Once the AFN has been successfully done (“ATC NOTIFIED” on the MCDU Notification page), the ATC centre can initiate a CPDLC connection. Here also, an exchange of two messages (CONNECTION REQUEST and CONNECTION CONFIRM) occurs between the ground and the aircraft to initiate the connection. But this is transparent to the crew. Checks are automatically done by the ATSU to validate or reject the connection:

- Connection is accepted if no previous connection already exists - Connection is accepted if it is relative to the next data link ATC to control the aircraft - Connection is rejected in all other cases

Note: The “Active ATC” line on the MCDU is dedicated to CPDLC connection status.

When CPDLC connection has been established, the active ATC isindicated on both DCDU and MCDU

MCDU

DCDU

Figure 4.2CPDLC connection



4.4.2. CPDLC CONNECTION TRANSFER

4.4.2.1. NOTIFICATION OF TRANSFER TO THE NEXT ATC The three following paragraphs describe a thorough explanation of the retained mechanisation. - The active data link ATC is usually called the Data Authority. - The next data link ATC is usually called the Next Data Authority (NDA). • Nominal case To inform the aircraft avionics (i.e. ATSU box) that a transfer of control will be done, the current active ATC sends a so-called NDA message to the aircraft. This is the only way for the ATSU to be aware of and to accept the connection with the next ATC centre. Once a NDA message has been received, the aircraft is waiting for the connection with the next ATC centre.

Figure 4.3 Notification of transfer to the next ATC

MCDU

DCDU



• Abnormal cases If the aircraft NDA message has not been received at the time when the next ATC centre tries to connect, this connection attempt is rejected. This is transparent to the crew. Whenever the controller of the transferring ATC knows the NDA message has not been delivered, he will ask the crew for a manual AFN with the next centre. Either voice or CPDLC can be used for this. The following phraseology is recommended: - Controller: " Contact (ATCXXXX). Frequency YYYYY. Select ATC com off then

logon to ATCXXXX " - Pilot: "WILCO".

4.4.2.2. TRANSFER TO THE NEXT ATC Transfer from one Data Authority to the next one is usually done automatically and remains transparent to the crew. The following explanations are nevertheless given for a better understanding of the failure cases and their associated procedures. The automatic transfer to the next ATC is made through a so-called “Address Forwarding Process”. The aim of the address forwarding is to forward the address of the next ATC to the aircraft avionics. • Automated procedures for an automatic transfer The following sequence of message exchange should be initiated by the first ATC around 30 minutes prior to the estimated time at the FIR boundary. The crew is unaware of this exchange. - The first ATC sends an AFN Contact Advisory message to the aircraft - The aircraft acknowledges this message and sends an AFN contact message to the

next ATC - This second ATC acknowledges the demand through an FN_ ACK message - The aircraft sends an AFN Complete (FN_COMP) message to the first ATC, to

inform it of the completion of the AFN



Figure 4.4 Transfer to the next ATC

• Abnormal cases Whenever the previous exchanges are not successful, a manual connection is to be done. The controller of the first ATC will ask the crew to manually send an AFN logon to the next ATC as explained in the previous paragraph (§4.4.2.1).

MCDU

DCDU



4.4.3. END OF SERVICE

A CPDLC connection with one ATC centre is usually terminated once this centre has sent an "END SERVICE" message to the aircraft. This message is sent once all the preparatory messages for the automatic transfer (as described in the §4.4.2) have been exchanged. It is sent just prior to the FIR boundary. The disconnection is made automatically and does not require any pilot action. Upon receipt of this message the ATSU:

- Sends down a "DISCONNECT" message and physically disconnects from the first ATC centre

- Activates the pending connection to the next ATC centre. If the next ATC centre has not been connected to the aircraft at the time the "END SERVICE" message is received, the aircraft is left without any connection. There are two cases in which the avionics will terminate established connections.

- When any uplink messages remain open when the aircraft receives an END SERVICE message,

- When the END SERVICE element is part of a multi-element message where none of the elements require a WILCO response.

In both cases an error message will be generated to both ATS systems and a deconnection with both ATC will occur. If any downlink message remains open when the aircraft receives an END SERVICE message, the avionics will close the message and terminate the CPDLC connection with the current ATC. This will not affect the CPDLC connection with the next ATC. Aircraft entering VHF coverage For aircraft entering airspace where radar and air-ground VHF are provided, and the aircraft will not cross a FIR boundary, it is not necessary to send an END SERVICE message to disconnect CPDLC. In this case, the CPDLC connection will remain active until termination of flight. If subsequent control sector within the FIR does not have CPDLC capability, and local instructions do not exist telling the contrary, the controller with jurisdiction for CPDLC must ensure that CPDLC clearances or instructions are not issued to the aircraft while it is under the control of another sector.



4.4.4. FAILURES OF THE CPDLC CONNECTION As soon as a failure of the CPDLC connection is noticed by either of the flight crew member or ground controller, voice will be used to inform the other part of the failure and to co-ordinate further actions. Once a connection has been lost, a complete LOGON procedure (AFN + Connection) must re-apply. The following procedures are recommended: • Failure detected by the controller

- The controller, through a voice system, tells the crew to switch off his data link system, and to reinitialise it.

- The crew access to the MCDU ATC pages and reinitialises the connection through the complete AFN from the NOTIFICATION pages.

• Failure detected by the aircraft

- The pilot, through voice, notifies the controller of the problem. - He restarts the CPDLC connection through the complete AFN from the

NOTIFICATION pages 4.4.5. CPDLC SHUTDOWN The following procedures should be followed whenever a shutdown occurs: • Planned shutdown:

- It should be notified through NOTAM, Voice is to be used • Unplanned shutdown, notified by the ground:

- The controller, through voice, informs the crews of the shutdown using the following phraseology: "CPDLC shutdown. Select ATC Com Off. Continue on voice"

- The pilot acknowledges: "Select ATC com off. Continue on voice" - The pilot continues on voice until further ATC notification.

• Unplanned shutdown, notified by the crew:

- The crew notifies the controller of the shutdown through the voice phraseology: "CPDLC shutdown. Select ATC com off. Continue on voice"

- The controller acknowledges: " Roger. Continue on voice". In all the three above cases, ATC / AOC co-ordination is recommended. • CPDLC Resumption Once CPDLC can be resumed, the following voice phraseology applies:

- The controller, through voice, announces: "CPDLC operational. Logon to (ATC XXXX)

- The pilot answers: "Logon to XXXX"



4.4.6.ABNORMAL CASES AT THE TIME OF TRANSFER OF CONNECTION

• Non delivery of the END SERVICE Whenever the controller is aware that the "END SERVICE" message has not been successful, he will tell (by voice) the crew to manually disconnect. Voice will be used until the connection with the next ATC has been done. The recommended voice phraseology is:

- Controller: "Select ATC Com Off then logon to ATCXXXX" - Pilot: "Select ATC Com Off then logon to ATCXXXX"

• Automatic connection transfer not successful Before crossing the boundary of the second data link ATC centre, the crew should have checked that the connection is well established with this ATC. Whenever the crew is aware that the connection with the first ATC centre is not terminated (e.g. at the time when a first position report to the next ATC) he should follow the recommended procedure:

- Advise the first ATC of the situation by voice - Manual disconnect from the current ATC - Logon to the next ATC - Send a CPDLC position report at the FIR boundary to the second ATC

4.4.7.RECOMMENDATIONS FOR EXCHANGE OF CPDLC MESSAGES This chapter depicts the various operational points for a proper understanding and use of the CPDLC system. It also provides for recommendations directly based on the lessons learned in the South Pacific operations. A list of all the up and down link messages supported by the CPDLC system is given in Appendix A.

4.4.7.1. TO BE KNOWN Pending for the ATN, as long as the FANS A ACARS based protocols exist, both pilot and controllers cannot know whether a message has been delivered to their right counterpart. However, the following is worth noting:

- Whenever the controller sends a message to an aircraft, a message assurance is triggered to indicate the controller that his message has reached the right aircraft (but this does not mean the message has been displayed and read by the pilot

- Whenever the crew sends a message to a controller, the "SENDING" then "SENT" indications displayed on the DCDU, indicates that the message has been delivered to the network. This does not mean the message has been displayed and read by the relevant controller.

Should any doubt or problem occur when dialoguing through CPDLC, voice should be resumed.



4.4.7.2. USE AND CONTEXT OF MESSAGES • Usual answers Most of the clearances can be directly answered through appropriate answer keys on the DCDU. According to the recommended international rules, the 5 following closure responses may be used as appropriate: WILCO, ROGER, AFFIRM, UNABLE, NEGATIVE. It is then important that the crew is fully aware of the right meaning and implications of these answers. The following lists the recognised statements for these response elements: - WILCO: This down link message tells the controller that the pilot will comply fully with the clearance/instruction contained in the associated up link message - UNABLE: Through this either up or down link message the pilot or the controller informs/is informed that the request(s) contained in the associated message cannot be complied with - STANDBY: Through this either up or down link message the pilot or the controller is informed that the request is being assessed and there will be a short term delay (within 10 minutes). The exchange is not closed and the request will be answered when conditions allow. - ROGER: Through this either up or down link message the pilot or the controller informs/is informed that the content of the associated message has been received and understood. ROGER is the only correct response to any up link free text message. ROGER shall not be used instead of AFFIRM. - AFFIRM: Whether up or down link, AFFIRM means YES and is an appropriate response to up linked message of negotiation request (e.g. "CAN YOU ACCEPT FL 350 AT ALCOA?"). - NEGATIVE: Whether up or down link, NEGATIVE means NO and is an appropriate response to up linked message of negotiation request (e.g. "CAN YOU ACCEPT FL 350 AT ALCOA?"). • Meaning of other messages - DISREGARD: This up link message means that the previous up link shall be ignored. DISREGARD should not refer to an instruction or clearance. Another element shall be added to clarify which message is to be disregarded. - CONFIRM: The present parameter (e.g. position, altitude, speed...) is awaited by the controller whenever CONFIRM XXXX is used. The DCDU will automatically propose to the crew the current FMS target linked to the considered parameter. Sending this answer is done directly on the DCDU. Should the crew be not satisfied with the proposed answer, he then could modify before sending. - CONFIRM ASSIGNED: The currently assigned parameter (e.g. altitude, speed, route) is awaited by the controller whenever CONFIRM ASSIGNED XXXX is used.



4.4.7.3. EXPECTED DELAYS IN RESPONDING TO CPDLC MESSAGES Delays depend upon numerous varying factors and happen to be more or less random and unpredictable. Waiting for a better consolidation of the three availability, integrity and accuracy elements as expected with the ATN, the current FANS A performance requirements have been given for the South Pacific operations:

- Down link: An end-to-end transit delay of 60 seconds or less for 95% of delivered messages. Transit being measured as the difference in the timestamp of the ground controller station and that of the sending action of the pilot.

- Up link: A 120 second round trip delay on 95%. Round trip being obtained by

comparing the time the up link is sent from the controller system against the time the message assurance (indicating successful delivery) was received back to the ground controller station. To be noted that a 6 minute round trip delay is also aimed at on 99%.

As an order of magnitude both controller and pilot should consider that it takes up to one minute for a message to be received, around 30 seconds for the pilot or controller to take action and respond and up to one other minute for the reply to be received. STANDBY answers assume that a further response should come within the next 10 minutes. The message thus remains open. If the controller does not respond within this time the pilot shall send an inquiry. In no case should a duplicate message be sent (this would cause failure of the system).

4.4.7.4. RECOMMENDED ANSWERS TO REQUEST AND CLEARANCES • Affirmative answer to a clearance WILCO is to be used. Pilot will then fully comply with the clearance or instruction • Affirmative answer to a negotiation request AFFIRM is to be used whenever an up linked negotiation request is approved (e.g. "CAN YOU ACCEPT FL 350 AT 1030Z") • Negative answer to a negotiation request NEGATIVE is to be used whenever an up linked negotiation request is not approved (e.g. "CAN YOU ACCEPT FL 350 AT 1030Z")



4.4.7.5. POSITION REPORT • General recommendations

- Only compulsory reporting points (unless requested otherwise by ATC) shall be reported by either voice, CPDLC or ADS for the "POSITION" and "NEXT POSITION". In particular, when ADS is used, only ATC reporting points will be entered in the FMS F-PLN. This will avoid that reports are triggered immediately and at unknown fixes.

- Whenever ADS is not used, CPDLC position reporting will be done once the

waypoint is passed over (or abeam when an offset is in progress). Use of the POSITION REPORT message (as given on the MCDU ATC pages) is expected.

- The first CPDLC position report is expected to be sent:

. after the completion of the initial connection, or

. after the transfer of connection from one centre to the next one, or

. when crossing the FIR boundary - Updating the estimate for a given waypoint should be done through a free text

message in the form of e.g. "REVISED ETA ALCOA 1034" - Whenever a position report is not received by the ground, the controller may ask

for it through the CPDLC up link: "REQUEST POSITION REPORT" - The use of the automatic position report capability should be preferred to manual

position report where CPDLC position reporting is needed. • Sequencing Abeam waypoints The FMS does not sequence the active waypoint when the aircraft is abeam this point by more than 7 NM. In this case, the waypoint is not sequenced on the CPDLC report message. It is thus recommended to use the offset function of the FMS so as to send true position reports. Once again, and specially in RNP or FANS route, updating the flight plan is highly recommended. • ARINC 424 Waypoints Since FANS A is operated, some issues have been highlighted concerning Waypoints Position Reporting (WPR) to ATC centres when encoded in ARINC 424 (format used to code FMS Navigation Database, but not recognised by ground systems). The problem is that waypoints that use ARINC 424 encoding scheme, which allows latitude and longitude to be encoded in 5 characters (e.g. 7560N for N75W060), are not interpreted properly by some ground systems, which try to decode them as latitude and longitude and may end up with something completely different. The issue is limited to ATC communication (CPDLC) for reporting Ident Waypoint coded in Arinc424. ADS does not use identifiers, but reports all lat./long waypoints, including the Reported Waypoint (in the Basic group) or a Waypoint Change Event report, Next and Next+1 waypoints (in the Predicted Route Group), as well as all those that force track, speed or altitude changes and are reported as “ADS Intent points”.



Many ATC centres cannot accept position reports containing latitude and longitude (Lat./Long) in ARINC 424 format (e.g. 4050N). Position reports containing Lat./Long waypoints within these areas will be accepted in whole latitude and longitude format only. Flights unable to send position reports in whole latitude and longitude format must accomplish position reporting via HF voice.

4.4.7.6. MULTI-ELEMENT MESSAGES - It is highly recommended to avoid potential ambiguity, that the crews do not send

multiple clearance requests in a single message. - Pilots should send one message per clearance element.

4.4.7.7. DUPLICATE MESSAGES • General

- As a general rule, duplicate messages, which can cause potential ambiguity, should be carefully avoided.

- To avoid the risk of duplicate messages, incoming request messages shall be answered as soon as possible

• Re-sending of a message

After a reasonable period without answer to his request, the crew may elect to re-send a message. In that case, he should do this in the form of a query, not a duplicate of the first request. In the case for instance where the initial request was "REQUEST CLIMB TO FL 350", the second attempt should be "WHEN CAN WE EXPECT FL 350".

4.4.7.8. USE OF FREE TEXT Free text messages cannot be treated by the automated station of the controller as standard ATC messages. As such, no correlation between the free text and its answer can be provided. Automatic pre-formatted answers cannot be provided in response to a free text. This thus increases the controller workload, the response time and the risk of input errors.

- Free text messages should be avoided as much as possible. - Use of free text is to be considered only when the pre-formatted messages do

not allow for a specific message element. - Standard ATC phraseology should be used in free text and abbreviations should

be avoided. Remark: "Standardised free text" messages have been developed and agreed upon by the main FANS actors of the South Pacific area, to cope with the lack of pre-formatted functions.



4.4.7.9. MESSAGE CLOSURE Among the basic assumptions and rules which have presided to the design of the CPDLC system, the closure of a message is one of the most important to be known by the crews. Open messages are prone to potential ambiguity and system issues. They should be avoided as far as possible. Pilots should be prompt to answer the received messages and to clean up their DCDU with the "CLOSE" prompt. They should be aware of the following definitions, which apply:

- A message is open as long as an associated response is not received - A message which needs not an answer is closed once received - A message is closed when its associated response, other than STANDBY or

REQUEST DEFERRED, is received. Free text message received on board will be closed once ROGER has been answered. ROGER is the sole response to any up linked free text.

4.4.7.10. EMERGENCY PROCEDURES Pilots should be aware of the CPDLC emergency procedures, which apply in the considered area. The emergency mode is activated through the EMERGENCY prompt of the ATC menu page. In particular, they should know what can be expected from the controller once the emergency mode is triggered. The general rules usually apply: - The controller shall immediately acknowledge receipt of an emergency message,

which has been sent by the pilot (e.g. MAYDAY or PAN). Either voice or CPDLC free text will be used. If free text is used, the crew is not required to close it through the "ROGER" reply.

- The controller shall also attempt a voice contact after he has acknowledged an

emergency message through CPDLC - If CPDLC is the best (or the sole) means for communications, the current controller

will keep the connection active to provide the assistance. In particular, no transfer (either automatic or manual) of connection will be done.

Remark: When both CPDLC and ADS are active, sending an emergency message through CPDLC automatically switches the ground ADS contract to the "High Periodic Reporting rate" (ADS Emergency mode). Conversely, sending the CPDLC "CANCEL EMERGENCY" message deactivates the ADS emergency mode.



Please, bear in mind… CPDLC Connection

• Once the AFN has been successfully done, the ATC centre can initiate aCPDLC connection (transparent to the crew).

• Checks are automatically done by the ATSU to validate or reject theconnection: - Connection is accepted if no previous connection already exists or, it is

relative to the next data link ATC to control the aircraft - Connection is rejected in all other cases

• Once connection is established, the active connected ATC centre is thendisplayed on the DCDU, and on the CONNECTION STATUS page of theMCDU.

Failures of the CPDLC connection

• As soon as a failure of the CPDLC connection is noticed by either the crew or the ground controller, voice will be used to inform the other part of the failureand to co-ordinate further actions.

• Once a connection has been lost, a complete LOGON procedure (AFN +Connection) must be done.

Transfer to the next ATC

• To inform the aircraft avionics (i.e. ATSU) that a transfer of control willoccurred, the current active ATC sends a so-called NDA message (Next Data Authority) to the aircraft. This is the only way for the ATSU to be aware of andto accept the connection with the next ATC centre.

• Once a NDA message has been received, the aircraft is waiting for theconnection with the next ATC centre.

• Under normal circumstances the CPDLC connection should be establishedwith the Next Data Authority prior to the connection between the aircraft and the current data authority being terminated

To be noticed Pending the ATN, as long as the FANS A ACARS based protocols is used, both pilotand controllers cannot know whether a message has been delivered to their rightcounterpart.



4.5. ADS PROCEDURES 4.5.1. ATS NOTIFICATION AND ADS CONNECTION The AFN procedure as described in §4.3 is to be applied to initiate an ADS connection with the desired ATC centre. The ATC centre can establish ADS contracts once the AFN has been done either manually via the MCDU or automatically through a transfer from a previous ATC centre. As soon as the ATSU is initialised, the ADS application is armed, waiting for a possible connection: - With the current FANS A design, ADS is ON by default, which is slightly misleading.

Until an ATC centre initiates a contract, ADS remains armed (refer to the examples here after).

- In addition, there is no means for the crew to know whether or not ADS is operative. On the NOTIFICATION page, "NOTIFIED" is displayed once the notification has been done, but this does not mean that the ADS is launched. On the CONNECTION STATUS page as well as on the DCDU, nothing is displayed (NO ACTIVE ATC for the DCDU and the ACTIVE ATC is dashed ---, on the MCDU page). These two devices are devoted to CPDLC only.

In the FANS A+ package, the initial FANS A HMI (as defined here above) has been modified to provide additional information relative to ADS/CPDLC connections.

Note: The ADS system must be set to “ON” (or “ARMED” with FANS A+), prior to

perform an ATC notification. This setting is the default status. With FANS A+, ADS connection status will stay on “ARMED” after AFN until at least one contract has been established. At this time, the ADS status switches to “CONNECTED”. This is not the case with FANS A, for which ADS status is “ON” before and after a contract establishment (see examples hereafter).

FANS-A FANS-A+

ADS Connection Status on MCDU

"OFF""ON"

"OFF""ARMED""CONNECTED"

ADS Connection Status on DCDU No Information

"ADS Connected (X)"where X is the number of

connections

MCDU / DCDU ADS Connection status


FANS A vs. FANS A+ MCDU HMI

FANS A MCDU HMI FANS A+ MCDU HMI

Notification done / Waiting for a connection (ADS or CPDLC)

An ADS connection occurred

ADS status is « ON » on the MCDUpage. But it does not mean that ADScontracts have been set up. In fact,here ADS is just «armed”, waiting forcontracts

ADS status is « ARMED » on the MCDU page. The ADS status is given without ambiguity.

ADS status is still « ON » on theMCDU page. But is this example,contract(s) has(have) been set up.

ADS status is now “CONNECTED”. We clearly know that the ADS application is sending reports to at least one ATC.




FANS A DCDU HMI FANS A+ DCDU HMI

A CPDLC connection exists, but no ADS contract has been set up.

CPDLC and 2 ADS connections are active

DCDU is devoted to CPDLC application. No information relative to ADS contracts areavailable

DCDU is devoted to both CPDLC & ADS applications. Information relative to ADS contracts are available

We can see that no ADS contracts has been set-up. (ADS is either “OFF” or “ARMED”)

We can not see that no ADS contracts hasbeen set-up (ADS is “ON” or “OFF”)

There is no CPDLC connection, but 2 ADS contracts have been set up.

In case of ADS-only, the information given bythe DCDU screen can be misleading. Even ifthere is “NO active ATC”, ADS contract couldhave been set up.

There is no ambiguity regarding the ADS status on the DCDU screen

No CPDLC and No ADS connections

Even if there are no connections, the CPDLCconnection status is displayed.

When there are no connections, the default screen is black.



4.5.2. ADS CONNECTIONS MANAGEMENT The ADS connection management is transparent to the crew, but is under the responsibility of the ATC centre in charge of the flight.

4.5.2.1. ADS CONNECTION PRIORITIES: FANS A equipped aircraft can have up to five ADS connections. One of the five connections is reserved for use of the AOC. The aircraft has the capability to report to four different ATC simultaneously using ADS. The FANS A system does not assign technical priority to ADS connections; therefore, the controlling ATC may not be aware of other connections established with the aircraft. In order to manage these connections, a procedural hierarchy controlled by the Address Forwarding process (§ 4.4.2.2) has been established.

4.5.2.2. ALLOCATION OF ADS CONNECTIONS: Using the Address Forwarding process, the current controlling authority shall allocate ADS connection priority to the next ATC that will have air traffic control responsibility for the aircraft. The priority for the allocation of ADS connections shall be in accordance with the following list:

1. The Current Data Authority, 2. The Next Data Authority, 3. An ATC requiring a connection for monitoring operations close to a FIR border, 4. Airline AOC 5. Other miscellaneous connections.

Remark: It is to be noticed that in the FANS A+ package, an MCDU “ADS DETAIL” page lists ATC centres with active ADS contracts. They can easily be disconnected through the appropriate right Line Select Key (LSK) of the MCDU.

In the example given through this figure, four centres have set up ADS contracts. Pressing the appropriate LSK cancels the ADS contract established by the corresponding ATC centre.



4.5.3. POSITION REPORTING WITH ADS Initially CPDLC was used for position reporting, but using the possibility of ADS to send position co-ordinates, some areas (such as NAT) has developed possibility to use ADS for position reporting. The way to report position by CPDLC or ADS is mentioned in AIPs of concerned area. In all cases, HF voice is on stand by to be use as a back up.

4.5.3.1. CPDLC REPORT AT FIR ENTRY POSITION When an ATC has nominated the use of ADS reporting only within the associated FIR, an HF or CPDLC position report at the FIR entry position is still required to confirm that the ATC holds the status of Current Data Authority. Following the initial report at the boundary, no further CPDLC or voice position reports will be required for operations within the FIR.

4.5.3.2. UPDATING WAYPOINT ESTIMATES ATS should publish in the AIP that pilots are not required to update estimates for waypoints when the aircraft is reporting by ADS in airspace where additional CPDLC or voice reports are not required. Exceptions to this rule are that updates to estimates are required when:

- An estimate previously advised by voice or by CPDLC will change by more than 2 minutes

- A pilot-initiated action, such as a change in speed, will change the estimate for the next reporting point by more than 2 minutes

Here also, and to a greater extent, whenever ADS is used, only ATC reporting points should be entered in the FMS F-PLN. This will avoid immediate reports triggering at unknown fixes. 4.5.4. ADS CONNECTIONS CLOSURE ADS is transparent to the crew. In particular, contracts can not be modified from the aircraft. An individual ADS connection may be stopped from the ground or manually by the crew (FANS A+ only) through the ADS DETAIL page of the MCDU ATC menu. ADS contracts and connections should normally be terminated by the ground system when the:

- Aircraft has crossed any FIR boundary and has passed beyond the normal "back co-ordination" parameter

- Aircraft's flight plan has been cancelled or has finished Note: Once the ATC centre has been notified ("NOTIFIED" is displayed on the MCDU),

the ADS should not be set to off, unless instructed to do so (e.g. ATC request). If the ADS is set to off, the ATC centre can no longer be provided with ADS reports.



4.5.5. ROUTE OFFSET The accuracy of the ADS intent and predicted route information is of prime importance when it is to be used by the ATC centre to allow for reduced lateral and /or longitudinal separation. If an offset is manually flown, in a Heading Select mode for instance, both the intent and predictions as sent by the FMS for ADS purpose, may be incorrect. A Waypoint will not be sequenced if the position is beyond 7NM from this point. It is then recommended that the crew keeps updated his FMS flight plan, and that he uses the FMS Offset function. When an Offset is flown with the FMS, the intent and predicted route information will be provided along the offset route. 4.5.6. ADS SHUTDOWN When a shutdown occurs the controller will advise the crew of the requirements for the position reports. If CPDLC is still available, the controller shall send a CPDLC free text: "ADS SHUTDOWN. REVERT TO ATC DATALINK POSITION REPORT" As for any free text the pilot will answer "ROGER". 4.5.7. EMERGENCY PROCEDURES The emergency mode can be activated either by the pilot or the controller, and is normally cancelled by the pilot. This activation is done through the EMERGENCY prompt accessed on the MCDU ATC page. When selected, the ATSU immediately sends a message to all ATC centres that currently have periodic or event contracts established with that aircraft. This means that all the established connections switch to this emergency mode and the High Reporting Rate will be automatically selected. The controller in charge of the flight shall acknowledge any ADS emergency message. This is done through either a voice contact or a free text CPDLC message. The following phraseology is then expected: "ROGER MAYDAY" or "ROGER PAN". It is to be noticed that when the pilot cancels the emergency mode, the existing contracts are unaffected by this cancellation.



4.6. ATS623 APPLICATIONS The ATS623 applications (Airbus implementation of AEEC623) are an option of the FANS A+ package. As a first step to a greater use of data link applications, and pending for a greater maturity of standardised services, Airbus has decided to implement only three AEEC623 applications:

- Departure Clearance (DCL) - Oceanic Clearance (OCL) - Digital – Automatic Terminal Information Service (D-ATIS)

Operating these applications is done with both the DCDU and the MCDU. Although very similar to the current FANS A functions, differences exist and must be kept in mind:

- ATS623 exchanges do not require a permanent connection between the ground and the aircraft systems

- ATS623 exchanges have been built upon voice exchanges: crew request, ground clearance, crew read-back and ground confirmation. This was a requirement from the Airworthiness Authorities.

- ATS623 exchanges do not allow for any data-link refusal of a clearance - No Time stamp information are available for ATS623 exchanges.

It is to be noted that in case similar applications have been customised through AOC (ACARS) contracts, these will no longer be available should the ATS623 package be chosen. This means that AOC DCL or OCL will no longer be sent from a customised AOC page. However, customised AOC functions such as Pre-Departure Clearance (PDC), which is not compliant with the AEEC 623 specifications, will remain possible through the ACARS. Note: ATS623 applications are not FANS applications, but are considered as such because using the DCDU/MCDU to exchange messages.



Example: Standard Departure Clearance Communication Scenario

Ground DSP

Aircraft

Request DCL

ACK DSP

Clearance

Answer (ACK)

Confirmed

DCDUMCDU +

ATCMSG DCDU

+

DCDU

ATCMSG

DCDU+

1-

2-

3-

4-

ATC center

‘ sending ’

‘ sent ’

ACK DSP‘ sending ’

‘ sent ’

NAT

NAT

AUCT

NAT = Network Acknowledgement TimerAUCT = ATC Uplink Confirmation Timer

Figure 4.5 : DCL communication scenario

1- Departure Clearance request: The DEPARTURE CLEARANCE request is prepared

on the MCDU, displayed on the DCDU and sent to the ground.

2- Departure Clearance reception: An uplink clearance is received: the aural and visual warnings are activated, and the message is displayed on the DCDU.

3- Departure Clearance readback: If the pilot accepts the clearance, he selects the proposed ACK answer on the DCDU and sends it to the ground together with the clearance.

4- Departure Clearance confirmation: The ground confirms that the acknowledgement for this clearance has been received, this is displayed on the DCDU.

If the crew prefer to REFUSE the received clearance (step 3), then no downlink message is sent to the ground and this must be done by voice contact: this is indicated on the DCDU when REFUSE is selected. Note: An operational scenario can be found in Appendix I.




ADS Connections • An ATC centre can establish ADS contracts once the AFN has been performed. • FANS A equipped aircraft can have up to five ADS connections.

One of these is reserved to the AOC. The aircraft has the capability to report to four different ATC centressimultaneously using ADS.

• Different types of ADS "contracts" exist: - periodic: the data are sent at periodic time intervals. - on demand: the data are sent only when asked for. - on event: the data are sent whenever a specified event occurs.

• ADS is transparent to the crew. In particular, contracts can not be modified fromthe aircraft. A connection may be stopped from the ground or manually by thecrew through the CONNECTION STATUS page of the MCDU ATC menu

• ADS contracts and connections should normally be terminated by the ground system when the: - Aircraft has crossed a FIR boundary - Aircraft's flight plan has been cancelled or has finished

• A Waypoint will not be sequenced if the position is offset by more 7NM aside fromthis point. When an offset is flown, it is recommended that the crew keeps updated his FMS flight plan, and that he uses the FMS Offset function.

ADS shutdown When a shutdown occurs the controller will advise the crew of the requirements forthe position reports (by voice or CPDLC). ADS Emergency • The emergency mode can be activated either by the pilot or the controller, and is

normally cancelled by the pilot. When selected on the MCDU ATC page, the FMSimmediately sends a message to all ATC centres that currently have contractsestablished with that aircraft.

• The controller in charge of the flight shall acknowledge any ADS emergencymessage.

ATS623 • Pending for a greater maturity of standardised services, Airbus has decided to

implement only three AEEC623 applications: - Departure Clearance (DCL) - Oceanic Clearance (OCL) - Digital – Automatic Terminal Information Service (D-ATIS)

• In case similar applications have been customised through AOC (ACARS)contracts, these will no longer be available should the ATS623 package bechosen (e.g. AOC DCL or OCL will no longer be sent from a customised AOC page).

• However, ,customised AOC functions such as Pre-Departure Clearance (PDC), which is not compliant with the AEEC 623 specifications, will remain possiblethrough the ACARS.


5. FANS A EVOLUTION ............................................................................................78 5.1. FANS A Enhanced ADS.............................................................................78 5.2. FANS A+ (FANS A System Evolution)......................................................78

5.2.1. FANS A+ Basics ................................................................................79 5.2.1.1. Enhancements to the Human-Machine Interface (HMI) ................................... 79 5.2.1.2. Improvements related to the CPDLC service.................................................... 80 5.2.1.3. DataLink Service Provider (DSP) worldmap ..................................................... 81 5.2.1.4. ATSU router customisation via loadable database........................................... 81 5.2.1.5. BITE (Built-In Test Equipment) improvement ................................................... 81

5.2.2. FANS A+ Options ..............................................................................82

5.2.2.1. HF DataLink (HFDL) ......................................................................................... 82 5.2.2.2. High speed VHF datalink (VDL mode2)............................................................ 83 5.2.2.3. Wired High speed dataloading capability (AEEC 615a) ................................... 83 5.2.2.4. clearances and digital atis applications (ATS623) ............................................ 84

5.2.3. FANS A+ Retrofits .............................................................................84

5 – FANS A EVOLUTION


5. FANS A EVOLUTION

5.1. FANS A ENHANCED ADS The issues concerning aircraft position reporting through ADS with FANS A over North Atlantic have been solved as detailed in Appendix J (OIT/FOT Ref. “SE 999.0001/03/VHR”). 5.2. FANS A+ (FANS A SYSTEM EVOLUTION) Since certified on both A330 and A340 aircraft in July 2000, FANS A has been used by numerous operators in various areas such as the Pacific Ocean, the North Atlantic Ocean or even the Indian Ocean. These three years of operations and an active participation in numerous international forums for CNS/ATM implementation have led to the introduction of new services and of modifications so as to satisfy to interoperability and standardisation requirements. The aim of this chapter is thus to list and to describe the main points that are addressed by this new standard of FANS A services. The objectives of this new standard FANS A+ are two-fold:

• To improve the current package of FANS A services (FANS A+ basics) • To extend the use of data link services (FANS A+ options)

Improvements address points coming from feedback from operators (e.g. ADS information on DCDU), interoperability and standardisation objectives (e.g. addition of CPDLC elements to clarify some messages) or have been dictated by improvement of Human Machine Interface (HMI) or by functional evolutions (e.g. availability of the "LOAD" command on the DCDU). New data link services have also been added with the introduction of :

- VDL mode 2, so as to increase the capacity for ATC communications - HFDL capability for ATC (once this service is approved) - Departure and Oceanic clearances together with Digital-ATIS applications

(ATS623) - High speed dataloading capability (AEEC 615A)

These services are optional and may be chosen separately according to the airlines needs and types of operations. Note: The following evolutions are independent of the software update providing an enhanced ADS (detailed in §5.1) and will be basics for A330/A340 at the entry into service since January 2004.



5.2.1. FANS A+ BASICS

5.2.1.1. ENHANCEMENTS TO THE HUMAN-MACHINE INTERFACE (HMI) In the FANS A+ package, the initial FANS A HMI has been modified to provide additional information relative to:

- ADS/CPDLC Connections - CPDLC Message and functions

• ADS (Modifications on MCDU):

- MCDU “CONNECTION STATUS” page specifies if ADS is either "ARMED", "CONNECTED" or "OFF" (as detailed in § 4.5.1).

- MCDU “ADS DETAIL” page lists ATC centres with active ADS contracts. They

can easily be disconnected separately through the appropriate right Line Select Key (LSK) of the MCDU (as detailed in § 4.5.2).

• Modifications on DCDU:

- FANS A DCDU was designed to be operated in an ADS/CPDLC environment, as it was foreseen in the CNS/ATM concept. In case of ADS-only regions, the DCDU HMI indicates “NO ACTIVE ATC”. This message refers to the CPDLC status only, and does not mean there are no ADS contracts established with the aircraft. So as to improve the knowledge of the ADS status, an ADS indication has been added on the DCDU (refer to §4.5.1)

- Previous «NO ACTIVE ATC» indication (on CPDLC status) has been removed in FANS A+.

• DCDU indications in case of failures In any abnormal conditions as regards the CPDLC services, positive information is provided on the DCDU screen whenever appropriate. In this case, the pilot (through voice) must notify the current ATC of the problem and restart the CPDLC connection through the complete AFN procedure from the MCDU NOTIFICATION pages (refer §4.3). • Crew awareness in case of no reply from the ATC Whenever an ATC reply has not been received after 5 minutes, the crew is warned by a message on the DCDU.

- If the request is still displayed, the indication is just added on the DCDU. - If the request had been closed, it is then automatically recalled and displayed

again with the "NO ATC REPLY" indication.



5.2.1.2. IMPROVEMENTS RELATED TO THE CPDLC SERVICE. They have been added in agreement with international FANS inter-operability groups that have been working on CNS/ATM implementations in various parts of the world. • Addition of information on Report messages When needed, the following message elements are now automatically proposed as part of the down-link message: "CLIMBING TO", "DESCENDING TO" or "DEVIATING TO". They are part of the Report messages, and are proposed wherever appropriate by the FMS. • Discarding old up-link messages To prevent operational misunderstanding due to delayed messages presentation (because of ACARS networks' performance), some ATC centres will ask, in a near future, the crews to set a maximum value for an acceptable delay. This request, done via CPDLC the message: "SET MAX UPLINK DELAY VALUE TO xxx SEC", will be displayed on the DCDU. The crew will set the value on the CONNECTION STATUS page in the MAX UPLINK DELAY field. Messages received beyond this maximum elapsed time will be discarded (not displayed on the DCDU). An error message will be sent to the ground indicating that the related delayed message has been discarded by the airborne system.

Figure 5.1



• The "Back On Route" Message after an offset has been flown When offsets are flown in areas where CPDLC is the first means of communication, to avoid the use of a free text to inform the ATC once back on the initial route, the "Back On Route" pre-formatted message has been added on the MCDU ATC REPORTS page.

Figure 5.2

5.2.1.3. DATALINK SERVICE PROVIDER (DSP) WORLDMAP In order to optimise Frequency, Media and DSP selection, an algorithm (VHF Worldmap) lists the VHF datalink service providers available in each geographical area. The ATSU router automatically selects a VHF frequency depending on the aircraft position in accordance with the scan mask entered by the airline.

5.2.1.4. ATSU ROUTER CUSTOMISATION VIA LOADABLE DATABASE Configuration of the ATSU Router (SCAN MASK and A/L IDENT parameters) can be achieved through a loadable database. MCDU inputs inhibition for those parameters is also achieved via loading of a customised ATSU router database.

5.2.1.5. BITE (BUILT-IN TEST EQUIPMENT) IMPROVEMENT The system capacity to auto-diagnose its failures (or those of its peripherals) has been improved to limit the number of inopportune messages, which harm the correct breakdown service of the system.



5.2.2. FANS A+ OPTIONS

5.2.2.1. HF DATALINK (HFDL) • HFDL for ATC purpose HF Data Link (HFDL) is an optional function of the FANS A package that has been certified only for AOC purpose (as explained in §2.2.1.3). HFDL for ATC purpose will be certified with FANS A+ and we can reasonably hope that it will soon be approved for ATC communications. For this reason, although HFDL is not yet approved by airworthiness authorities as a medium for ATC communications or surveillance functions, it has been decided to remove the “lock" installed on current FANS A, and allow for the use of HFDL as a tertiary means of communication for data link ATC messages. The reason behind this is that operational trials have started in some parts of the world, to demonstrate that HFDL could be used for ATC. Good results have so far been gathered. HFDL performance happens to be better than current HF voice. • Operational use of HFDL As there is only one HF antenna to support the use of either HFDL or HF voice, some operational constraints exist that have to be understood. HF voice and HFDL cannot be used at the same time, and as per the international aeronautical rule (AEEC 753), HFDL is inhibited for 60 seconds whenever HF voice has been used for transmission. This 60 seconds limitation is justified by the need for a possible HF voice reply to any HF voice initiated from the aircraft. So as not to disturb this reply, HFDL is thus inhibited momentarily. This one minute limitation is arguable: in some poor conditions of propagation, one minute may not be sufficient. The above mentioned rule however, recommends an inhibition in between 30 and 120 seconds. 60 seconds were chosen on Airbus aircraft. When HFDL is used, the aircraft may be emitting for slots of 2.5 seconds every 32 seconds.



5.2.2.2. HIGH SPEED VHF DATALINK (VDL MODE2) VHF Data Link mode2 (as described in §2.2.1) is an optional function of the FANS A+ package that allows higher data rate than VDL mode A. • VDL-2 operations Although both the current VDL mode A and VDL mode 2 are available in the ATSU, only one of them can be used at the same time. Although mostly developed to overcome the current ACARS networks congestion, the VDL-2 should be used for ATC purpose. It has indeed started to be used in two ATC centres (Maastricht and Miami) and will be implemented in other ATC over the next years. VDL-2 ensures a communication function, and as such is not dependent of any application. Current AOC applications can be transferred to VDL-2 without modification. The figure given in Appendix C gives the current deployment of VDL-2 ground stations. (ARINC courtesy). As can be seen, deployment over continental US airspace is large. It must be noted that another service provider (namely SITA) has already taken the needed provisions on their ground stations throughout both Europe and USA for a quick upgrade to VDL- 2.

5.2.2.3. WIRED HIGH SPEED DATALOADING CAPABILITY (AEEC 615A) • General: The ATSU has now the capability to support wired high speed data loading specification AEEC-615A (Ethernet loading usually called ARINC-615A), which enables airlines to save additional operating costs. This new feature reduces software data loading duration with a factor of 5 at a minimum and introduce also a full ATSU software configuration management (including the AOC ) to ease maintenance operations. On board high speed dataloading requires installation of:

- a dedicated plug in the avionics bay - an hardware modification, which consists in integrating an Ethernet module in the

ATSU • Benefits: A joint utilisation of a high-speed-dataloading ATSU and of a SDL/PDL provides the following benefits:

- Reduced dataloading time with a factor of five at a minimum - Compatible with AEEC 615-3 and AEEC 615A - Facilitated maintenance operation:

. reduce manual intervention between loads

. capacity to load customised airline configuration

. user-friendly dataloader design

. trouble shooting aids in case of loading issue



5.2.2.4. CLEARANCES AND DIGITAL ATIS APPLICATIONS (ATS623) • ATS623 Main HMI principles In Appendix I, a departure clearance scenario is proposed to depict the main points that are linked to the three applications. • Operational use of ATS623 As part of the certification, the operational conditions for a use of the ATS623 is as follows:

- Pre-flight and En-Route phases for both DCL and OCL - All flight phases for D-ATIS - During Take off and landing phases, all associated uplinks are inhibited. They indeed are put in a buffer and are displayed once out off the inhibition phases.

Although very similar to FANS A as far as the DCDU and MCDU displays and handling are concerned, the ATS623 operations do present some differences that have to be known (refer to 4.6). The most important point is that Oceanic Clearance and Departure Clearance are not true FANS A services, and as such, cannot be processed by the system in the same way as CPDLC for instance. The associated HMI (DCDU mainly) is thus slightly different, and has been adapted to take account of these differences. 5.2.3.FANS A+ RETROFITS To upgrade aircraft systems from FANS A to FANS A+ standards, only a software update is necessary for basic package and options (no hardware components need to be changed). For operators wishing to modify their aircraft configuration, an RFC (Request For Change) must be issued for the “basic functions” package (see §5.2.1) and a specific RFC for capabilities to be activated separately (options). Remark: the provision of AEEC615a capability (option detailed in §5.2.2.3) requires a hardware modification, which consists in the installation of a dedicated plug in the avionics bay along with the integration of an Ethernet module in the ATSU.




Enhance ADS

Current FANS A ADS system can be enhanced through the updates of the ATSU software (CLR3.6b) and FMS Pegasus 2 software (as detailed in Appendix G).

FANS A+ Standard

To improve the current FANS A package and extend the use of data link services, anew standard, called FANS A+, has been developed.

♦ Improvements address points coming from: - operational / in service feedback from operators - interoperability and standardisation objectives - improvement of Human Machine Interface (HMI) - functional evolutions

♦ New data link services have also been added with the introduction of : - VDL mode 2, so as to increase the capacity for ATC communications - HFDL capability for ATC (once this service is approved) - ATS623 (Departure and Oceanic clearances, Digital-ATIS applications) - High speed dataloading capability (AEEC 615a)

FANS A+ RETROFITS

To upgrade aircraft systems from FANS A to FANS A+ standards, only a softwareupdate is necessary (no hardware components need to be changed).

FANS A ACARS Router ATSU Software CLR3.5

FANS A with enhanced ADSACARS Router ATSU Software CLR3.6

FANS A+ ACARS Router ATSU Software CLR4.5

Jan. 2004

Enhanced ADS automatically provided with FANS A+ package

1Q-2003



6. FANS A WORLD STATUS ....................................................................................88 6.1. Status of FANS A implementation............................................................88

6.2. North Atlantic (NAT) ..................................................................................89

6.3. South Atlantic.............................................................................................90

6.4. North Canada .............................................................................................91

6.5. Pacific Ocean .............................................................................................91

6.6. Indian Ocean : South Africa......................................................................94

6.7. Indian Ocean : Australia............................................................................95

6.8. Singapore ...................................................................................................96

6.9. Bay of Bengal .............................................................................................96

6.10. China.........................................................................................................97

6 – FANS A WORLD STATUS


6. FANS A WORLD STATUS

6.1. STATUS OF FANS A IMPLEMENTATION For the time being only remote areas such as oceanic or desert areas are implemented with FANS. All FIRs which are FANS equipped, do not provide the same services. These FIRs may provide the following FANS functions

- Both ADS and CPDLC. - ADS only - CPDLC only

These FANS capabilities are represented on the following chart (based on data available in April 2003) :

FIR using FANS

Note: New York Oceanic service area (KZWY) is expected to implement ADS in

September 2003.

= Full FANS (ADS + CPDLC)

= CPDLC only

= ADS only

= ADS only + CPDLC trials

= ADS and/or CPDLC trials

= ADS and/or CPDLC planned before 2005

= ADS-B only



6.2. NORTH ATLANTIC (NAT) 6.2.1. OPERATIONAL CONCEPT The use of ADS to report position over waypoints is called ADS Waypoint Position Reporting (ADS WPR). Typically, on a Europe / North America flight (Eastbound and Westbound), ADS WPR is done at the 5 longitude crossings (10°W, 20°W, 30°W, 40°W, 50°W). In addition to the above NATS operations, it is to be noted that the New York oceanic FIR (KZWY) provides full CPDLC services and is to implement ADS in September 2003. Waiting for the implementation of ADS, pilots should send their required position reports using CPDLC. 6.2.2. AREA OF APPLICATIONS

• The NAT ADS airspace consists of both: - Gander* Oceanic Control Area - Shanwick Oceanic Control Area - Reykjavik** Oceanic Control Area - Santa Maria Oceanic Control Area - New York Oceanic Control Area (September 2003)

* Gander Oceanic CTA encompasses the Gander Oceanic FIR and that part of the Sondrestrom FIR south of 63°30' and above FL195 ** Reykjavik CTA encompasses the Reykjavik FIR and that part of the Sondrestrom FIR north of 63°30' and above FL195.

• The NAT CPDLC operational airspace consists of New-York Oceanic Control Area.

It is to be noticed that CPDLC trials are carried out in both Gander and Shanwick OCA. Iceland (Reykjavik) and Portugal (Santa Maria) have indicated that they may be able to begin CPDLC pre-operational trials in 2004.

• Both ADS and CPDLC trials have started in Canary Islands FIR (see South Atlantic operations §6.3).

6.2.3. NAT OPERATIONAL PROCEDURES They are based on a "Guidance material for ATS Data Link Services in the NAT Airspace". This document may be downloaded from the NAT PCO (North Atlantic Program Coordination) web site: http://www.nat-pco.org For deeper interest, the main NAT operational procedures are given in Appendix E. 6.2.4. POINT OF CONTACTS Don Harris Manager, Procedures

Nav Canada

Ph: (613) 563-5674 Fax: (613) 563.5674 E-mail: [email protected]

John Coulson UK NATS Ph:44 1293 576385 Fax: 44 1293 576452 E-mail: [email protected]

Leifur Hakonarson

CAA Iceland

Ph: 354 569 4100 Fax: 354 552 2744 E-mail: [email protected]

mailto:[email protected]




6.3. SOUTH ATLANTIC 6.3.1. OPERATIONAL CONCEPT CPDLC for position reports and ADS functions may be exercised within the Canarias airspace for operational evaluation trials. The CANARIAS ATS unit (GCCC) ensures those services. 6.3.2. AREA OF APPLICATIONS A protocol was developed by Cape Verde and Spain in order to enable Sal (Cape Verde) ACC to receive information from Canary Island ADS system. Furthermore, Spain is initiating protocols for “ADS sharing” with other members of EUR/SAM Corridor, such as Brazil (Recife) and Senegal (Dakar). 6.3.3. OPERATIONAL PROCEDURES Details about the SACCAN system and necessary detailed procedures to participate in the trials can be found in the document titled “Guidance material on SACCAN FANS A operational evaluation trials in Canarias airspace”, which can be requested to SATMA (South Atlantic Monitoring Agency) or directly downloaded from its web site: www. satmasat.com For deeper interest, the main South and Central Atlantic operational procedures are given in Appendix E. 6.3.4. POINTS OF CONTACT Contact points for the SACCAN FANS A operational evaluation trials within SATMA are as follows: Jorge Cabrera Umpiérrez

(Operational Support Department)

AENA Ph : + 34 928577057 Fax : + 34 928577052 [email protected]

Jorge Ascensión Godoy (Operations Management Department)

AENA Ph : + 34 928577060 Fax :+ 34 928577052 [email protected]

Operators using ARINC as their DSP

Terry Anton ARINC Ph : 410 266-4027 Fax :410 573-3515 [email protected]

Operators using SITA as their DSP

Eduard Blasi SITA Ph : + 33 1 4641 2473 Fax :+ 33 1 4641 1978 [email protected]




6.4. NORTH CANADA 6.4.1.AREA OF APPLICATIONS

Independent of NAT Region, Nav Canada also plans to expand its domestic data link service into Canada's northern airspace by making its Edmonton (CZEG) area control centre ADS and CPDLC-capable in early 2004. Such an upgrade could facilitate air transport flights that take the polar routes between North America and the Asia-Pacific region. Waiting for HFDL to be approved as an ATC media, ADS and CPDLC services will be limited to 80°N (satellite coverage limitation).

6.4.2. POINTS OF CONTACT

John Fekkes

Nav Canada Ph: 1 613 248 6930 Fax: 1 613 248 6802 [email protected]

Norm Dimock

Nav Canada Ph: 1 613 248 6859 Fax:1 613 248 6802 [email protected]

6.5. PACIFIC OCEAN 6.5.1. AREA OF APPLICATIONS

• For more than 7 years , the South Pacific has been used as a trial area for data link operations. CPDLC and ADS procedures have been experienced and fine tuned. Specific operations have been developed so as to increase the operational benefits of the operators under the auspices of the ICAO ISPACG group (Informal South Pacific ATC Co-ordination Group).

The 5 following ATC centres have been involved so far:

- Oakland ACC - Tahiti ACC - Nadi ACC - Auckland ACC - Brisbane ACC

• Based on the procedures that have been developed in the South Pacific data link

operations are in use on routes of both the North and Central Pacific where the controlling centres are: - Oakland ACC - Anchorage ACC - Tokyo ACC




6.5.2. OPERATIONAL CONCEPT • CPDLC: It is used as the primary means of communications within the Pacific FIRs. • ADS: It is used by all the ATCs within the Pacific areas (except Oakland and

Anchorage, which should be equipped in 2004). • DARP (Dynamic Airborne Route Planning): This type of operation has been specifically developed to take full advantage of the weather conditions as they appeared along the average 14 hours flight in the SOPAC. It consists in allowing an in-flight dynamic re-routing once better wind conditions are known. Once primarily negotiated with the concerned ATCs, a new flight plan is sent by AOC to the aircraft via ACARS into the FMS secondary flight plan. It is then up to the crew to decide and negotiate for the new route. All this transaction with ATC is done through CPDLC. Now, DARP is used on some User Preferred Route (detailed below). Although promising, this procedure (detailed in Appendix F) has not been used very much for the time being, because it happens that the current wind models, as used by the airlines, are precise enough within the frame of the flight. Activating the DARP procedure requires a good co-ordination between all involved actors (Aircraft, AOC, ATC) . The User Preferred Route procedure (UPR) is by far preferred by the airlines. In addition, DARP cannot be generalised because it needs AIDC between the various ground ATC, which is not available in all ATC centres. • UPR (User Preferred Route): The wind models used by the airlines are not the same than those used by the ATC when the daily PACOTS routes are defined. Differences of up to around 15 minutes of flight time are claimed by the operators. These have been asking for the possibility to define their own routes according to the daily conditions. They file their UPR Flight Plan. These UPR procedures are generalised throughout South Pacific. • Reduced lateral separation (50Nm) As previously mentioned, 50 NM lateral separation is already used in New Zealand airspace and throughout Oakland's airspace between RNP-10-capable aircraft (75NM between RNP-10 and non-RNP-10 aircraft and 100NM between non-RNP-10 aircraft). But PACOTS tracks are only defined with 50NM lateral separation outside areas of known or forecast convective weather. It is to be notice that 30/30 lateral and longitudinal separation is to start in the Tasman sea area.



The end-to-end data link system is now sufficiently reliable to support 50NM lateral spacing in the south Pacific. Weather deviations occur frequently in the south Pacific but application of RVSM provides an opportunity for more flexibility and for added contingency procedures that pilots can use if a weather deviation clearance cannot be provided. Contingency procedures for 300 feet climbs are being developed and will provide a level of safety in all scenarios. Imposition of Required Navigation Performance RNP-10 in the Central Pacific has enabled the reduction in the lateral separation minimum from 100 nautical miles to 50 nautical miles. Refer to POM manual for description of all the procedures in use. All the operations are described in the so-called POM (Pacific Operating Manual) which has now been used as a basis to other areas in the world. This document may be downloaded from the FAA-Oceanic Procedures Branch (ATP-130) web site: http://www.faa.gov/ats/ato/130.htm 6.5.3. POINT OF CONTACT - Oakland: Jerry Audiat FAA Ph: 510-745-3320 Fx: 510-745-3628 [email protected]

Robert Hansen

FAA Ph: 510-745-3836 Fx: 510-745-3826 [email protected]

- Tahiti: Jean-Pierre Carle

VIVO Tahiti [email protected]

- Fiji: Inia Tueli J. Seetom

SASL-Fiji Ph: 679-725110 Fx: 679-724-525 [email protected]

[email protected]

- Auckland: Mark Goodall

ACNZ Ph: 64-9-275-3109 Fx: 64-9-275-3106 [email protected]

Paul Radford

ACNZ Ph: 64-9-2568077 Fx: 64-9-275-3106 [email protected]








- Brisbane: Adam Watkin

Air Services Australia

Ph: 61-7-3866-3421 Fx: 61-7-3866-3257 [email protected]

- United States: Jerry Audiat

FAA Ph: 510-745-3320 Fx:510-745-3628 [email protected]

Robert Hansen

FAA Ph: 510-745-3836 Fx: 510-745-3826 [email protected]

- Japan: Yoshiki Imawaka

JCAB Ph: 81 3 3581 6672 Fx: 81 3 3580 7971 [email protected]

Yoshinori Furukawa

Director ATC Div JCAB

y-furukawa @so.motnet.go.jp

6.6. INDIAN OCEAN : SOUTH AFRICA 6.6.1. OPERATIONAL CONCEPT CPDLC for position reports and ADS functions may be exercised along some African routes below the equator line, or over the oceanic routes (Indian and Atlantic). Johannesburg ATC centre (FAJO) ensures those services. 6.6.2. AREA OF APPLICATIONS Three areas A, B and C have been defined: - Area A is the continental part over the South part of Africa (South latitudes) - Area B covers the Indian Ocean part (Between 75°E and Johannesburg and down to

60°S ) - Area C covers the Atlantic Ocean part (Up to 10°W in the Johannesburg Oceanic

FIR) Appendix E highlight the main operations principles within this area. For further details, refer to the Indian Ocean Operating Manuals (IOOM). 6.6.3. POINTS OF CONTACT A J Bradshaw GAL Manager

ATNS Ph: 27 11 392 4895 Fx: 27 11 392 3946 [email protected]

Stuart Ratcliff ATNS Ph: 2711 928 6433 Fx: 2711 928 6420 [email protected]











6.7. INDIAN OCEAN : AUSTRALIA 6.7.1. AREA OF APPLICATIONS According to ERSA NAV/COMM §2-5, which describe data link operations within Australian airspace, and unless otherwise specified, both ADS and CPDLC are used in Australian FIRs. There are two Australian FIRs:

- Melbourne (YMMM) - Brisbane (YBBB)

6.7.2. OPERATIONAL CONCEPT CPDLC: is the primary means of communication outside VHF voice range and is used in conjunction with an HF backup frequency. Inside VHF voice range CPDLC is used in conjunction with VHF on certain routes, but primarily outside radar coverage (generally the traffic within radar coverage is too busy for FANS A CPDLC). A CPDLC position report is required at the first contact:

- On the FIR boundary for aircraft inbound to Australian airspace - On being transferred to datalink from voice for outbound aircraft

Once the CPDLC position report is received by the ATC (which is only used to confirm that the FIR is the CPDLC data authority), and providing that ADS is operating normally, then only ADS position reporting is required by the ATC. (No CPDLC or voice position report is then required). ADS is thus used for this purpose on all routes outside radar coverage and allows lateral/longitudinal separation 30/30 Nm. Australian ATC does not have any requirements for new FANS operators, other than the aircraft and crew to meet the FANS training/performance standards of their State of Registration. Australian ATC has noticed that some new FANS operators have not had their aircraft registered correctly with the datalink service providers (e.g. SITA or ARINC) and therefore have been unable to logon to Australian data link system until the registration is completed. Emphasis is thus put on the correct preparation of data link operations. Appendix E highlight the main operations principles within this area. For further details, refer to the Indian Ocean Operating Manuals (IOOM). 6.7.3. POINTS OF CONTACT Craig Roberts



Adam Watkin







6.8. SINGAPORE 6.8.1. OPERATIONAL CONCEPT Although of a limited geographic area, the Singapore FIR does support both CPDLC and ADS operations (The 4-letter address code is WSJC). These are used on the South China Sea area (which is outside radar coverage) of the FIR, thus providing for a better knowledge of the aircraft position and for easier communications in these areas of poor HF operations. The Singapore CAA are waiting for international separation standards to be finalised to introduce reduced separation standards. Once introduced, less delays due to increased airspace capacity should bring the first benefits to airlines.

6.8.2. POINT OF CONTACT

Soo Kiat Goh CAAS/OP [email protected]

6.9. BAY OF BENGAL 6.9.1. AREA OF APPLICATIONS The L759 route (previously UM501) crossing above Bay of Bengal has been the very first one to be defined for specific FANS operations. This route crosses over three FIRs:

- Calcutta, India - Yangon, Myanmar - Phuket, Thailand

The three ATC centres are respectively:

- Calcutta, India (VECO) - Yangon, Myanmar (VYYF) - Phuket, Thailand (VTBB)

6.9.2. OPERATIONAL CONCEPT India, Myanmar and Thailand have published the route with special conditions, namely RNP4, ADS and CPDLC are the aircraft capabilities pre-requisites. The published requirements can be get from the local AIPs authorities.

6.9.3. POINTS OF CONTACT

S.P. Sikka Gal Manager-Ops Airports Authority-India

Ph: 91 11 465 2649 Fx: 91 11 461 1078

U YAO SHU Director ATS Dept of Civil Aviation Myanmar

Ph: 5 11 665 144 Fx: 95 665124

Suriya Samittachatti

Bangkok Area Control Centre Thailand

Ph: 662 285 9405 [email protected]





6.10. CHINA 6.10.1. AREA OF APPLICATIONS A specific FANS route (L888) has been opened along Western China over Tibetan plateau. Four FANS equipped stations ensure CPDLC and ADS services along this route:

- Kunming (ZPPP) - Chengdu (ZUUU) - Lanzhou (ZLLL) - Urumqi (ZWWW)

It is to be noticed that ADS and CPDLC operational trials are conducted along route A588, in Shenyang FIR (ZYSH). Procedures may be get from the local AIPs authorities. 6.10.2. OPERATIONAL PROCEDURES The route is RNP 4 or less; it provides 10 minutes longitudinal separation, 600 metres vertical separation, and the available flight levels are:

- 10200m / 11400m on the Urumqi to Kunming sector - 9600m/10800m/12000m on the Kunming to Urumqi way

The route is defined as follows: BIDRU MAKUL DONEN NIVUX LEVBA PEXUN SANLI LUVAR MUMAN TEMOL LEBAK TONAX NOLEP SADAN KCA(VOR). An AIP has been published to describe the data link capabilities supported by the China Air Traffic services on this Chinese western route. Both CPDLC and ADS operations are carried out through Satellite data link in a first step. Alternate airports along the route are:

- Kunming - Chengdu - Urumqi - Kashi

The diverting routes are described in the AIP. 6.10.3. POINTS OF CONTACT Yi Qun Deputy Director

CNS/ATM Division ATM Bureau

Ph: 8610 67318866 Fx: 8610 6731 8482 [email protected]

Li Xin CNS/ATM Division ATM Bureau

Ph: 8610 67318866 Fx: 8610 6731 8482 [email protected]




Synthesis The table underneath is based on data available in April 2003.

C P D L C A D S -C C P D L C A D S -CF ra n c e

F re n c h P o l. T a h it i N T T T T a h iti X X

F iji N F F F N a d i X XN e w Z e a la n d N Z Z O A u k la n d X X

A u s tra lia Y B B B B r ib a n e X XA u s tra lia Y M M M M e lb o u rn e X X

J a p a n R J T G T o k y o X XU n ite d S ta te s K Z A K O a k la n d X 4 Q -0 3U n ite d S ta te s P A Z A * A n c h o ra g e X 3 Q -0 4

A u s tra lia Y B B B B r is b a n e X XA u s tra lia Y M M M M e lb o u rn e X X

M a d a g a s c a r F M M M A n ta n a n a r iv o X XS e y c h e lle s F S S S S e y c h e lle s 4 Q .0 3 4 Q .0 3 X X

S o u th A fr ic a F A J O J o h a n n e s b u rg X XM a u r it iu s F IM M M a u r it iu s X X

G re a t B r ita in E G G X S h a n w ic k X XU n ite d S ta te s K Z W Y N e w Y o rk O c e a n ic X 3 Q -0 3

P o r tu g a l L P P O S a n ta M a r ia , A z o re s X 2 0 0 4

G re e n la n d (D e n .) B G G L * S o n d re s tro m (R e y k la v ic & G a n d e r C T A s ) X 2 0 0 4

Ic e la n d B IR D R e y k ja v ik X 2 0 0 4C a n a d a C Z Q X G a n d e r X XC a n a d a C Z E G * E d m o n to n 2 0 0 4 4 Q -0 3

C a n a r ie s Is . (S p a in ) G C C C L a s P a lm a s (C a n a ry Is la n d s ) X X

C a p e V e rd e Is . G V S C S a l (C a p e V e rd e Is .) X XN o rw a y E N O B * B o d o 2 0 0 5 2 0 0 5S w e d e n E S O S S to c k h o lm X

R u s s ia n F e d e ra t io n U H M M * M a g a d a n X XR u s s ia n F e d e ra t io n U L M M * M u rm a n s k X

U z b e k is ta n U T T T T a s h k e n t XM o n g o lia Z M B Z U la a n B a to r X X

In d ia V E C F K o lk a ta X XIn d ia V O M F C h e n n a i X X

M y a n m a r V Y Y Y Y a n g o o n X XT h a ila n d V T B B P h u k e t X X

B a y o f S r i L a n k a V C C C C o lo m b o X XIn d o n e s ia W A A Z U ju n g X XIn d o n e s ia W IIZ J a k a r ta X XM a la y s ia W M F C K u a la L u m p u rL a o P D R V L IV V ie n t ia n e

C h in a Z P K M K u n m in g (L 8 8 8 ) X XC h in a Z P K M C h e n g d u (L 8 8 8 ) X XC h in a Z L H W L a n z h o u (L 8 8 8 ) X XC h in a Z W U Q U ru m q i (L 8 8 8 ) X XC h in a Z Y S H S h e n y a n g -H a rb in (A 5 8 8 ) X X

S in g a p o re W S J C S in g a p o re X XP h ilip p in e s R P H I M a n ila 2 0 0 5 2 0 0 5

K o re a , S o u th R K T T T a e g u X XH o n g K o n g , C h in a V H H K H o n g K o n g X X

V ie tn a m V V G L H a n o i 2 0 0 4 2 0 0 4M a a s tr ic h t E H B K M a a s tr ic h t X X

U n ite d S ta te s K Z M A M ia m i X XE g y p t H E C C C a iro X X

Ira n O IIX T e h ra n X X

* : p e n d in g H F D L a p p ro v a l a s a te r t ia ry m e d ia fo r A T C , F A N S s e rv ic e s a re n o t p ro v id e d a b o v e 8 0 °N

E a s te r n E u r o p e

O p e ra t io n a l T r ia ls

In d ia n O c e a n

U IR id .S ta te

S o u th P a c i f ic

F IR

W e s te rn E u r o p e

N o r th P a c i f ic

A T N

S o u th A t la n t ic

N o r th A t la n t ic

C e n tra l A s ia

M id d le E a s t

F a r E a s t

E q u ip m e n t T e s t O p e r ta t io n s


7. STARTING FANS OPERATIONS........................................................................100 7.1. General .....................................................................................................100

7.2. DataLink: contracts and declarations ....................................................100

7.2.1. Contracts with Datalink Service Providers (DSP) ............................100 7.2.2. Aircraft declaration to DSP and ATC centres...................................101 7.2.3. Recommendations...........................................................................101

7.3. Impact on aircraft configuration .............................................................101

7.3.1. ATSU scan mask .............................................................................101 7.3.2. SATCOM user ORT.........................................................................101 7.3.3. AMI database of the FMS ................................................................102

7.4. Get the operational approval ..................................................................102

7.4.1. General ............................................................................................102 7.4.2. Aircraft configuration........................................................................103 7.4.3. Flight crew training / qualification.....................................................103 7.4.4. Maintenance training .......................................................................111 7.4.5. Approved documentation.................................................................111

7 – STARTING FANS OPERATIONS

100

7. STARTING FANS OPERATIONS

7.1. GENERAL This chapter aims at providing airlines with administrative and technical guidelines so as to ensure proper operations of FANS A aircraft on FANS routes. To perform FANS operations, data communication has to be ensured between the concerned Aircraft and the following entities:

• ATC Centres • Information service • Airline host

Or part of them depending on the operated area or the required services. For these reasons the operator needs to ensure the following before starting FANS Operations:

7.2. DATALINK: CONTRACTS AND DECLARATIONS The air/ground data communications can be made through the three following communication media:

• VHF • SATCOM • HF

As of today, VHF and SATCOM are certified by Airbus to sustain both ATC and AOC datalink, whereas HFDL (already used to make AOC datalink) is to be certified for ATC communications at the beginning of 2004. 7.2.1. CONTRACTS WITH DATALINK SERVICE PROVIDERS (DSP) To operate in FANS environment, i.e. on routes where AFN, ADS and CPDLC functions are required, it is necessary to have a contract with at least one of the major service providers (ARINC or SITA) for SATCOM datalink and VDL (VHF datalink). If an airline wishes to use more than one service provider, then two solutions may be considered:

- Place contracts directly with each service provider vider who will subcontract data

1. Sign contract(s) with Datalink Service Provider(s) (DSP) 2. Declare aircraft to these Datalink Services Providers 3. Declare aircraft and its FANS capability to ATC centres of the operated routes 4. Configure adequately the aircraft avionics 5. Obtain the operational approval

- Place a contract with a unique service pro

Flight Operations Support & Line Assistance Getting to grips with FANS – Ref STL 945.7011/03

handling to other service providers.



7.2.2. AIRCRAFT DECLARATION TO DATALINK SERVICE PROVIDERS

AND ATC CENTRES For ATC datalink, each individual aircraft must be declared, and identified namely through its Aircraft Registration Number in Datalink Service Provider tables. This is an imperative condition to allow ATC datalink message exchanges between an aircraft and the ATC centre on the ground. In addition, the SATCOM AES (Aircraft Earth Station) identification, i.e. the aircraft ICAO address, must be declared to the GES (Ground Earth Station) the aircraft will operate with. This is achieved through registering with Inmarsat using the Registration for service activation of Aircraft Earth Station (AES) form. The airline should make sure that all service providers to be potentially contacted by a given aircraft have been advised of its FANS capability and identification. Each new FANS aircraft entry into service must be declared to the service providers selected by the airline and to the ATC centres the aircraft will communicate with. 7.2.3. RECOMMENDATIONS It is strongly recommended not to make spontaneous FANS testing with ATC centres when they have not been previously made aware of a given aircraft intention to operate in FANS mode. Such unscheduled testing are indeed inconvenient for ground ATC centres, and disturb them in their daily work.

7.3. IMPACT ON AIRCRAFT CONFIGURATION Once the airline has selected the datalink service providers, the aircraft configuration needs to be adapted accordingly. This can be achieved through customisation of:

- The ATSU (Air Traffic Services Unit) scan mask for VHF DataLink - The SATCOM user ORT (Owner Requirements Table) for SATCOM datalink

7.3.1. ATSU SCAN MASK

The ATSU scan mask is a user-modifiable list of VHF Datalink Service Providers (DSP) that is used by the ATSU to operate in VHF datalink. DSP(s) to which the aircraft registration number has been declared FANS capable, must be sorted by order of priority in the scan mask. Airlines must therefore set up a scan mask programming policy to be applied on each FANS aircraft. If the scan mask is not set properly, FANS operation will be impacted, and this may result in ATC Datalink message losses. The Initialisation procedure of the ATSU router (airline identification and scan mask) is provided through AMM 46-21-00-860-801. 7.3.2. SATCOM USER ORT The SATCOM user ORT (Owner Requirements Table) is a database in which the airline specifies the GES/satellites on which the aircraft SATCOM system will logon for both voice and data communications. GES are connected to ARINC or SITA networks to provide SATCOM datalink services. Therefore, the programming of the ORT will impact FANS operation if not done properly, i.e. if selected GES are connected to datalink service provider networks to which the aircraft is not declared.



The table (Appendix D) gives the GES code and associated Satellite code that are used by Airborne SATCOM systems to select, according to the priority order set in the ORT, the couple Satellite/GES through which they will operate for both voice communications and datalink. The ORT cannot be modified via MCDU, thus is less prone to programming errors than the ATSU scan mask. 7.3.3. AMI DATABASE OF THE FMS The FMS database called AMI (Airline Modifiable Information) allows activating the FMS/ATSU interface. FMS data are required by the ATSU to operate in ADS, AFN and CPDLC. A wrong AMI definition can cause these FANS applications to be inoperative on a FANS aircraft. Airlines are required, by their FMS supplier, to fill-in a form called AMI worksheet, where they must specify the FMS optional functions they wish to use. In order to have FANS functions activated, it is necessary to have the datalink function enabled (§2.5.1 of Honeywell AMI worksheet). Airlines should advise their FMS supplier, that the aircraft on which the AMI will be loaded have the FANS function activated, so that a particular attention will be paid at AMI settings. 7.4. GET THE OPERATIONAL APPROVAL 7.4.1. GENERAL REQUIREMENTS Based on the systems global description and operational points, as described in the previous parts, the aim of this chapter is to provide the operators with recommendations and guidance material, that will help them to put in place operational procedures, training programs, and maintenance needed to obtain the operational approval to use CPDLC and ADS. Operational approval rules are not yet fully available and individual operational authority may choose the "means of compliance" (such as FAA AC 120-70), stating what the applicant airline may have to demonstrate. It is however expected that the following items will have to be complied with, by the applicant airline:

- Aircraft configuration - Flight crew training/qualification - Maintenance training - Approved operational documentation and procedures

In complement to the FANS A certification system, the airworthiness authorities of the applicant airline may require additional demonstration activities for specific environment or operational conditions. To this end, the FANS A Airworthiness Approval Summary document has been written for certification and provided to both the airline and its authority (refer to Appendix K). For FANS A+ approval, an Airworthiness Approval Summary document will also be available early 2004.



Based on this document, which lists the assumptions on the ground environment and gives a synthesis of the tests carried out for certification, the scope of additional tests may be defined:

- Interoperability test scenarios - Verification of the safety and performance criteria with regards to the considered

environment 7.4.2. AIRCRAFT CONFIGURATION The aircraft should be configured in accordance with the approved certification configuration for FANS A operations. In particular the following list of equipment shall be implemented:

- 1 ATSU - 2 DCDU - 2 “Attention getter” pushbuttons on the glareshield - 3 VDR - 2 second generation FMS: Honeywell Pegasus or Thales FMS2 (once certified) - MCDU with the "ATC COMM" key - FWC at appropriate standard - UTC Time Clock - MDDU at appropriate standard - SATCOM system - 2 HF

The list of the approved FANS aircraft configuration will be kept updated by Airbus. Compliance to this list will have to be ensured. Remark: To operate in the South Pacific and take benefit of the problem analysis as currently proposed by the FIT (FANS Interoperability Team, subgroup of the ISPACG), a strict adherence to the South Pacific Operations approved aircraft configuration list will have to be observed. 7.4.3. FLIGHT CREW TRAINING / QUALIFICATION

7.4.3.1. GENERAL RECOMMENDATIONS Operating an aircraft in a FANS type environment requires from the crew understanding, knowledge and operational use of the three C, N and S dimensions of the CNS/ATM concept. The Navigation aspects are addressed in the “Getting to grips with modern navigation” brochure. The following develops recommendations to assure flight crew qualification for a safe and efficient use of data link communications and surveillance systems. They should be part of the programmes to be presented to the airworthiness authorities.



To this end, the following points will be emphasised in preparing the flight crew training programs: • Basic knowledge of the overall CNS/ATM environment for which, the various

concepts and interacting elements, the involved aircraft systems and relevant operating procedures to be applied should be covered in a dedicated academic training.

• Operational use of data link communications (e.g. handling of up and down link ATC

messages or ATC operating procedures) should be taught so as to develop skills and practices for the considered FANS environment.

• Initial evaluation and recurrent training have to be part of the approved syllabi. • Specific Human Factors points pertaining to the data link communications should be

carefully addressed (they are mentioned in the here below "academic training" chapter.

7.4.3.2. PROPOSED QUALIFICATION MEANS A training program has been discussed with the main airworthiness authorities FAA/JAA. The individual airline should submit its own training program to its relevant authority to get the operational approval. It is Airbus opinion that the initial qualification should be made of the following components:

• Half a day familiarisation course, to address the academic training, and emphasise the main operational critical points.

• "Home work" training for each pilot, through the interactive CD-ROM developed by Airbus.

• One operational flight conducted with an airline check pilot. As soon as the FANS training are available in the simulators, the FANS training can be proposed in various options: initial, transition, recurrent or upgrade training or qualification programs.

7.4.3.3. ACADEMIC TRAINING The aim of the academic training is to familiarise the flight crew with the main characteristics of the digital communications, as used in a CNS/ATM context. In a first step prior to FANS operations, pilots will be introduced to the basic principles of CNS/ATM concept. Such an initial training may be based on the CD-ROM developed by Airbus or given as a first step. Note: To obtain a CD-ROM, a CBT license is needed. For further information, contact your Airbus Customer Service Manager.



Once completed, this program should not be repeated. Only the new, modified or specific points will be addressed during further programs. The following points should be part of this academic training: • General presentation of the CNS/ATM concept.

C, N and S together with the current trends for ATM should be described. The general characteristics of the data link communications will be given and the chain links of the components that exist in between a pilot and a controller will be emphasised. Flight crews should be made aware of the nominal systems operations and performance parameters, normal and abnormal use together with the limitations of the systems.

• Basic use of the AIM-FANS.

The crews should be taught on the normal handling of the data link. In particular, coping with the DCDU ATC messages reception and acknowledgement, acceptance or rejection should be addressed. At this stage, the crews will be made aware of the DCDU / MCDU relations for handling of Clearances and Requests and of the role of the FMS in such operations.

• Basic knowledge of the data link communications language, terms to be used

and information to be exchanged. Use of CPDLC and ADS for instance, are based on an extensive set of formatted messages, agreed upon abbreviations, conventions and assumptions the main of which will have to be known. The crews will be made aware of and familiar with the existing terminology as used by the considered ATS, as displayed on relevant charts or manuals, or given by the various service providers (ATC and communications). Familiarisation with all the available means of communications (e.g. VDR, HF, Satcom both in voice and data communications) is expected at that stage. In particular Satcom voice procedures, call addressing, ATC facility phone access, codes, call ID and priority will be covered. Later on, mode S or VDL 2, 3 or 4 will be included.



• Awareness of the ATS communications, co-ordination and credits for use of

data link

The ATC requirements in terms of F-PLN classification, separation criteria, operating procedures or MEL credits that are based on digital communications use should be known of the crews. A special emphasis on the voice/data link communications transition in both normal and abnormal configurations will be given. Although voice remains the ultimate back up mode, procedures for its use must be carefully followed.

• Basic knowledge of the main AIM-FANS components, equipment and controls

in both the nominal and abnormal operations.

The interaction of the various computers (e.g. ATSU, FMS, FWC) or the relations in between their interface (e.g. DCDU, MCDU, ECAM, printer, warning lights..) will have to be described here. Transmission times, failure annunciation, constraints and limitations of these components should be known of the crews for a safe and efficient operation.

• Human Factors considerations. The following recommendations have been developed to cope with the specific issues of the data communications: - The pilot responsible for the communications ensures that the situation awareness,

as entailed by the ATC data link messages, is fully shared by the other pilot. To this end, any message transiting through the DCDU (whether received or to be sent) will be read in a loud voice so as to ensure a common understanding and allow for a good cross checking between the two pilots.

- Crew co-ordination should be completed before any action ensuing a received

message is done or before any message or answer is sent to the ground. - Emphasis will be done on the crew work sharing, so as to avoid simultaneous head

down attention by both pilots, while handling of the messages is done.

7.4.3.4. OPERATIONAL TRAINING In addition to the academic training, the airline will have to demonstrate to its authorities that an operational training is done to provide all the flight crew members with the adequate training to perform their duties in an operational FANS environment. • Operational points This paragraph addresses the practical application of the operational procedures described in chapter 5. The Airbus CD-ROM training device, through its interactive operational scenarios, mostly covers this training syllabus. It may be presented by the airline to the airworthiness authorities as a "stand alone" computer-based instruction (CBI). It covers the data link communications items of the global FANS, and comes in complement to the RNP/RVSM operational training (as described in the “Getting to grips with modern navigation” brochure).



The following lists the items to be tackled in a training course. All but the "Special Recommendations" paragraph are addressed in the Airbus CD-ROM: - Message handling The pilots should be trained on how to receive and interpret ATC messages. Understanding the CPDLC / ADS phraseology is to be acquired. Appropriate use of the pre-formatted answers of the DCDU (e.g. WILCO, ROGER, UNABLE, CANCEL...) together with the knowledge for storing and retrieving messages from the ATC messages logbook will be addressed. Will also be practised the operations that require simultaneous work on both the DCDU and the MCDU. In particular, loading route clearance messages in the FMS, or preparing requests on the ATC pages of the MCDU should be covered. The automatism, as provided by the FMS, for monitoring and answering to some specific messages (e.g. differed clearances) should be known from the flight crews. Handling of automatically FMS proposed answers should be mastered. - Managing the communications systems The global use of the communications systems, whether they are traditional voice or new data link communications will have to be acquired. Establishing and terminating CPDLC, activating and deactivating ADS, switching from traditional voice based to digital communications control and coping with failures of these systems should be practised. All the available controls and indicators of the AIM-FANS system should be known and used (e.g. the meaning of the various displays, advisories, available functions). Whenever CPDLC is the primary means of communications, pilots should be trained to monitor the appropriate HF primary and secondary frequencies through the SELCAL. Whenever CPDLC is the primary means of communications, the use of voice communications should be done as a complement, and through the following available means:

- VHF - HF - SATCOM

SATVOICE may be considered, at pilot's discretion whenever required (emergency, medical advice, hazards,..) - ATS procedures and services Knowledge of the ATS procedures for the considered FANS area (e.g. timely, relevant and appropriate responses to communications and surveillance failures) is of prime importance. In addition, crews should be able to recognise "usual" failures and be fully aware of the tricks pertaining to the sensitivity of the end-to-end data link communications (Refer to the following recommendations).



- Special recommendations Derived from the lessons learned during FANS operations in the South Pacific area, the following list gives the main points to be underlined in the operational training: . Flight identification

The correlation of the flight identification, between that expected by an ATC ground system according to the filed F-PLN, and that of the coded message exercised during the initial log on attempt (AFN), is very prone to errors. Pilots should be fully aware that the flight identification of both the filed F-PLN and the one used for data link communications must be identical. It is the pilot's responsibility to ensure that correct flight identification and registration number are used. In particular, the operator ICAO 3-letter code is to be used (e.g. ICAO ATC filed F-PLN, FMS, data link). Attempting a connection with a TP 232 ident for instance, whereas TAP232 has been filed, will cause the ground system to reject the connection. Space and leading zeros in these identifications have to be carefully handled.

. Use of free text

Limit the use of free text message to exceptional cases. Pilots should be made aware that free text messages cannot be treated by the automated station of the controller as a standard ATC message. As such, no correlation between the free text and its answer can be provided.

Avoid abbreviations and acronyms since they may have different meanings to different operators.

. Use standard English aeronautical terminology only.

"ROGER" is the sole answer for an up linked free text message. Any other answer will keep the received message open.

. FIR transfer of control

- Until the AIDC function in between subsequent ATC centres is fully implemented, the transfer of control between two FIR will have to be carefully monitored by the crew. The applicable procedures will have to be strictly followed. Whenever an automatic transfer is done, it is recommended to monitor it through the display of the active ATC centre on the DCDU. In case a manual transfer is done, carefully apply the correct sequence of actions (as described in the "operational procedures" chapter or by the relevant ATC). In particular, pilots should verify that the expected ICAO 4 letter code for the region is displayed on the DCDU, and should not send any message before this check has been done.



- Disconnection may also occur during FIR transfers due to pending uplink messages and this, although the recommended procedures specify that the "END SERVICE" message is not transmitted while there are open messages. Pilots should be aware of such occurrences.

. Open message

Open messages should be chased and it should be recommended to avoid sending messages whenever another one is open. This is to avoid crossing answers, misunderstanding of replies, wrong correlation of up/down links or even disconnection (in the case of transfer of centre).

. Delays in responding

Both pilots and ATC answers to messages should be done as soon as possible. In case a STANDBY response has been received from the ATC, the flight crew should expect a further answer within 10 minutes. Waiting for it, the message remains open. If no answer comes on time, and to avoid a duplicate message, it is then recommended that the next message of the crew is based on an inquiry (e.g. "When can we expect...")

. Multi-element messages

Multi-elements messages (up/down links) should be avoided. Answering multi-elements messages is prone to misunderstanding since it is done for the whole message itself and cannot apply to each element individually.

. Waypoint sequencing

When an aircraft is laterally displaced by more than a set distance (7NM for Airbus models) from the track defined by an active flight plan, waypoints cease to be sequenced. This affects the data transmitted in CPDLC position reports and prevents ADS waypoint events from triggering reports. Monitoring the correct sequencing of the waypoints together with the updating of the F-PLN is thus to be recommended, especially in those areas of flight where ADS (or CPDLC) position reporting is done.

. Position reporting

Pilots should be aware that there is no ATC response to their CPDLC position report. As such, they must not re-send their message.

The ATC ground systems are designed so as to address compulsory reporting points as defined on approved En route charts. Pilots are thus invited to check that their FMS F-PLN is consistent with these charts, and that only compulsory position reports are sent through data link (CPDLC or ADS).



. Weather deviation

Weather deviation procedures should be emphasised in training. Increasing use of ADS and radar cover in some unexpected areas have shown that crews routinely deviate from track without a clearance for ATC.

Clearances and use of offset should be highlighted.

Weather deviation procedures have been developed and published: . Priority is given to aircraft which include "Due to weather" in requests or those using the urgency pro-word "PAN") . If ATC is unable to achieve the required deviation and maintain minimum horizontal separation, a 1000-foot vertical buffer will be provided. . If ATC is unable to issue a clearance or if communication cannot be established, the aircraft should climb or descend 500 feet, establish communications, and make the aircraft visible. This is a simple modification of global contingency procedures.

. Abnormal configurations

Pilots should be well aware of applicable procedures to revert to voice communications whenever a data link failure or misbehaviour is encountered.

• Operational responsibilities Pilot responsibilities: During their operational training, flight crews should be taught of their responsibilities with regards to the use of digital communications. The following lists the expected pilot's behaviour for an efficient use of the data communications systems, whether this is used as either a primary or a secondary means:

- Prompt and appropriate answer to up linked messages - Appropriate emission of down linked messages - Nominal crew work share for an efficient handling of the messages - Compensation of system failures through prompt back up voice - Compliance with the voice clearance whenever this contradicts the data link one - Use of data link only within approved area and configuration

Operator responsibilities: Operators have the following responsibilities regarding the use of digital communications:

- Signing contract with DSP and declaring aircraft to DSP and ATC centres of operated routes

- Configuring adequately the aircraft avionics, - Verifying digital communications functionality for each environment to be used and

when new or modified components or software are introduced, - Assuring follow up and evaluation of exceptional data link events; - Periodically assessing digital communication training, checking and maintenance

programs to ensure their correctness, pertinence, timeless and effectiveness.



• Operational feed back Pilots should be encouraged to report on the overall performance of the FANS system. Specific data link events should be reported to the flight operations department or to the ATC whenever appropriate. Data link anomalies (failures, loss of messages, unanswered messages, very long response time, disconnection...), procedural difficulties, human factors issues should be reported through any appropriate devices according to the airline policies. 7.4.4. MAINTENANCE TRAINING To get its operational approval, the airline must demonstrate that an appropriate maintenance training program relative to the digital communications, is given to its maintenance people. This is part of the ICAO Annex 6, paragraph 8.3. In this program, the procedures for digital communications maintenance will be consistent with that recommended in the relevant chapters of the aircraft maintenance manuals. The aim is to train the maintenance personnel to properly implement, maintain, or replace the AIM-FANS equipment (e.g. ATSU, DCDU, FMS, printer, VDR...) Installation, modification and use of testing tools are some of the points to be trained. The maintenance people should also be aware of the MEL items associated to the relief of FANS equipment. Adhering to configuration control lists that may be recommended in some FANS areas, so as to maintain recognised operating equipment and performance levels, might be part of the requirements. Data link service providers can provide the airline with information on poor performance by individual aircraft. It is also recommended that the airline provide Airbus with information on their current avionics configuration and operating performance so as to ensure a good feed back on the FANS systems and documentation update. Implementing the adequate Service Bulletins for approved configuration and ensuring software updates of the FANS systems are correctly incorporated should also be assured. 7.4.5. APPROVED DOCUMENTATION The applicant airline should present to its relevant authority a set of documents to be approved. It is expected that the following documentation will be required:

- FANS A Airworthiness Approval Summary - MEL - AFM

7.4.5.1. FANS A AIRWORTHINESS APPROVAL SUMMARY This document (provided in Appendix K) is part of the manufacturer operational approval. It can be made available to the national authority of the applicant airline. It contains the assumptions on the ground environment and a synthesis of the results of certification tests. Based on this document, the operational and technical context may be evaluated and additional demonstration activities be asked by the authority.



7.4.5.2. MEL (MINIMUM EQUIPMENT LIST) The airline should submit its intended MEL for operation of FANS routes to its airworthiness authority. In addition to the MEL provisions taken for the navigation equipment, in the frame of RNP/RVSM context (“Getting to grips with modern navigation” brochure), provisions will have to be taken for the digital communications equipment. The MEL items for data link communications may depend on the considered FANS route (oceanic, continental, remote areas). The airline should thus take provisions for some specific operating systems at dispatch, and consider the consequences of their loss on the data link communications. FANS operations are related to operational aspects, and therefore Airbus current policy is not to include FANS considerations in the MMEL. Therefore it remains up to the operators to amend their own MEL for FANS operations. However, for CNS/ATM operations, the following minimum equipment must be operative : * ATA 46-20 COCKPIT INFORMATION SYSTEM

- ATSU - 1 DCDU - 1 ATC MSG pb

* ATA 23 COMMUNICATIONS

- VDR3 - SATCOM Note : 2 HF are required for remote area further than VHF line-of-sight with or without FANS capability. Although the availability and the reliability of the SATCOM have proven to be good enough in South Pacific area, dispatch with one HF only is still not granted for such area. As soon as HFDL is available and authorized for ATC data link purpose, dispatch equipment list may be reconsidered.

* ATA 22 AUTO FLIGHT

- 1 FMGC Note : Second FMGC or its Nav Backup function may be required in function of the RNP of the planned route.

* ATA 34 NAVIGATION

- 1 GPS Note : GPS is needed for ensuring position/time report accuracy

7.4.5.3. AIRPLANE FLIGHT MANUAL The airplane flight manual shall reference the FANS A Airworthiness Approval Summary document (provided in Appendix K).



Please, bear in mind… To ensure proper operations of FANS A aircraft on FANS routes, the operator needsto ensure the following before starting operations:

1. Sign contract(s) with Datalink Service Provider(s) (DSP) 2. Declare aircraft to these Datalink Services Providers 3. Declare aircraft and its FANS capability to ATC centres of the operated

routes 4. Configure adequately the aircraft avionics 5. Obtain the operational approval

Contracts with Datalink Service Providers • To operate in FANS environment, it is necessary to have a contract with at least

one of the major service providers (ARINC or SITA) for SATCOM and VDL datalink • For ATC datalink, each individual aircraft must be declared, and identified namely

through its Aircraft Registration Number in DSP tables. • In addition, the SATCOM AES (Aircraft Earth Station) identification, i.e. the aircraft

ICAO address, must be declared to the GES (Ground Earth Station) the aircraft willoperate. This is achieved through the SATCOM commissioning procedure.

Impact on aircraft configuration Once the airline has selected the datalink service providers, the aircraft configurationneeds to be adapted accordingly. This can be achieved through customisation of:

- The ATSU (Air Traffic Services Unit) scan mask for VHF DataLink - The SATCOM user ORT for SATCOM datalink

Operational approval Rules are not yet fully available and individual operational authority may choose the"means of compliance" stating what the applicant airline may have to demonstrate.However, the following items will have to be complied with:

- Aircraft configuration The aircraft should be configured in accordance with the approved certificationconfiguration for FANS A operations

- Flight crew training/qualification Operating an aircraft in a FANS type environment requires from the crewunderstanding, knowledge and operational use of the three C, N and Sdimensions of the CNS/ATM concept.

- Maintenance training An appropriate maintenance training program relative to the digitalcommunications, must be given to maintenance people

- Approved operational documentation The applicant airline should present to its relevant authority the FANS AAirworthiness Approval Summary, the MEL and the AFM to be approved.

It is strongly recommended not to make spontaneous FANS testing with ATCcentres when they have not been previously made aware of a given aircraft intention to operate in FANS mode.


APPENDICES


APPENDICES

A - CPDLC messages and their meaning B - ADS Report data C - Data Communications Service Providers

- INMARSAT - ARINC - SITA

D - SATCOM Operators E - FANS Operational Procedures

- Pacific FANS operations - Indian ocean FANS operations - North Atlantic FANS operations - South Atlantic FANS operations - New York oceanic CPDLC service area

F - Dynamic Airborne Route Planning (DARP) G - Operational Scenarios FANS A H - Operational Scenarios FANS A+ I - Operational Scenarios ATS623 J - OIT/FOT Ref. 999.0001/03:

New Air Traffic Services Unit (ATSU) aircraft interface K - FANS A Airworthiness Summary

APPENDIX A


APPENDIX A

LIST OF CPDLC MESSAGES WITH THEIR MEANING

Listed in this appendix are all the FANS A and FANS A+ messages supported by the CPDLC, as defined by the EUROCAE ED-100 and endorsed by the ICAO ADS panel. Additional comments provided by the ISPACG user forum are displayed in italics. The abbreviations used for classification purpose are defined here below. All up and down messages have been classified into operational groups. The reference number is that of the initial ED-100. ABBREVIATIONS CLOSURE RESPONSES W/U WILCO, UNABLE, will close the uplink message. A/N AFFIRM, NEGATIVE, will close the uplink message. R ROGER, will close the uplink message. NE WILCO, UNABLE, AFFIRM, NEGATIVE, ROGER, STANDBY,

will not close the uplink message. Only the actual referenced response (time, heading, speed,…) will close the uplink message. Remark: The response is typed through the MCDU scratch pad after having pressed the DCDU “MODIFY” key.

Y Response required. N Response not required

Uplink - Responses and Acknowledgements

UL MESSAGE ELEMENT MESSAGE INTENT RESPONSE

0 UNABLE Indicates that ATS cannot comply with the request.

NE

1 STANDBY Indicates that ATS has received the message and will respond. The pilot is informed that the request is being assessed and there will be a short-term delay (within 10 minutes). The exchange is not closed and the request will be responded to when conditions allow.

NE

2 REQUEST DEFERRED Indicates that ATS has received the request but it has been deferred until later. The pilot is informed that the request is being assessed and a long-term delay can be expected. The exchange is not closed and the request will be responded to when conditions allow.

NE

3 ROGER Indicates that ATS has received and understood the message.

NE

4 AFFIRM

Yes NE

5 NEGATIVE No

NE

APPENDIX A


Uplink - Vertical Clearances


6 EXPECT [altitude]

Notification that a level change instruction should be expected.

R

7 EXPECT CLIMB AT [time] Notification that an instruction should be expected for the aircraft to commence climb at the specified time.

R

8 EXPECT CLIMB AT [position] Notification that an instruction should be expected for the aircraft to commence climb at the specified position.

R

9 EXPECT DESCENT AT [time] Notification that an instruction should be expected for the aircraft to commence descent at the specified time.

R

10 EXPECT DESCENT AT [position] Notification that an instruction should be expected for the aircraft to commence descent at the specified position.

R

11 EXPECT CRUISE CLIMB AT [time] Notification that an instruction should be expected for the aircraft to commence cruise climb at the specified time.

R

12 EXPECT CRUISE CLIMB AT [position] Notification that an instruction should be expected for the aircraft to commence cruise climb at the specified position.

R

13 AT [time] EXPECT CLIMB TO [altitude]

Notification that an instruction should be expected for the aircraft to commence climb at the specified time to the specified level.

R

14 AT [position] EXPECT CLIMB TO [altitude]

Notification that an instruction should be expected for the aircraft to commence climb at the specified position to the specified level.

R

15 AT [time] EXPECT DESCENT TO [altitude]

Notification that an instruction should be expected for the aircraft to commence descent at the specified time to the specified level.

R

16 AT [position] EXPECT DESCENT TO [altitude]

Notification that an instruction should be expected for the aircraft to commence descent at the specified position to the specified level.

R

17 AT [time] EXPECT CRUISE CLIMB TO [altitude]

Notification that an instruction should be expected for the aircraft to commence cruise climb at the specified time to the specified level. Due to different interpretations between the various ATS units, this element should be avoided.

R

18 AT [position] EXPECT CRUISE CLIMB TO [altitude]

Notification that an instruction should be expected for the aircraft to commence cruise climb at the specified position to the specified level. Due to different interpretations between the various ATS units, this element should be avoided.

R

19 MAINTAIN [altitude] Instruction to maintain the specified level. W/U

APPENDIX A


Uplink - Vertical Clearances (Continued)

20 CLIMB TO AND MAINTAIN [altitude]

Instruction that a climb to the specified level is to commence and the level is to be maintained when reached.

W/U

21 AT [time] CLIMB TO AND MAINTAIN [altitude]

Instruction that at the specified time, a climb to the specified level is to commence and once reached the specified level is to be maintained.

W/U

22 AT [position] CLIMB TO AND MAINTAIN [altitude]

Instruction that at the specified position, a climb to the specified level is to commence and once reached the specified level is to be maintained.

W/U

23 DESCEND TO AND MAINTAIN [altitude]

Instruction that a descent to the specified level is to commence and the level is to be maintained when reached.

W/U

24 AT [time] DESCEND TO AND MAINTAIN [altitude]

Instruction that at the specified time a decent to the specified level is to commence and once reached the specified level is to be maintained.

W/U

25 AT [position] DESCEND TO AND MAINTAIN [altitude]

Instruction that at the specified position a descent to the specified level is to commence and when the specified level is reached it is to be maintained.

W/U

26 CLIMB TO REACH [altitude] BY [time]

Instruction that a climb is to commence at a rate such that the specified level is reached at or before the specified time.

W/U

27 CLIMB TO REACH [altitude] BY [position]

Instruction that a climb is to commence at a rate such that the specified level is reached at or before the specified position.

W/U

28 DESCEND TO REACH [altitude] BY [time]

Instruction that a descent is to commence at a rate such that the specified level is reached at or before the specified time.

W/U

29 DESCEND TO REACH [altitude] BY [position]

Instruction that a descent is to commence at a rate such that the specified level is reached at or before the specified position.

W/U

30 MAINTAIN BLOCK [altitude] TO [altitude]

A level within the specified vertical range is to be maintained.

W/U

31 CLIMB TO AND MAINTAIN BLOCK [altitude] TO [altitude]

Instruction that a climb to a level within the specified vertical range is to commence.

W/U

32 DESCEND TO AND MAINTAIN BLOCK [altitude] TO [altitude]

Instruction that a descent to a level within the specified vertical range is to commence.

W/U

33 Reserved 34 CRUISE CLIMB TO [altitude]

A cruise climb is to commence and continue until the specified level is reached.

W/U

35 CRUISE CLIMB ABOVE [altitude]

A cruise climb can commence once above the specified level.

W/U

36 EXPEDITE CLIMB TO [altitude]

The climb to the specified level should be made at the aircraft's best rate.

W/U

37 EXPEDITE DESCENT TO [altitude]

The descent to the specified level should be made at the aircraft's best rate.

W/U

APPENDIX A


Uplink - Vertical Clearances (Continued)

38 IMMEDIATELY CLIMB TO [altitude] Urgent instruction to immediately climb to

the specified level. W/U

39 IMMEDIATELY DESCEND TO [altitude] Urgent instruction to immediately descend to the specified level.

W/U

40 IMMEDIATELY STOP CLIMB AT [altitude]

Urgent instruction to immediately stop a climb once the specified level is reached.

W/U

41 IMMEDIATELY STOP DESCENT AT [altitude]

Urgent instruction to immediately stop a descent once the specified level is reached.

W/U

171 CLIMB AT [VERTICAL RATE] MINIMUM Instruction to climb at not less than the specified rate.

W/U

172 CLIMB AT [vertical rate] MAXIMUM Instruction to climb at not above the specified rate.

W/U

173 DESCEND AT [vertical rate] MINIMUM Instruction to descend at not less than the specified rate.

W/U

174 DESCEND AT [vertical rate] MAXIMUM

Instruction to descend at not above the specified rate.

W/U

Uplink - Crossing Constraints

UL MESSAGE ELEMENT MESSAGE INTENT RESPONSE42 EXPECT TO CROSS [position] AT

[altitude]

Notification that a level change instruction should be expected which will require the specified position to be crossed at the specified level.

R

43 EXPECT TO CROSS [position] AT OR ABOVE [altitude]

Notification that a level change instruction should be expected which will require the specified position to be crossed at or above the specified level.

R

44 EXPECT TO CROSS [position] AT OR BELOW [altitude]

Notification that a level change instruction should be expected which will require the specified position to be crossed at or below the specified level.

R

45 EXPECT TO CROSS [position] AT AND MAINTAIN [altitude]

Notification that a level change instruction should be expected which will require the specified position to be crossed at the specified level which is to be maintained subsequently.

R

46 CROSS [position] AT [altitude]

The specified position is to be crossed at the specified level. This may require the aircraft to modify its climb or descent profile.

W/U

47 CROSS [position] AT OR ABOVE [altitude]

The specified position is to be crossed at or above the specified level.

W/U

48 CROSS [position] AT OR BELOW [altitude]

The specified position is to be crossed at or below the specified level.

W/U

49 CROSS [position] AT AND MAINTAIN [altitude]

Instruction that the specified position is to be crossed at the specified level and that level is to be maintained when reached.

W/U

APPENDIX A


Uplink - Crossing Constraints (Continued)

50 CROSS [position] BETWEEN

[altitude] AND [altitude] The specified position is to be crossed at a level between the specified levels.

W/U

51 CROSS [position] AT [time] The specified position is to be crossed at the specified time.

W/U

52 CROSS [position] AT OR BEFORE [time]

The specified position is to be crossed at or before the specified time.

W/U

53 CROSS [position] AT OR AFTER [time]

The specified position is to be crossed at or after the specified time.

W/U

54 CROSS [position] BETWEEN [time] AND [time]

The specified position is to be crossed at a time between the specified times.

W/U

55 CROSS [position] AT [speed] The specified position is to be crossed at the specified speed and the specified speed is to be maintained until further advised.

W/U

56 CROSS [position] AT OR LESS THAN [speed]

The specified position is to be crossed at a speed equal to or less than the specified speed and the specified speed or less is to be maintained until further advised.

W/U

57 CROSS [position] AT OR GREATER THAN [speed]

The specified position is to be crossed at a speed equal to or greater than the specified speed and the specified speed or greater is to be maintained until further advised.

W/U

58 CROSS [position] AT [time] AT [altitude]

The specified position is to be crossed at the specified time and the specified level.

W/U

59 CROSS [position] AT OR BEFORE [time] AT [altitude]

The specified position is to be crossed at or before the specified time and at the specified level.

W/U

60 CROSS [position] AT OR AFTER [time] AT [altitude]

The specified position is to be crossed at or after the specified time and at the specified level.

W/U

61 CROSS [position] AT AND MAINTAIN [altitude] AT [speed]

Instruction that the specified position is to be crossed at the specified level and speed and the level and speed are to be maintained.

W/U

62 At [time] CROSS [position] AT AND MAINTAIN [altitude]

Instruction that at the specified time the specified position is to be crossed at the specified level and the level is to be maintained.

W/U

63 AT [time] CROSS [position] AT AND MAINTAIN [altitude] AT [speed]

Instruction that at the specified time the specified position is to be crossed at the specified level and speed and the level and speed are to be maintained.

W/U

APPENDIX A


Uplink - Lateral Offsets


64 OFFSET [direction] [distance offset] OF ROUTE

Instruction to fly a parallel track to the cleared route at a displacement of the specified distance in the specified direction.

W/U

65 AT [position] OFFSET [direction] [distance offset] OF ROUTE

Instruction to fly a parallel track to the cleared route at a displacement of the specified distance in the specified direction and commencing at the specified position.

W/U

66 AT [time] OFFSET [direction] [distance offset] OF ROUTE

Instruction to fly a parallel track to the cleared route at a displacement of the specified distance in the specified direction and commencing at the specified time.

W/U

67 PROCEED BACK ON ROUTE

The cleared flight route is to be rejoined. W/U

68 REJOIN ROUTE BY [position] The cleared flight route is to be rejoined at or before the specified position.

W/U

69 REJOIN ROUTE BY [time] The cleared flight route is to be rejoined at or before the specified time.

W/U

70 EXPECT BACK ON ROUTE BY [position]

Notification that a clearance may be issued to enable the aircraft to rejoin the cleared route at or before the specified position.

R

71 EXPECT BACK ON ROUTE BY [time] Notification that a clearance may be issued to enable the aircraft to rejoin the cleared route at or before the specified time.

R

72 RESUME OWN NAVIGATION Instruction to resume own navigation following a period of tracking or heading clearances. May be used in conjunction with an instruction on how or where to rejoin the cleared route.

W/U

Uplink - Route Modifications


73 [predepartureclearance]

Notification to the aircraft of the instructions to be followed from departure until the specified clearance limit.

W/U

74 PROCEED DIRECT TO [position] Instruction to proceed directly from the present position to the specified position.

W/U

75 WHEN ABLE PROCEED DIRECT TO [position]

Instruction to proceed, when able, directly to the specified position.

W/U

76 AT [time] PROCEED DIRECT TO [position]

Instruction to proceed, at the specified time, directly to the specified position.

W/U

77 AT [position] PROCEED DIRECT TO [position]

lnstruction to proceed, at the specified position, directly to the next specified position.

W/U

78 AT [altitude] PROCEED DIRECT TO [position]

Instruction to proceed, upon reaching the specified level, directly to the specified position.

W/U

APPENDIX A


Uplink - Route Modifications (Continued)

79 CLEARED TO [position] VIA [route

clearance] Instruction to proceed to the specified position via the specified route.

W/U

80 CLEARED [route clearance] Instruction to proceed via the specified route.

W/U

81 CLEARED [procedure name] Instruction to proceed in accordance with the specified procedure.

W/U

82 CLEARED TO DEVIATE UP TO [direction] [distance offset] OF ROUTE

Approval to deviate up to the specified distance from the cleared route in the specified direction.

W/U

83 AT [position] CLEARED [route clearance]

Instruction to proceed from the specified position via the specified route.

W/U

84 AT [position] CLEARED [procedure name]

Instruction to proceed from the specified position via the specified procedure.

W/U

85 EXPECT [route clearance] Notification that a clearance to fly on the specified route may be issued.

R

86 AT [position] EXPECT [route clearance]

Notification that a clearance to fly on the specified route from the specified position may be issued.

R

87 EXPECT DIRECT TO [position] Notification that a clearance to fly directly to the specified position may be issued.

R

88 AT [position] EXPECT DIRECT TO [position]

Notification that a clearance to fly directly from the first specified position to the next specified position may be issued.

R

89 AT [time] EXPECT DIRECT TO [position]

Notification that a clearance to fly directly to the specified position commencing at the specified time may be issued.

R

90 AT [altitude] EXPECT DIRECT TO [position]

Notification that a clearance to fly directly to the specified position commencing when the specified level is reached may be issued.

R

91 HOLD AT [position] MAINTAIN [altitude] INBOUND TRACK [degrees][direction] TURN LEG TIME [leg type]

Instruction to enter a holding pattern with the specified characteristics at the specified position and level.

W/U

92 HOLD AT [position] AS PUBLISHED MAINTAIN [altitude]

Instruction to enter a holding pattern with the published characteristics at the specified position and level.

W/U

93 EXPECT FURTHER CLEARANCE AT [time]

Notification that an onwards clearance may be issued at the specified time.

R

94 TURN [direction] HEADING [degrees]

Instruction to turn left or right as specified onto the specified heading.

W/U

95 TURN [direction] GROUND TRACK [degrees]

Instruction to turn left or right as specified onto the specified track.

W/U

96 FLY PRESENT HEADING

Instruction to continue to fly on the current heading.

W/U

97 AT [position] FLY HEADING [degrees]

Instruction to fly on the specified heading from the specified position.

W/U

98 IMMEDIATELY TURN [direction] HEADING [degrees]

Instruction to turn immediately left or right as specified onto the specified heading.

W/U

APPENDIX A


Uplink - Route Modifications (Continued)

99 EXPECT [procedure name] Notification that a clearance may be

issued for the aircraft to fly the specified procedure.

R

178 TRACK DETAIL MESSAGE

Message not defined.

Uplink - Speed Changes

UL MESSAGE ELEMENT MESSAGE INTENT RESPONSE100 AT [time] EXPECT [speed] Notification that a speed instruction may

be issued to be effective at the specified time.

R

101 AT [position] EXPECT [speed] Notification that a speed instruction may be issued to be effective at the specified position.

R

102 AT [altitude] EXPECT [speed]

Notification that a speed instruction may be issued to be effective at the specified level.

R

103 AT [time] EXPECT [speed] TO [speed]

Notification that a speed range instruction may be issued to be effective at the specified time.

R

104 AT [position] EXPECT [speed] TO [speed]

Notification that a speed range instruction may be issued to be effective at the specified position.

R

105 AT [altitude] EXPECT [speed] TO [speed]

Notification that a speed range instruction may be issued to be effective at the specified level.

R

106 MAINTAIN [speed]

The specified speed is to be maintained. W/U

107 MAINTAIN PRESENT SPEED

The present speed is to be maintained. W/U

108 MAINTAIN [speed] OR GREATER The specified speed or a greater speed is to be maintained.

W/U

109 MAINTAIN [speed] OR LESS The specified speed or a lesser speed is to be maintained.

W/U

110 MAINTAIN [speed] TO [speed] A speed within the specified range is to be maintained.

W/U

111 INCREASE SPEED TO [speed] The present speed is to be increased to the specified speed and maintained until further advised.

W/U

112 INCREASE SPEED TO [speed] OR GREATER

The present speed is to be increased to the specified speed or greater, and maintained at or above the specified speed until further advised.

W/U

113 REDUCE SPEED TO [speed] The present speed is to be reduced to the specified speed and maintained until further advised.

W/U

114 REDUCE SPEED TO [speed] OR LESS The present speed is to be reduced to the specified speed or less and maintained at or below the specified speed until further advised.

W/U

APPENDIX A


Uplink - Speed Changes (Continued)

115 DO NOT EXCEED [speed]

The specified speed is not to be exceeded.

W/U

116 RESUME NORMAL SPEED Notification that the aircraft need no longer comply with the previously issued speed restriction.

W/U

Uplink - Contact/Monitor/Surveillance Requests


117 CONTACT [icaounitname][frequency]

The pilot is required to call the ATS facility on the specified frequency.

W/U

118 AT [position] CONTACT [icaounitname] [frequency]

At the specified position the ATS unit with the specified ATS unit name is to be contacted on the specified frequency.

W/U

119 AT [time] CONTACT [icaounitname] [frequency]

At the specified time the ATS unit with the specified ATS unit name is to be contacted on the specified frequency.

W/U

120 MONITOR [icaounitname][frequency]

The pilot is required to monitor the specified ATS facility on the specified frequency. The Pilot is not required to check in.

W/U

121 AT [position] MONITOR [icaounitname] [frequency]

At the specified position the ATS unit with the specified ATS unit name is to be monitored on the specified frequency.

W/U

122 AT [time] MONITOR [icaounitname] [frequency]

At the specified time the ATS unit with the specified ATS unit name is to be monitored on the specified frequency.

W/U

123 SQUAWK [beacon code]

The specified code (SSR code) is to be selected.

W/U

124 STOP SQUAWK The SSR transponder responses are to be disabled.

W/U

125 SQUAWK ALTITUDE

The SSR transponder responses should include level information.

W/U

126 STOP ALTITUDE SQUAWK

The SSR transponder responses should no longer include level information.

W/U

179 SQUAWK IDENT The 'ident' function on the SSR transponder is to be actuated.

W/U

Uplink - Report/Confirmation Requests

UL MESSAGE ELEMENT MESSAGE INTENT RESPONSE127 REPORT BACK ON ROUTE Instruction to report when the aircraft is

back on the cleared route. R

128 REPORT LEAVING [altitude]

Instruction to report when the aircraft has left the specified level. Either a level that has been maintained, or a level passed through on climb or descent.

R

129 REPORT LEVEL [altitude]

Instruction to report when the aircraft is in level flight at the specified level. Note: To avoid confusion, Some States have decided that they will not use this element

R

APPENDIX A


Uplink - Report/Confirmation Requests (Continued)

175 REPORT REACHING [altitude]

Instruction to report when the aircraft has reached the specified level. To be interpreted as “Report reaching an assigned level.”

R

180 REPORT REACHING BLOCK [altitude] TO [altitude]

Instruction to report when the aircraft is within the specified vertical range.

R

130 REPORT PASSING [position] Instruction to report when the aircraft has passed the specified position.

R

181 REPORT DISTANCE [to/from] [position]

Instruction to report the present distance to or from the specified position.

NE

131 REPORT REMAINING FUEL AND SOULS ON BOARD

Instruction to report the amount of fuel remaining and the number of persons on board.

NE

132 CONFIRM POSITION

Instruction to report the present position. NE

133 CONFIRM ALTITUDE

Instruction to report the present level. NE

134 CONFIRM SPEED

Instruction to report the present speed. NE

135 CONFIRM ASSIGNED ALTITUDE

Instruction to confirm and acknowledge the currently assigned level.

NE

136 CONFIRM ASSIGNED SPEED Instruction to confirm and acknowledge the currently assigned speed.

NE

137 CONFIRM ASSIGNED ROUTE Instruction to confirm and acknowledge the currently assigned route.

NE

138 CONFIRM TIME OVER REPORTED WAYPOINT

Instruction to confirm the previously reported time over the last reported waypoint.

NE

139 CONFIRM REPORTED WAYPOINT Instruction to confirm the identity of the previously reported waypoint.

NE

140 CONFIRM NEXT WAYPOINT Instruction to confirm the identity of the next waypoint.

NE

141 CONFIRM NEXT WAYPOINT ETA Instruction to confirm the previously reported estimated time at the next waypoint.

NE

142 CONFIRM ENSUING WAYPOINT Instruction to confirm the identity of the next plus one waypoint.

NE

143 CONFIRM REQUEST The request was not understood. It should be clarified and resubmitted.

NE

144 CONFIRM SQUAWK Instruction to report the currently selected transponder code.

NE

145 CONFIRM HEADING

Instruction to report the present heading. NE

146 CONFIRM GROUND TRACK

Instruction to report the present ground track.

NE

182 CONFIRM ATIS CODE Instruction to report the identification code of the last ATIS received.

NE

147 REQUEST POSITION REPORT

Instruction to make a position report. To be used if the controller does not receive a scheduled position report.

NE

APPENDIX A


Uplink - Negotiation Requests

UL MESSAGE ELEMENT MESSAGE INTENT RESPONSE148 WHEN CAN YOU ACCEPT [altitude]

Request for the earliest time at which the specified level can be accepted.

NE

149 CAN YOU ACCEPT [altitude] AT [position]

Instruction to report whether or not the specified level can be accepted at the specified position.

A/N

150 CAN YOU ACCEPT [altitude] AT [time]

Instruction to report whether or not the specified level can be accepted at the specified time.

A/N

151 WHEN CAN YOU ACCEPT [speed] Instruction to report the earliest time when the specified speed can be accepted.

NE

152 WHEN CAN YOU ACCEPT [direction] [distance offset] OFFSET

Instruction to report the earliest time when the specified offset track can be accepted.

NE

Uplink - Air Traffic Advisories

UL MESSAGE ELEMENT MESSAGE INTENT RESPONSE153 ALTIMETER [altimeter] ATS advisory that the altimeter setting

should be the specified setting. R

154 RADAR SERVICES TERMINATED

ATS advisory that the radar service is terminated.

R

155 RADAR CONTACT [position] ATS advisory that radar contact has been established at the specified position.

R

156 RADAR CONTACT LOST ATS advisory that radar contact has been lost.

R

157 CHECK STUCK MICROPHONE [frequency]

A continuous transmission is detected on the specified frequency. Check the microphone button.

R

158 ATIS [atis code] ATS advisory that the ATIS information identified by the specified code is the current ATIS information.

R

Uplink - System Management Messages

UL MESSAGE ELEMENT MESSAGE INTENT RESPONSE159 ERROR [error information] A system generated message that the

ground system has detected an error. NE

160 NEXT DATA AUTHORITY [facility designation]

Notification to the avionics that the next data authority is the specified ATSU.

NE

161 END SERVICE Notification to the avionics that the data link connection with the current data authority is being terminated.

NE

162 SERVICE UNAVAILABLE Notification that the ground system does not support this message.

NE

163 [icao facility designation] [tp4Table]

Notification to the pilot of an ATSU identifier.

NE

APPENDIX A


Uplink - Additional Messages

UL MESSAGE ELEMENT MESSAGE INTENT RESPONSE164 WHEN READY The associated instruction may be

complied with at any future time. NE

165 THEN Used to link two messages, indicating the proper order of execution of clearances or instructions.

NE

166 DUE TO TRAFFIC

The associated instruction is issued due to traffic considerations.

NE

167 DUE TO AIRSPACE RESTRICTION The associated instruction is issued due to airspace restrictions.

NE

168 DISREGARD The indicated communication should be ignored. The previously sent uplink CPDLC message shall be ignored. DISREGARD should not refer to a clearance or instruction. If DISREGARD is used, another element shall be added to clarify which message is to be disregarded.

R

176 MAINTAIN OWN SEPARATION AND VMC

Notification that the pilot is responsible for maintaining separation from other traffic and is also responsible for maintaining Visual Meteorological Conditions.

W/U

177 AT PILOTS DISCRETION Used in conjunction with a clearance or instruction to indicate that the pilot may execute when prepared to do so.

N

169 [free text]

Normal urgency attribute R

170 [free text]

Distress urgency attribute R

APPENDIX A


Downlink Messages Downlink - Responses

DL MESSAGE ELEMENT MESSAGE INTENT RESPONSE0 WILCO

The instruction is understood and will be complied with.

N

1 UNABLE The instruction cannot be complied with.

N

2 STANDBY

Wait for a reply. The controller is informed that the request is being assessed and there will be a short term delay (within 10 minutes). The exchange is not closed and the request will be responded to when conditions allow.

N

3 ROGER

Message received and understood. ROGER is the only correct response to an uplink free text message. Under no circumstances will ROGER be used instead of AFFIRM.

N

4 AFFIRM

Yes AFFIRM is an appropriate response to an uplinked negotiation request message (e.g. CAN YOU ACCEPT [altitude] AT [time]).

N

5 NEGATIVE

No NEGATIVE is an appropriate response to an uplinked negotiation request message (e.g. CAN YOU ACCEPT [altitude] AT [time]).

N

Downlink - Vertical Requests

DL MESSAGE ELEMENT MESSAGE INTENT RESPONSE6 REQUEST [altitude]

Request to fly at the specified level. Y

7 REQUEST BLOCK [altitude] TO [altitude]

Request to fly at a level within the specified vertical range.

Y

8 REQUEST CRUISE CLIMB TO [altitude] Request to cruise climb to the specified level.

Y

9 REQUEST CLIMB TO [altitude]

Request to climb to the specified level. Y

10 REQUEST DESCENT TO [altitude]

Request to descend to the specified level. Y

11 AT [position] REQUEST CLIMB TO [altitude]

Request that at the specified position a climb to the specified level be approved.

Y

12 AT [position] REQUEST DESCENT TO [altitude]

Request that at the specified position a descent to the specified level be approved.

Y

13 AT [time] REQUEST CLIMB TO [altitude]

Request that at the specified time a climb to the specified level be approved.

Y

14 AT [time] REQUEST DESCENT TO [altitude]

Request that at the specified time a descent to the specified level be approved.

Y

APPENDIX A


Downlink - Lateral Off-Set Requests

DL MESSAGE ELEMENT MESSAGE INTENT RESPONSE15 REQUEST OFFSET [direction]

[distance offset] OF ROUTE

Request that a parallel track, offset from the cleared track by the specified distance in the specified direction, be approved.

Y

16 AT [position] REQUEST OFFSET [direction] [distance offset] OF ROUTE

Request that a parallel track, offset from the cleared track by the specified distance in the specified direction, be approved from the specified position.

Y

17 AT [time] REQUEST OFFSET [direction] [distance offset] OF ROUTE

Request that a parallel track, offset from the cleared track by the specified distance in the specified direction, be approved from the specified time.

Y

Downlink - Speed Requests

DL MESSAGE ELEMENT MESSAGE INTENT RESPONSE18 REQUEST [speed]

Request to fly at the specified speed. Y

19 REQUEST [speed] TO [speed] Request to fly within the specified speed range.

Y

Downlink - Voice Contact Requests

DL MESSAGE ELEMENT MESSAGE INTENT RESPONSE20 REQUEST VOICE CONTACT

Request for voice contact. Y

21 REQUEST VOICE CONTACT [frequency]

Request for voice contact on the specified frequency.

Y

Downlink - Route Modification Requests

DL MESSAGE ELEMENT MESSAGE INTENT RESPONSE22 REQUEST DIRECT TO [position] Request to track from the present position

direct to the specified position. Y

23 REQUEST [procedure name]

Request for the specified procedure clearance.

Y

24 REQUEST [route clearance]

Request for a route clearance. Y

25 REQUEST CLEARANCE

Request for either a pre-departure or route clearance.

Y

26 REQUEST WEATHER DEVIATION TO [position] VIA [route clearance]

Request for a weather deviation to the specified position via the specified route.

Y

27 REQUEST WEATHER DEVIATION UP TO [direction] [distance offset] OF ROUTE

Request for a weather deviation up to the specified distance off track in the specified direction.

Y

70 REQUEST HEADING [degrees] Request a clearance to adopt the specified heading.

Y

71 REQUEST GROUND TRACK [degrees] Request a clearance to adopt the specified ground track.

Y

APPENDIX A


Downlink - Reports

DL MESSAGE ELEMENT MESSAGE INTENT RESPONSE28 LEAVING [altitude]

Notification of leaving the specified level. N

29 CLIMBING TO [altitude]

Notification of climbing to the specified level.

N

30 DESCENDING TO [altitude]

Notification of descending to the specified level.

N

31 PASSING [position] Notification of passing the specified position.

N

78 AT [time] [distance] [to/from] [position]

At the specified time, the aircraft's position was as specified.

N

32 PRESENT ALTITUDE [altitude]

Notification of the present level. N

33 PRESENT POSITION [position]

Notification of the present position. N

34 PRESENT SPEED [speed]

Notification of the present speed. N

35 PRESENT HEADING [degrees] Notification of the present heading in degrees.

N

36 PRESENT GROUND TRACK [degrees] Notification of the present ground track in degrees.

N

37 LEVEL [altitude]

Notification that the aircraft is maintaining the specified level.

N

72 REACHING [altitude]

Notification that the aircraft has reached the specified level.

N

76 REACHING BLOCK [altitude] TO [altitude]

Notification that the aircraft has reached a level within the specified vertical range.

N

38 ASSIGNED ALTITUDE [altitude]

Read-back of the assigned level. N

77 ASSIGNED BLOCK [altitude] TO [altitude]

Read-back of the assigned vertical range. N

39 ASSIGNED SPEED [speed]

Read-back of the assigned speed. N

40 ASSIGNED ROUTE [route clearance]

Read-back of the assigned route. N

41 BACK ON ROUTE The aircraft has regained the cleared route.

N

42 NEXT WAYPOINT [position] The next waypoint is the specified position.

N

43 NEXT WAYPOINT ETA [time] The ETA at the next waypoint is as specified.

N

44 ENSUING WAYPOINT [position] The next plus one waypoint is the specified position.

N

45 REPORTED WAYPOINT [position] Clarification of previously reported waypoint passage.

N

46 REPORTED WAYPOINT [time] Clarification of time over previously reported waypoint.

N

47 SQUAWKING [beacon code]

The specified (SSR) code has been selected.

N

APPENDIX A


Downlink – Reports (Continued)

48 POSITION REPORT [position report]

Reports the current position of the aircraft when the pilot presses the button to send this message. ATC expects position reports based on this downlink message

N

79 ATIS [atis code] The code of the latest ATIS received is as specified.

N

80 DEVIATING [direction] [distance offset] OF ROUTE

Notification that the aircraft is deviating from the cleared route by the specified distance in the specified direction.

N

Downlink - Negotiation Requests

DL MESSAGE ELEMENT MESSAGE INTENT RESPONSE49 WHEN CAN WE EXPECT [speed] Request for the earliest time at which a

clearance to the specified speed can be expected.

Y

50 WHEN CAN WE EXPECT [speed] TO [speed]

Request for the earliest time at which a clearance to a speed within the specified range can be expected.

Y

51 WHEN CAN WE EXPECT BACK ON ROUTE

Request for the earliest time at which a clearance to regain the planned route can be expected.

Y

52 WHEN CAN WE EXPECT LOWER ALTITUDE

Request for the earliest time at which a clearance to descend can be expected.

Y

53 WHEN CAN WE EXPECT HIGHER ALTITUDE

Request for the earliest time at which a clearance to climb can be expected.

Y

54 WHEN CAN WE EXPECT CRUISE CLIMB TO [altitude]

Request for the earliest time at which a clearance to cruise climb to the specified level can be expected.

Y

Downlink - Emergency Messages

DL MESSAGE ELEMENT MESSAGE INTENT RESPONSE55 PAN PAN PAN

Urgency prefix. N

56 MAYDAY MAYDAY MAYDAY

Distress prefix. N

57 [remaining fuel] OF FUEL REMAINING AND [souls on board] SOULS ON BOARD

Notification of fuel remaining and number of persons on board.

N

58 CANCEL EMERGENCY Notification that the pilot wishes to cancel the emergency condition.

N

59 DIVERTING TO [position] or DIVERTING TO [position] VIA [x]

Notification that the aircraft is diverting to the specified position via the specified route.

N

60 OFFSETTING [direction] [distance offset] OF ROUTE

Notification that the aircraft is deviating the specified distance in the specified direction off the cleared route and maintaining a parallel track.

N

61 DESCENDING TO [altitude]

Notification that the aircraft is descending to the specified level.

N

APPENDIX A


Downlink - System Management Messages

DL MESSAGE ELEMENT MESSAGE INTENT RESPONSE 2 RROR [error information] system generated message that the

avionics has detected an error. N

3 OT CURRENT DATA AUTHORITY system generated denial to any CPDLC message sent from a ground facility that is not the Current Data Authority.

N

4 cao facility designation] otification to the ground system that the specified ATSU is the current data authority.

N

3 version number] system generated message indicating the software version number.

N

Downlink - Additional Messages

DL MESSAGE ELEMENT MESSAGE INTENT RESPONSE65 DUE TO WEATHER Used to explain reasons for aircraft

operator’s message. N

66 DUE TO AIRCRAFT PERFORMANCE Used to explain reasons for aircraft operator's message.

N

74 MAINTAIN OWN SEPARATION AND VMC States a desire by the pilot to provide his/her own separation and remain in VMC.

N

75 AT PILOTS DISCRETION Used in conjunction with another message to indicate that the pilot wishes to execute the request when the pilot is prepared to do so.

N

67 [free text]

Normal urgency attribute N

67b

WE CAN ACCEPT [altitude] AT [time] We can accept the specified level at the specified time.

N

67c WE CAN ACCEPT [speed] AT [time]

We can accept the specified speed at the specified time.

N

67d

WE CAN ACCEPT [direction] [distance offset] AT [time]

We can accept a parallel track offset the specified distance in the specified direction at the specified time.

N

67e WE CANNOT ACCEPT [altitude]

We cannot accept the specified level. N

67f WE CANNOT ACCEPT [speed]

We cannot accept the specified speed. N

67g

WE CANNOT ACCEPT [direction] [distance offset]

We cannot accept a parallel track offset the specified distance in the specified direction.

N

67h

WHEN CAN WE EXPECT CLIMB TO [altitude]

Request for the earliest time at which a clearance to climb to the specified level can be expected.

N

67i WHEN CAN WE EXPECT DESCENT TO [altitude]

Request for the earliest time at which a clearance to descend to the specified level can be expected.

N

68 [free text]

Distress urgency attribute Y

APPENDIX B


APPENDIX B

ADS REPORT DATA (*): On request

GROUP PARAMETERS Basic ADS group

(Required) - Current latitude - Current longitude - Current STD altitude - UTC Time stamp - Navigation redundancy bit:

set to 1 if two or more IRS are providing valid position to the FMS, else, set to 0

- Figure of merit: level (0-7), which reflects the accuracy of the reported position

- TCAS health: set to 1 if valid data, else to 0 Earth Reference

Group (*)

- True Track - Ground Speed - Inertial Vertical Rate

Air Reference Group(*)

- Current True Heading - Mach - Inertial Vertical Rate

Airframe Ident Group(*)

- 24 bit ICAO code (Not provided in FANS A)

Flight Ident Group(*)

- Flight ID

Meteorological Group(*)

- Wind Speed - True Wind Direction - Static Air Temperature

Predicted Route Group(*)

- Latitude at next waypoint - Longitude at next waypoint - STD altitude at next waypoint - Estimated Time to Go (ETG) to next waypoint - Latitude at Next +1 waypoint - Longitude at Next+1 waypoint - STD altitude at Next+1 waypoint

Fixed Intent Group(*)

- Latitude of fixed projected point - Longitude of fixed projected point - STD altitude of fixed projected point - Projected time:

Travel time to the fixed intent point along the active route Intermediate

Projected Intent Group(*)

- Distance: . from current a/c position to the first intermediate projected point . from the previous intermediate projected point, for the

subsequent points - Track::

. from current a/c position to the first intermediate projected point

. from the previous intermediate projected point, for the subsequent points

- STD altitude of the intermediate projected point Projected Time: Estimated Time to Go (ETG) to the intermediate projected point

Output values of the parameters of the ADS messages

APPENDIX B


PARAMETER

VALID RANGE

DEFAULT VALUE (1)

SIGNIFICANT BITS (7)

DEFINED MSB VALUE (2)

APPROX. LSB VALUE

Latitude ±90° (Note 3) 20 & sign 90° 0.000172° Longitude ±180° (Note 3) 20 & sign 90° 0.000172° Altitude ±131,068 feet -131,072 feet 15 & sign 65,536 feet 4 feet Time Stamp (Note 8)

0 - 3599.875 sec FOM = 0 (Note 9)

15 2048 sec. 0.125 sec.

Flight ID Alphanumeric Space (Note 4)

6 per character (Note 5)

N/A N/A

Mach 0 - 4.095 mach 4.0955 mach 13 2.048 mach 0.0005 mach Ground Speed 0 - 4095 knots 4095.5 knots 13 2048 knots 0.5 knots Wind Speed 0 - 255 knots 255.5 knots 9 128 knots 0.5 knots True Wind Direction

-180 - +179.296875° Valid bit = 1 (Note 6)

8 & sign & valid 90° .703125°

Vertical Rate ±32,752 ft/min -32,768 ft/min

11 & sign 16,384 ft/min 16 ft/min

Temperature ±511.75°C -512°C 11 & sign 256°C 0.25°C True Track Angle -180 - +179.912° Valid bit = 1

(Note 6) 11 & sign & valid

90°

0.08789°

True Heading -180 - +179.912° Valid bit = 1 (Note 6)

11 & sign & valid

90°

0.08789°

Distance 0 - 8191.750 nm 8191.875 nm 16 4096 nm 0.125 nm ETA 0 - 16382 sec 16383 sec 14 8192 sec 1 sec Projected Time 0 - 16382 sec 16383 sec 14 8192 sec 1 sec

NOTES: 1. When no value is available or the value available to the ADS is invalid, a

default value shall be inserted in the field. The values shown here reflect a coding of all "ones".

2. The value of the Most Significant Bit (MSB) is accurate by definition. The value of the Least Significant Bit (LSB) is an approximation.

3. When either the latitude or the longitude for a position are invalid, both shall be set to -180°. In the Basic ADS Group, the FOM shall also be set to 0.

4. When the Flight Identification is invalid, all characters shall be encoded as spaces. When the Flight Identification is less than eight characters, the Flight Identification shall be encoded left justified and the unused characters shall be encoded as spaces.

5. The character set for the Flight Identification Group shall be ISO 5, without the most significant bit. This allows the characters to be encoded using only six bits. Valid characters are contained in the following sets: (A..Z), (0..9) and ( ).

6. The validation of the direction parameter shall be indicated by the immediately preceding bit, where 0 = valid and 1 = invalid.

7. Signed numerical values shall be represented in two's complement notation. 8. The time stamp shall be expressed as the time elapsed since the most

recent hour. Time shall be rounded, not truncated, to accurately yield the value loaded into the time stamp field.

APPENDIX C


APPENDIX C

DATA COMMUNICATIONS SERVICE PROVIDERS

A) INMARSAT - Aeronautical global and spot beam coverage

B) ARINC - VHF datalink coverage - VHF coverage - HFDL coverage

C) SITA - VDL coverage

APPENDIX C

13


INMARSAT

APPENDIX C

ARINC - VHF Data Link Coverage

North America

ARINC VDL COVERAGE


APPENDIX C

13

ARINC - VHF Coverage

ARINC VHF COVERAGE


APPENDIX C

ARINC - HFDL Coverage

ARINC HFDL COVERAGE


APPENDIX C

14

SITA - Americas coverage Altitude 30 000 feet / On-line RGS are in red, planned are in blue

SITA VDL COVERAGE


APPENDIX C


SITA - Europe, Africa and Middle-East coverage

Altitude 30 000 feet / On-line RGS are in red, planned are in blue

APPENDIX C


SITA - Asia Pacific coverage Altitude 30 000 feet / On-line RGS are in red, planned are in blue

GES Inmarsat Satellite

Country Location Code (Octal) Name Code

Telecom Providers for voice/fax

communications

Service provider for SATCOM

datalink SKYPHONE CONSORTIUM

101 AOR/E 01 UK Goonhilly 001 AOR/W 00 British Telecom ARINC

310 IOR 03 Singapore Sentosa 201 POR 02 Singapore Telecom ARINC

SATELLITE AIRCOM CONSORTIUM 305 IOR 03 Australia Perth 205 POR 02 TELSTRA SITA

103 AOR/E 01 France Aussaguel 005 AOR/W 00 France Telecom SITA

SKYWAYS ALLIANCE 004 AOR/W 00 104 AOR/E 01 Norway Eik 301 IOR 03

Norwegian Telecom ARINC

312 IOR 03 Italy Fucino 105 AOR/E 01 Telecom Italia NONE

USA Southbury 002 AOR/W 00 COMSAT ARINC

USA Santa Paula 202 POR 02 COMSAT ARINC 306 IOR 03 Japan Yamaguchi 203 POR 02 KDD AVICOM

Thailand Nonthaburi 302 IOR 03 CAT AEROTHAI MTSAT Satellites (expected availability end 2004)

Japan Kobe 161 MTSAT 07 JCAB (GES operator) SITA (Provider)

SITA (AOC Messages) JCAB (ATS Messages)

APPENDIX D : SATCOM OPERATORS

APPENDIX E


APPENDIX E

FANS OPERATIONAL PROCEDURES

1) Pacific FANS operations 2) Indian Ocean FANS operations 3) North Atlantic FANS operations

A) CPDLC procedures B) ADS procedures

4) South Atlantic FANS operations (Trials) 5) New York Oceanic (KZWY) CPDLC service area

APPENDIX E


E.1 - PACIFIC FANS OPERATIONS This appendix provides information of FANS A datalink operations in the Pacific area:

- Japan - Australia - Fiji - New Zealand - Tahiti - United States

All the following information are based on the Pacific Operation Manual (v1.1) available on the FAA web site (Oceanic Procedures Branch): http://www1.faa.gov/ats/ato/130.htm 1. ATSU Designators 1.1 ICAO The Pacific ICAO facility designations (called also “4 character ICAO code”) are:

ATS Units ICAO Facility Designation Anchorage PAZA Auckland NZZO

Brisbane YBBB Melbourne YMMM

Nadi NFFF Oakland KZAK Tahiti NTTT Tokyo RJTG

1.2 ACARS ADDRESSES The following indicates the ATS Unit addresses lodged in the ACARS system, for the Pacific: ATS System ATSU Address OCS – Anchorage ANCXFXA OCS – Auckland AKLCDYA TAATS – Brisbane BNECAYA TAATS – Melbourne MELCAYA Eurocat 2000X – Nadi NANCDYA ODL – Oakland OAKODYA VIVO – Tahiti PPTCDYA ODP-3 – Tokyo TYOTGYA

APPENDIX E


2 HF Voice Communications Requirements a) Pre-Departure All South Pacific ATS Units require a SELCAL check prior to departure. In the North and Central Pacific only those aircraft, including aircraft equipping with FANS A datalink, intending to operate in the North and Central Pacific airspace using a Selective Calling System (SELCAL) to fulfil communications listening watch requirements, should conduct a SELCAL check prior to departure. b) Crossing International FIR Boundaries When entering a Pacific FIR from an adjacent international FIR and CPDLC is serviceable, the HF instruction CONTACT or MONITOR datalink message shall be sent as detailed below: FIR HF Instruction Anchorage Oceanic CONTACT PAZA CENTRE [frequency] Auckland Oceanic CONTACT NZZO CENTRE [frequency] Brisbane CONTACT YBBB CENTRE [frequency] Melbourne CONTACT YMMM CENTRE [frequency] Nadi CONTACT NFFF CENTRE [frequency] Oakland CONTACT KSFO CENTRE [frequency]

KSFO (San Francisco Radio) will provide all primary and secondary HF frequencies, and HF transfer points along the route of flight.

Tahiti CONTACT NTTT CENTRE [frequency] A SELCAL check is required.

Tokyo CONTACT TOKYO CENTRE [frequency] c) CPDLC Services Within The Tokyo FIR Initial notification of emergency status may be accepted by CPDLC. Depending on the nature of the emergency condition experienced, the pilot should notify ATC of the circumstances by the most efficient means (voice or CPDLC). Clearances/instructions relating to cruise climb are not issued within the Tokyo FIR. Therefore, downlink request DL #8 “REQUEST CRUISE CLIMB TO [ level ]” should not be used. Pre-formatted messages regarding route modifications, including route clearance are not able to be uplinked. These messages include UL #79, 80, 81, 83, 84, 85 and 86 (detailed in appendix A). The route clearance should, therefore be requested and issued by HF or VHF voice communication. Special and other non-routine aircraft observation, i.e. moderate turbulence (transonic and supersonic aircraft only), severe turbulence, and volcanic activity should be reported by HF or VHF voice communication. Flight information services will be provided by HF or VHF voice communication.

APPENDIX E


d) Logon Procedures within the Tokyo FIR Datalink-equipped aircraft inbound from non-datalink airspace or radar airspace to Tokyo Oceanic Controlled airspace are required to log on between 15 and 45 minutes prior to entering datalink airspace within the Tokyo FIR. On initial contact with Tokyo Radio, the pilot should inform Tokyo Radio that they have the CPDLC connection using the voice phraseology “WE HAVE CPDLC CONNECTION”, and should downlink a CPDLC position report. Datalink-equipped aircraft inbound from the Anchorage FIR or Oakland FIR to Tokyo Oceanic Controlled airspace will be automatically transferred to “RJTG” by Anchorage or Oakland. If the process is not successful and “RJTG” is not the active centre, the pilot shall, within 5 minutes after crossing the Tokyo and Anchorage/Oakland common FIR boundary, terminate the connection by selecting ATC datalink off, then log on with “RJTG”. Once a CPDLC connection has been established with “RJTG (Tokyo ACC)”, the pilot should inform Tokyo Radio that they have the CPDLC connection using the voice, and should downlink a CPDLC position report.

3 Differences of Use of FANS A Messages The Pacific States listed in the box on the right do NOT use these two messages.

33 UL Cruise [altitude] Australia, Fiji, Japan, New Zealand, and Tahiti do not use this message.

129 UL Report level[altitude] Australia, Fiji, Japan, New Zealand, Tahiti and the United States do not to use this message

4 Position Reporting Requirements: CPDLC and ADS Environments The table below lists the position reporting requirements of individual ATS Units in the Pacific.

ATC Reporting Requirements Anchorage Does not accept CPDLC position reports in lieu of HF

voice Auckland Requires an initial CPDLC position report at the FIR

boundary entry point, then ADS reporting only. Brisbane Requires an initial CPDLC position report at the FIR

boundary entry point, then ADS reporting only. Melbourne Requires an initial CPDLC position report at the FIR

boundary entry point, then ADS reporting only. Nadi Currently accepts CPDLC position reports. Following the

commissioning of the EASY system Fiji will require an initial CPDLC position report at the FIR boundary entry point, then ADS reporting only.

Oakland Accepts CPDLC position reports in lieu of HF voice. Tahiti Accepts CPDLC position reports. Controllers will send a

free text request for an FIR boundary estimate for outbound flights.

Tokyo Accepts CPDLC position reports in lieu of HF voice.

APPENDIX E


E.2 - INDIAN OCEAN FANS OPERATIONS

All the following information is based on the Indian Ocean Operation Manual (v1.0) available on the following web site http://members.optusnet.com.au/~cjr/index.html HF Voice Communications Requirements • HF SELCAL Check All Indian Ocean ATCs, except Australia, require a SELCAL check. • Crossing International FIR Boundaries When entering an Indian Ocean FIR from an adjacent international FIR and CPDLC is serviceable, the HF instruction CONTACT or MONITOR datalink message shall be sent as detailed below: FIR HF Instruction Antananarivo CONTACT FMMM CENTRE [frequency] Brisbane CONTACT YBBB CENTRE [frequency] Melbourne CONTACT YMMM CENTRE [frequency] Johannesburg CONTACT FAJO CENTRE [frequency] Seychelles CONTACT FSSS CENTRE [frequency] • Differences of Use of FANS A Messages The Indian Ocean States use the following FANS A messages as detailed below:

33 UL Cruise [altitude] Australia, South Africa and Madagascar do not use this message.

129 UL Report level[altitude] Australia does not use this message in order to avoid confusion because it does not comply with voice phraseology.

• Position Reporting Requirements: CPDLC and ADS Environments The following table lists the position reporting requirements of individual ATCs in the Indian Ocean.

ATC Reporting Requirements Antananarivo Johannesburg Brisbane Melbourne Seychelles

Requires an initial CPDLC position report at the FIR boundary entry point, then ADS reporting only.

http://members.optusnet.com.au/~cjr/index.html

APPENDIX E


• Class G airspace procedures: MELBOURNE FIR Some specific procedures apply for flight operating the Indian Ocean portion of the Melbourne FIR south of Latitude 45 South (Class G airspace). Despite operating in a Traffic Information only when south of 45 South, flight crew should still send CPDLC requests for changes of level and/or amended tracking that will apply to route segments wholly within Class G airspace. This action will update the controller flight data record, ensuring that the most accurate information is presented to the controller. These specific procedures (level changes, route clearance request…) are detailed in the “Indian Ocean Operations Manual”, Part 8, which can be obtained from Airservices Australia (www.airservices.gov.au).

APPENDIX E


E.3 - NORTH ATLANTIC FANS OPERATIONS

All the following information are based on the “ATS Data link Services in NAT Airspace” Version 7.0. This document is available on the NAT PCO web site: www.nat-pco.org

1. CPDLC PROCEDURES 1.1 Flight Planning • The aircraft registration is required in Field 18 of the ATC flight plan. If the aircraft

registration is missing, or different from that contained in the AFN CONTACT message, the ground system will not establish a CPDLC connection with that aircraft.

• Hyphens contained in an aircraft registration must not be entered into the ICAO flight plan form.

1.2 Air Traffic Control • Where CPDLC-related voice communications are required, utilise the appropriate

phraseology as detailed in Appendix A. • When CPDLC fails and communications revert to voice, all open messages should

be considered not delivered and any dialogues involving those messages should be re-commenced by voice.

• Initiate voice contact to clarify the meaning or intent if an unexpected or

inappropriate response is received to an uplink message. • Immediately revert to voice communications if at any time it appears that there is a

misunderstanding about the intent of a CPDLC dialogue. • If possible, all open messages should be closed, regardless of any associated voice

communications. These responses should be consistent with the voice communication, in order to prevent confusion.

• Up to five message elements can be sent within the same message, but the number

of elements should be kept to a minimum. Messages should not include ATC clearances or instructions that are not dependent on one another. Misunderstanding could result if only part of such a message could be complied with.

• If the controller becomes aware that the AFN to the NDA is not successful, the

controller should instruct the aircraft to manually initiate an AFN with the next ATC Do not re-send the NDA message. - Co-ordinate with the next ATC, establishing clearly when or where the aircraft will

be instructed to initiate AFN with that unit. - The AFN instruction should be timed to allow the next ATC to establish an Active

CPDLC connection prior to the aircraft’s crossing the common boundary. Note that this process will terminate the current CPDLC connection.

APPENDIX E


• Do not include any other message element with the END SERVICE message. • Appropriate responses to any received downlink messages should be sent prior to

sending the END SERVICE message. • If an NDA was established, co-ordinate with that ATC regarding any CPDLC uplink

messages that were open at the time the END SERVICE message was sent. 1.3 Flight Crew – General The following procedures apply to all Phases of CPDLC Operational Trials. • When initialising the FMC, it is essential to ensure that the aircraft identification/call-

sign/flight ID matches the one displayed in the filed ATC flight plan. If the aircraft identification/call-sign/flight ID and registration contained in the AFN CONTACT message do not match what is provided in the flight plan, the AFN will be rejected.

• In the Shanwick FIR, the AFN will be rejected unless the oceanic clearance has

been issued to the flight. As well, the Shanwick system will reject AFN from westbound flights proceeding into or transiting the Madrid FIR, because the limited benefit for such flights does not justify the workload associated with providing CPDLC services to them.

• If an AFN is rejected:

a) check whether the aircraft identification/call-sign/flight ID in the FMC matches the aircraft identification/call-sign/flight ID provided in the flight plan and make corrections if necessary;

b) check whether the aircraft registration matches the aircraft registration provided in the flight plan, and arrange for the flight plan to be modified, if necessary;

c) attempt another AFN after receipt of the oceanic clearance; or d) do not attempt another AFN if the flight is westbound in the Shanwick FIR and

will proceed into or transit the Madrid FIR.

• If entering CPDLC or ADS airspace via departure from an airport adjacent to, or underlying the airspace, initiate AFN with the appropriate ATC prior to departure.

• If entering a CPDLC OCA/FIR from adjacent airspace where no CPDLC connections

have been established, initiate AFN to the CPDLC ATC between 15 and 45 minutes prior to entering the CPDLC OCA/FIR.

• If, after initiating an AFN, the Active Centre does not match the ATC specified during

the Logon, the flight crew should clarify the situation via voice. • CPDLC transfers to adjacent ATCs offering CPDLC services will be automatic.

APPENDIX E


• When exiting a CPDLC OCA/FIR into a non-CPDLC OCA/FIR flight crews should

expect the Active Centre to terminate the CPDLC connection, leaving the aircraft with no CPDLC connectivity. If entering a subsequent CPDLC OCA/FIR, crews should initiate an AFN to the CPDLC ATC between 15 and 45 minutes prior to entering the CPDLC OCA/FIR.

• Unless otherwise instructed, flight crews should revert to voice communications

while transiting non-CPDLC OCA/FIRs. Crews should note that an active CPDLC connection may be established with the next CPDLC OCA/FIR well before entering that OCA/FIR. Such connections should not be utilised except in highly unusual or emergency situations.

• Where CPDLC-related voice communications are required, utilise the appropriate

phraseology as detailed in Appendix A. • Initial contact and SELCAL check (if SELCAL will be used to monitor HF) with the

appropriate aeradio station are essential requirements prior to entering oceanic airspace and each OCA/FIR along the route of flight.

• If no domestic frequency assignment has been received by 10 minutes prior to the

flight’s entry into domestic airspace, contact aeradio and request the frequency, stating the oceanic exit fix.

• Flight crews should be aware of paragraph 5.4.6 concerning END SERVICE. For

this reason, it is important to respond to uplink messages promptly and appropriately, particularly when approaching a FIR boundary. It should be noted that if any uplink messages are open when the END SERVICE message is sent, the CPDLC connections to both the CDA and NDA will be terminated.

• If unable to continue using CPDLC, flight crews should revert to voice procedures. • Flight crews should be aware of the Expected Responses to particular downlink

message elements listed in Appendix A. If one of the Expected Responses is not received, the flight crew should initiate voice contact to clarify the situation.

• All open messages should be closed, regardless of any associated voice communications. These responses should be consistent with the voice communication, in order to prevent confusion.

APPENDIX E


1.4 Flight Crew –Contact with Aeradio The integrity of the ATC service remains wholly dependent on establishing and maintaining HF or VHF voice communications. During implementation of CPDLC, specific Air Traffic Service Providers may be in various stages of development and testing. • Prior to entering each oceanic CTA, the pilot shall contact the appropriate aeradio

station. • If the flight will exit the CTA into oceanic airspace, on initial contact the pilot shall:

a) use the term “C-P-D-L-C” after the aircraft call sign; b) state the name of the next OCA/FIR to be entered; and c) request the SELCAL check.

Example: KLM634 C-P-D-L-C, SHANWICK NEXT, REQUEST SELCAL CHECK CDAB. Expect to either receive the frequencies for the stated OCA/FIR or to be advised about the frequencies that will be assigned via CPDLC. • If the flight will exit the CTA into domestic airspace, on initial contact the pilot shall:

a) use the term “C-P-D-L-C” after the aircraft call sign; b) state the track letter if operating on the Organised Track System (OTS); c) state the last two fixes in the cleared route of flight if operating outside the

OTS; and d) request the SELCAL check.

Example 1: KLM634 C-P-D-L-C, TRACK BRAVO, REQUEST SELCAL

CHECK CDAB. Example 2: CRX126 C-P-D-L-C, SCROD VALIE, REQUEST SELCAL

CHECK DMCS. Expect to receive the domestic frequencies or to be advised about the frequencies that will be assigned via CPDLC. • Continue to use the term “C-P-D-L-C” until the SELCAL check has been completed,

the frequency assignment has been received or advised about the frequency that will be assigned via CPDLC.

• If a frequency assignment is not received prior to crossing an OCA/FIR boundary, contact the appropriate aeradio station.

APPENDIX E


• When an onboard systems failure prevents CPDLC, or if CPDLC is terminated due

to FANS A problems: a) do not inform aeradio that CPDLC has been terminated; b) if the failure occurs prior to initial contact with the aeradio station, do not

use the phrase “C-P-D-L-C”; and c) inform Company Operations Department in accordance with established

problem reporting procedures. • When leaving CPDLC airspace, resume:

- ADS procedures if entering ADS airspace; or - normal voice procedures if entering non-FANS A airspace.

1.5 Aeradio • If an OCA/FIR implements Phase 2 operational trials:

some aeradio operators will advise CPDLC flights that frequencies will be provided via CPDLC; while other aeradio operators will continue to provide frequency assignments.

• Aeradio operators shall: a) respond to an aircraft that identifies itself as “C-P-D-L-C” by restating

“C-P-D-L-C” in conjunction with the aircraft call-sign; and b) complete the SELCAL check.

• Aeradio operators serving ATCs that are participating in ADS WPR operational trials

but not in CPDLC operational trials shall: a) advise aircraft that:

“CPDLC SERVICE NOT AVAILABLE IN (name) OCA/FIR. VOICE REPORTS NOT REQUIRED IN (name) OCA/FIR”; and

b) issue: - communication instructions for the next OCA/FIR; or - communication instructions and the frequency to contact the appropriate ATS

unit approaching, or over, the exit point; or - instructions for the aircraft to call the aeradio station serving the next

OCA/FIR at a time or location prior to the exit OCA/FIR boundary or exit point.

• Aeradio operators serving ATCs that are participating in ADS WPR operational trials and in CPDLC operational trials shall advise aircraft that: “VOICE REPORTS NOT REQUIRED IN (name) OCA/FIR”; and a) advise aircraft that:

“(type) FREQUENCIES WILL BE ASSIGNED VIA CPDLC”; or b) issue:

- communication instructions for the next OCA/FIR; or - communication instructions and the frequency to contact the appropriate ATS

unit approaching, or over, the exit point; or - instructions for the aircraft to call the aeradio station serving the next

OCA/FIR at a time or location prior to the exit OCA/FIR boundary or exit point.

APPENDIX E


1.6 Emergency Messages During Operational Trials • It is expected that, in an emergency, flight crews will immediately revert to voice

communications. This does not preclude crews from using CPDLC for emergency communications if unable to establish voice contact.

• Any downlink message that contains an emergency message element (see

Appendix 1) should be treated as an emergency message. • In the event that a controller receives an emergency downlink message he/she

should take immediate action to confirm the status and intentions of the aircraft via voice.

• Upon receipt of an emergency downlink message, the controller shall indicate to the

aircraft that the message was received by: - responding with standard freetext message 004: ROGER PAN if the message

contains DM55 PAN PAN PAN; - responding with standard freetext message 005: ROGER MAYDAY if the message

contains DM56 MAYDAY MAYDAY MAYDAY; or - responding with UM3 ROGER if the message contains DM57, DM58, DM59, DM60

or DM61.

• If an emergency downlink message is inadvertently sent, the flight crew should send DM58 CANCEL EMERGENCY as soon as practicable. After sending DM58, the flight crew should confirm their status and intentions via voice.

• Once an emergency downlink message is received, controllers will consider the

aircraft to be in an emergency state until confirmed otherwise via voice contact with the flight crew.

APPENDIX E


2. ADS PROCEDURES

Air Traffic Control Procedures • Whenever an ADS WPR is overdue by more than an period of time, as determined

by ATC, a controller shall take action to advise the aircraft concerned and request a voice position report. If either the pilot or the controller notices intermittent operation, either may revert to voice communications at any time. (Crews would be expected to log-off and resume voice reporting for the remainder of the crossing.)

• A controller who becomes aware of corrupt or incorrect data shall initiate action to establish voice contact with the aircraft concerned in order to correct the situation.

• If the controller is advised, or becomes aware of, a data link communications failure, aircraft concerned shall be advised as necessary to revert to voice position reporting.

• When an ADS emergency message is received, the controller with control responsibility for the aircraft shall request confirmation of the emergency through voice communications with the aircraft.

• When a controller not having control responsibility for the aircraft receives an ADS emergency report, he/she shall co-ordinate with the controlling authority to ensure that the emergency report has been received.

Flight Crew Procedures - General The integrity of the ATC service remains wholly dependent on establishing and maintaining HF or VHF voice communications. During implementation of ADS WPR, specific Air Traffic and Communications Service Providers may be in various stages of development and testing. To assist in the smooth transition to full implementation of ADS WPR throughout the NAT Region, the pilot procedures below reflect the end-state for ADS WPR. They are also applicable for operation within OCA/FIR’s conducting Pre Operational Trials. The application of the following pilot and associated aeradio procedures will permit a seamless expansion of ADS WPR without numerous changes to the procedures themselves . Flight Crew Procedures – ATS Facilities Notification (AFN) • When initialising the FMC, it is essential to ensure that the aircraft identification

matches the one displayed in the filed ATC flight plan. If a flight crew becomes aware that they have provided incorrect flight identification data for the AFN, they shall immediately terminate ADS and re- with a correct identification.

• Between 15 and 45 minutes prior to entering an ADS CTA the pilot shall initiate an

AFN. For flights departing from airports adjacent to, or underlying ADS Airspace, the pilot shall logon prior to departure. Regardless of the Data link Service Provider, the logon address for: - Gander is CZQX; - Shanwick is EGGX; - Reykjavik is BIRD; - Santa Maria is LPPO;

• Once logon has been established with one participating ATS provider, subsequent logons with adjacent participating ATS providers will be automatic.

APPENDIX E


Flight Crew Procedures – Aeradio Communications Prior to entering an ADS CTA, the pilot shall contact the appropriate aeradio station. • If the flight will exit an ADS CTA into oceanic airspace, on initial contact the pilot

shall: - use the term “A-D-S” after the aircraft call sign; - state the name of the next OCA/FIR to be entered; and - request the SELCAL check.

Example: KLM634 A-D-S, SHANWICK NEXT, REQUEST SELCAL CHECK CDBA. (Expect to receive the frequencies for the stated OCA/FIR)

If the flight will exit an ADS CTA into domestic airspace, on initial contact, the pilot shall:

- use the term “A-D-S” after the aircraft call sign; - state the track letter if operating on the Organised Track System (OTS); - state the last two fixes in the cleared route of flight if operating outside the OTS and - request the SELCAL check.

Example 1: KLM634 A-D-S, TRACK BRAVO, REQUEST SELCAL CHECK CDBA. Example 2: CRX126 A-D-S, SCROD VALIE, REQUEST SELCAL CHECK DMCS. (Expect to receive the Domestic frequencies). • Continue to use the term “A-D-S” until either the SELCAL check has been completed

or the frequency assignment has been received. • Pilots shall submit position reports via voice unless otherwise advised by the aeradio

operator. (See next section, Aeradio Procedures); • If the estimated time for the NEXT position last reported to ATC is found to be

delayed by three minutes or more, a revised estimate shall be transmitted via voice to the ATS unit concerned as soon as possible.

• When an onboard system failure prevents ADS WPR, or if ADS is terminated due to

FANS A problems: - do not inform aeradio that ADS has been terminated; - transmit all subsequent position reports via voice; - if the failure occurs prior to initial contact with the aeradio station, do not use the

phrase “A-D-S”; - inform Company Operations Department in accordance with established problem

reporting procedures. When leaving ADS airspace, Pilots shall resume normal voice communications. • Flight crews should not insert non-ATC waypoints (e.g. mid-points) in cleared

oceanic flight legs, as it will result in transmission of unwanted ADS reports. Non ATC waypoints may prevent the provision of proper ETA data in the ADS reports required for ATC waypoints.

APPENDIX E


Notes: - The use of ADS WPR does not negate the requirement to advise ATC whenever

any lateral offset is initiated or terminated. - Aircraft participating in ADS WPR are exempt from all routine voice Meteorological

Reporting (wind and temperature), requirements. - ADS WPR will automatically terminate after exiting ADS Airspace.

Aeradio Procedures • Aeradio operators shall: - Respond to an aircraft that identifies itself as “A-D-S” by restating “A-D-S” in

conjunction with the aircraft call-sign; and - Complete the SELCAL check.

• During Pre-Operational Trials, aeradio operators shall advise the pilot to make

position reports by HF voice. • During the Operational Trial aeradio operators shall: - Advise aircraft that “VOICE REPORTS NOT REQUIRED IN (nominated)

OCA/FIR”, - Issue:

- communication instruction for the next OCA/FIR; or - communications instructions and the frequency to contact the appropriate ATS unit

approaching, or over, the exit point or - instructions for the aircraft to call the aeradio station serving the next OCA/FIR at a

time or location prior to the next OCA/FIR boundary or exit point.

APPENDIX E


E.4 - SOUTH ATLANTIC FANS OPERATIONS (TRIALS) All the following information are based on the “Guidance material on SACCAN FANS A operational evaluation trials in Canarias airspace” Version 1.0. This document is available on the SATMA web site: www.satmasat.com

SYSTEM OPERATION - MANAGING ADS AND CPDLC • Log-on/Connection Aircraft participating in the SACCAN FANS A operational evaluation trials are kindly requested to manually log-on the Canary Islands SACCAN system by sending an ATS Facilities Notification (AFN) Contact message, containing the 4 character ICAO code of the CANARIAS ATS unit “GCCC” between 15 and 45 minutes prior to entering the CANARIAS FIR/UIR. If a log-on attempt is not successful, wait at least 5 minutes before making a second attempt For flights departing from airports adjacent to, or within CANARIAS FIR/UIR, the pilot should log-on prior to departure. Some aircraft may decide to participate only in ADS operational evaluation trials, and therefore the only connection to be activated will be ADS. The AFN log-on will be rejected if:

- the aircraft registration/flight identification pairing does not match the pairing contained in the flight plan; - there is no aircraft registration included in the flight plan; or - there is no flight plan in the ATS system (SACCAN) for that flight.

The flight identification used for log-on must be exactly the same as the filed in the ATS flight plan. • Establishing and Terminating an ADS Connection Immediately after log-on has been completed successfully SACCAN will automatically activate the ADS connection and set an initial 15 minutes (adaptable value) periodic reporting rate contract with the aircraft. During the aircraft transit through CANARIAS FIR/UIR airspace different periodic contract reporting rates and data contents will be exercised in order to operationally evaluate the SACCAN automatic ADS contracts management feature. Although several types of event contracts will be operationally evaluated , the most commonly used will be:

- ADS Way Point Change Event; - Altitude Range; and, - Lateral Deviation Change Event; and, - Demand contracts (set by the ground system at any time); and, - ADS MET Data contract request will also be evaluated.

APPENDIX E


In order to minimise the cost of data communications the use of high periodic reporting rates (the highest possible is 64 seconds for FANS A avionics) and in general the amount of ADS data exchanged will be kept to the minimum required. During the operational evaluation trials phase it is not expected to execute any transfer since no adjacent ATS unit FANS A equipped is yet available • ADS Emergency Mode Operation When SACCAN receives an emergency-mode ADS report (triggered by pilot action) , it will alert the Controller. If a periodic contract is active, the emergency reports will be transmitted at the existing periodic rate. Only the pilot can cancel the emergency mode. During the ADS operational evaluation trials the ADS Emergency Mode Operation will be occasionally evaluated with aircraft. Pilot triggering of the emergency mode for testing purposes will be done only on controller request via voice communications, or via data link free text in case the aircraft is also participating in CPDLC trials. • Surveillance Safety Considerations During this first phase of ADS operational evaluation trials ADS data will never be used for operational purposes such as application of ADS separations between aircraft, aircraft and the terrain, or any kind of ADS service. Only after proper evaluation, system modification if required, and validation, SACCAN will be used in a first operational phase for “ADS monitoring” • Establishing, Executing, and Terminating a CPDLC Connection Participating FANS A equipped aircraft wanting/able to participate on top of ADS also in CPDLC operational evaluation trials, once entered Canarias airspace and ready to start the trials, should inform Canarias ACC by means of the following voice phraseology: “READY FOR CPDLC TRIALS” If when receiving the aircraft request the controller is ready for CPDLC trials, he/she will answer “ ROGER, INITIATING CPDLC” while he/she manually triggers the CPDLC initiation in the SACCAN system. If when receiving the aircraft request the controller is not ready for CPDLC trials with that aircraft, and expects he/she will never be before the aircraft leaves the Canarias airspace, the answer will be “UNABLE TO PERFORM CPDLC TRIALS”. If when receiving the aircraft request the controller is not ready for CPDLC trials, but he/she expects to be ready for it later before the aircraft leaves the Canarias airspace, he/she will answer “ROGER, I WILL CALL YOU BACK FOR CPDLC TRIALS”, or “EXPECT CPDLC CONECTION FOR TRIALS AT TIME __ __”.

APPENDIX E


Once the controller is ready for CPDLC trials he/she will indicate it to the pilot by the voice message “ CONFIRM READY FOR CPDLC TRIALS”, and if the pilot response is ”AFFIRMATIVE” he/she will answer “ROGER” and trigger the CPDLC initiation in the SACCAN system. A CPDLC exchange can only occur after the AFN has been completed, the CPDLC initiated by means of a CONNECTION REQUEST message triggered manually by the controller and sent by the SACCAN system to the aircraft, and a CONNECTION CONFIRM message received from the aircraft. Pilots will ensure that the CPDLC connection is an active connection. When so requested by ATC by means of the free text message “START CPDLC WAYPOINT POSITION REPORTING” pilots shall ensure that a CPDLC message will be issued whenever an ATC waypoint is passed over (Waypoint Change Events (WCE) ). ATC expects position reports based on downlink message POSITION REPORT [position report] (Message 48 of the DOWNLINK MESSAGE ELEMENT TABLE defined in RTCA DO-219 that also can be seen in Appendix 3). Pilots should not expect a controller response to these position reports. Free text message “STOP CPDLC WAYPOINT POSITION REPORTING” will be used by ATC to advice pilot to stop this reporting. A set of CPDLC tests to be carried out during the first phase of the operational evaluation is in “Guidance material on SACCAN FANS A Operational Evaluation Trials in Canarias Airspace. The CPDLC messages exchanged during this first phase of operational evaluation trials are not operationally valid and therefore instructions or requests in them shall never be considered as operational valid either by the crew or controller. Controller instructions via CPDLC are not to be complied with, either by pilot or FMS. Once a test have been commenced, that test should be completed in order not to leave open messages before terminating the CPDLC trials. The termination of a CPDLC trials session may be decided at any moment by either pilot or controller and will be communicated to each other by means of the following free text message: “REQUEST CPDLC TRIALS TERMINATION” Pilot response to this message should be “ROGER”. The controller will trigger the initiation of the CPDLC connection termination sequence which will cause SACCAN to send an END SERVICE uplink message. The controller shall ensure that no open uplink CPDLC messages exist prior to the up-linking of an END SERVICE message.

APPENDIX E


Although it is an abnormal case, if the controller is aware that the END SERVICE message has been unsuccessful, the pilot will be instructed by voice to terminate the connection. If the CPDLC connection does not terminate automatically at the appropriate time (normally 5 minutes after leaving CANARIAS FIR/UIR, then the pilot shall manually disconnect. • Communications Safety Considerations The CPDLC messages exchanged during this first phase of operational evaluation trials are not operationally valid and therefore instructions or requests in them shall never be considered as operational valid either by the crew or controller. During this first phase of the operational evaluation trials the integrity of the ATC service remains wholly dependent on establishing and maintaining HF or VHF voice communications. The only operational valid means of communications continue to be VHF and HF voice communications.

OPERATIONAL EVALUATION TRIALS PROCEDURES • Flight Planning Procedures Operators should complete the ICAO flight plan form as follows for FANS A equipped aircraft as detailed in §5.2. It is to be noticed that the Item 18 must be filled with RMK/ followed by CANARIAS FANS 1 or CANARIAS FANS A (specifically requested by Canarias ACC to FANS A participating aircraft). Example: ICAO Item 18: DAT/SV..RMK/CANARIAS FANS 1 (for a satellite and VHF data link equipped aircraft, and FANS 1 aircraft participating in the Canarias FANS A operational evaluation trials ) NOTE: The above requirements are for an end-state system. If an operator’s flight planning system does not have the capability to enter any of the data as indicated; this will not restrict participation in the SACCAN FANS A Operational Evaluation Trials. The ATS system (SACCAN) compares the registration number of the aircraft contained in Field 18 (Other Information) of the ICAO flight plan with the registration contained in the ATS Facilities Notification (AFN). The operator is responsible for ensuring that the correct aircraft registration is filed in Field 18 of the ICAO flight plan.

APPENDIX E


• Air Traffic Control Procedures It is to be noticed that logon and connection management are detailed in § 5. Whenever an ADS-WPR is overdue by more than interval, as determined by ATC, the controller will take action to advise the aircraft concerned in order to investigate or try to correct the situation. A controller who becomes aware of corrupt or incorrect data, will take action to advise the aircraft concerned in order to investigate or try to correct the situation. In order to perform the operational evaluation the controller will follow the internal evaluation procedures and protocols established to this respect. If the controller is advised, or becomes aware of a data link communications failure, aircraft concerned will be advised. When an unexpected /not programmed ADS emergency message is received, the controller with control responsibility for the aircraft shall request confirmation of the emergency through voice communications with the aircraft. When a controller not having control responsibility for the aircraft receives an ADS emergency report, he/she shall co-ordinate with the controlling authority to ensure that the emergency report has been received and is investigated. • Flight Crew Procedures When initializing the FMC, it is essential to ensure that the aircraft identification matches the one displayed in the filed ATC flight plan (FPL Message). If a flight crew becomes aware that they have provided incorrect flight identification data for logon to ATC, they shall immediately terminate ADS and re-logon with a correct identification. Pilots must be aware that appropriate clocks synchronisation to UTC (hours/minutes/seconds) is essential for FANS operations and specially for ADS. Pilots might be asked by the controller to provide a “time check for ADS” by means of the following voice message: “REQUEST TIME CHECK FOR ADS”; if that is the case, pilot response should be : “TIME (minutes, seconds)”. Pilots are requested to log-on between 15 and 45 minutes prior to entering the CANARIAS FIR/UIR. On initial voice contact with CANARIAS ACC the pilot will use the term “FANS ADS” after the call-sign. If unable to log-on after several attempts , on initial voice contact with CANARIAS ACC the pilot should inform ATS using the following terminology: “UNABLE TO FANS LOG-ON”.

APPENDIX E


ADS, with the exception of the “ADS Emergency Mode Operation” will normally be initiated, managed, and terminated by the ground system, without pilot intervention. If problems are experienced with the CPDLC connection , pilot should inform ATS via HF or VHF voice using the following terminology: “PROBLEMS WITH CPDLC CONNECTION” Log-off should normally take place 5 minutes after leaving CANARIAS FIR/UIR unless something different is agreed in real time via pilot-controller voice communications Flight crews that encounter problems with FANS A data link will inform controller and advise their Company Operations Department in accordance with their established problem reporting procedures. The CPDLC messages exchanged during this first phase of operational evaluation trials are not operationally valid and therefore instructions or requests in them shall never be considered as operational valid either by the crew or controller. During this first phase of the operational evaluation trials the integrity of the ATC service remains wholly dependent on establishing and maintaining HF or VHF voice communications.

APPENDIX E


E.5 - NEW YORK OCEANIC (KZWY) CPDLC SERVICE AREA

This document is based on a NOTAM (March 20th, 2003) available on the FAA web site: http://www1.faa.gov/ats/ato/data_link.htm On March 2003, New York ARTCC has implemented full FANS1/A CPDLC capability in the New York Oceanic FIR MNPS airspace including that additional airspace within the New York Oceanic FIR south of 27 degrees North latitude and east of 60 degrees West longitude inclusive. CPDLC will not be available in the WATRS area. FANS A capable aircraft that wish to participate in CPDLC may utilise this service. The New York Oceanic FIR log-on address is “KZWY”. As KZWY does not have the capability to receive waypoint position reports using ADS, pilots should send their required position reports utilising CPDLC. Meteorological reports will not be required from flights when utilising CPDLC. 1. HF Communications Requirement Prior to entering the KZWY CPDLC service area, contact New York Radio on HF or VHF and identify the flight as CPDLC equipped; provide SELCAL, departure point, destination, and aircraft registration number. Expect to receive primary and secondary HF frequency assignments from New York Radio for the route of flight within the CPDLC service area. Pilots must maintain HF communications capability with New York Radio at all times within the entire New York Oceanic FIR. 2. Log-On (Entry Procedures) Aircraft entering the KZWY CPDLC service area from NON-CPDLC airspace: • Initial log-on from non-CPDLC airspace: Log on to KZWY at least 15 minutes but

not more than 45 minutes prior to entering the KZWY CPDLC service area.

• Initial log-on in transit eastbound through WATRS airspace: Log on to CPDLC at least 15 minutes but no more than 45 minutes prior to entering the KZWY CPDLC service area. Continue normal ATC communication via HF voice until entering the KZWY CPDLC service area. Commence CPDLC communications at the service area boundary. Downlink messages sent prior to entering the CPDLC service area will be rejected and a response of "Service unavailable" will be uplinked.

EXCEPTION: Flights operating along A700 within MNPS airspace are not to use CPDLC and are to continue using HF voice.

APPENDIX E


Aircraft entering the KZWY CPDLC service area from adjacent CPDLC airspace: Until further advised, there is no automatic transfer of a flight’s CPDLC connection from any CPDLC service area entering KZWY. If a “Datalink Termination” message is received, pilots must manually log-on to the KZWY CPDLC system and send a boundary waypoint position report. If “KZWY” is not the active centre within 5 minutes after the boundary is crossed, pilots shall ensure all open uplinks from the previous ATC unit have been responded to, then terminate the CPDLC connection and log on to KZWY. While “KZWY” is the active centre the pilot shall ensure HF communications are maintained as a backup and begin CPDLC communication. 3. KZWY CPDLC Service Area Exit Procedures

• Aircraft exiting the KZWY CPDLC service area to adjacent NON-CPDLC airspace (Santa Maria, Piarco, San Juan, WATRS, New York Centre, Bermuda Radar, Moncton, and Gander Domestic): Aircraft approaching the airspace above can expect the CPDLC “CONTACT” message containing the frequency for the next facility. CPDLC will be terminated approximately 10 minutes prior to the boundary crossing point.

• Aircraft exiting the KZWY CPDLC service area to adjacent CPDLC

airspace (presently only applicable to Gander Oceanic): Aircraft approaching adjacent CPDLC airspace above can expect the CPDLC “MONITOR” message containing the frequency for the next facility. CPDLC will be transferred approximately 10 minutes prior to the boundary crossing point.

4. Position Report Message Format KZWY cannot accept position reports containing latitude and longitude (Lat/Long) in ARINC 424 format (e.g. 4050N). Position reports containing Lat/Long waypoints within the KZWY CPDLC service area will be accepted in whole latitude and longitude format only (050N040W). Flights unable to send position reports in whole latitude and longitude format must accomplish position reporting via HF voice communications. 5. Controller Pilot Data Link Communications (CPDLC) Failure In the event of CPDLC failure, flight crews shall contact New York Radio via HF voice for routine communications. SATVOICE contact is limited to distress and urgency situations. Direct questions to New York International Operations, telephone: (1) 631-468-1037, fax: (1) 631-468-4229 during normal business hours Monday – Friday. During all other times, contact New York Centre North Atlantic Supervisor: (1) 631-468-1496. Questions can also be e-mailed to [email protected] (email address effective as of 1 March 2003).


APPENDIX F


APPENDIX F

DYNAMIC AIRBORNE ROUTE PLANNING The dynamic re-routing procedure has been developed by the ISPACG forum to provide FANS equipped aircraft with the possibility of a complete F-PLN change once airborne. On the typical Los Angeles/Sydney or Los Angeles/Auckland routes, the wind updates after the first hours of flight may happen to show that a better F-PLN could be considered. Procedures, based on an extensive use of the data link capabilities of the three AOC, ATC and aircraft, have thus been developed to allow for the crew to get an in-flight route re-clearance. The DARP scenario is described in the Airbus AIM-FANS A training CD-ROM. The following describes the SPOM procedures, for a single re-route per flight, as currently in use. 1- Prerequisites - The airline shall have an AOC data link capability to communicate with both the

aircraft and the ATC with data link. - The airline must be able to sustain CPDLC with the appropriate ATC, and data link

AOC with its operations centre. - The ATC centres providing the control of the FIR where the re-routing will be done

must have CPDLC capability.

2- PACOTS / DARP Track designations PACOTS tracks still exist but many operators use them as UPR. Therefore, there are aircraft both on PACOTS and UPR. Consequently, no more strategic separations (50Nm) between aircraft can be applied. 3- Descriptive drawing The following sequence is applied: OAKLAND - Oakland (ZOA) receives new weather forecast and loads it in its system - ZOA Traffic Management Unit defines the DARP entry point on the original track, at

least 90 minutes ahead of the aircraft. - ZOA TMU (Traffic Management Unit) defines a new track based on the old route

until the DARP entry point. - ZOA TMU sends a new TDM (Track Definition Message) to all concerned ATCs

AOC / Aircraft/ ATC - Following the receipt of the new TDM, AOC decides whether or not to re-route - If re-route decided, the AOC uplinks the new route to the aircraft - After evaluation of the received P-PLN, the pilot asks for a re-route clearance - Once cleared, the crew activates the re-route and notifies it to his AOC - The AOC transmits a Change message to the all concerned ATC (until AIDC

exists)

APPENDIX F


The following drawing gives a general view of all the co-ordinated sequences that occur in a DARP phase.

Although promising this procedure has not been used very much for the time being, because it happens that the current wind models, as used by the airlines, are precise enough within the frame of the flight. Activating the DARP procedure requires a good co-ordination between all involved actors (Aircraft, AOC, ATC) . The User Preferred Route procedure (UPR) is by far preferred by the airlines.

UPR (User Preferred Route): The wind models used by the airlines are not the same than those used by the ATC when the daily PACOTS routes are defined. Differences of up to around 15 minutes of flight time are claimed by the operators. These have been asking for the possibility to define their own routes according to the daily conditions. They file their UPR Flight Plan. These UPR procedures are currently used between Los Angeles and both Sydney and Auckland. Next Step: DARP from UPR The South Pacific FIT is developing procedures for a trial of a DARP from the airlines' individual UPR. In this case, the airlines do not need to take into account the daily published PACOTS. A trial of the procedure is proposed for mid-2003.

Oakland (USA) Traffic Management Unit

Meteo Centre

ATC1 ATC2 Airline Operations Control

AFTN

1 – Wind Forecast

2 – New Track Definition

3 – Revised F-PLN

4 – Route Clearance Request

5 – ClearedRoute

6 – Re-route Notification

7 – Revised F-PLN

APPENDIX G


APPENDIX G

OPERATIONAL SCENARIOS FANS A 1 - INITIAL NOTIFICATION The aircraft is in flight, for a flight from Los Angeles (KLAX) to Auckland (NZAA). The first ATC for this flight is KZAK control and the crew wants to logon to it. The first step is to notify the ATC center of the aircraft datalink capability. - First, select the ATC Menu page on the MCDU (by pressing on the ATC COMM function key), then select the NOTIFICATION page.

MSG +

MSG -

PGE +

PGE -

PRINT

BRT

DIM

NO AC T I V E AT C

D IR

F U E LP R E D

S E CF -P L NF -P L N R A D

N A VA T C

C O M MM C D UM E N U

D A T AIN ITP E R FP R O G

F M 1 IN D R D Y F M 2

B R T

O F F

A T S U D A T A L I N K

< A T C M E N U A O C M E N U >

APPENDIX G


D IR

F U E LP R E D


N A VA T C




B R T

O F F

< L A T R E Q

<WH E N C A N WE

<M S G L O G

<N O T I F I C A T I O N A T S U D L K

< R E T U R N

V E R T R E Q >

O T H E R R E Q >

T E X T >

R E P O R T S >

C O N N E C T I O N

S T A T U S > E M E R G E N C Y >

A T C M E N U

The ATC FLT NBR is provided by the FMGEC (set on the INIT page). The system has stored the last active ATC center of the previous flight, here KZAK. In our example, this is the first ATC for your flight. Press NOTIFY* in order to notify the KZAK ATC center.

D IR

F U E LP R E D


N A VA T C




B R T

O F F

N OT I F I C A T I O N A T C F L T N B R

A F 8 0 0

A T C C E N T E R

K Z A K – – – – – – – – – – – – – N O T I F Y *

A T C M E N U

< R E T U R NC O N N E C T I O N

S T A T U S >

APPENDIX G


KZAK NOTIFIED is displayed in green. It means that the ATC has been notified of the aircraft datalink capability. It does not mean that the connection has been performed. This is confirmed on the DCDU by the NO ACTIVE ATC message. Once notified, the connection operation is initialised by the ATC at their discretion.

MSG +

MSG -

PGE +

PGE -

PRINT

BRT

DIM

N O A C T I V E A T C

D IR

F U E LP R E D


N A VA T C




B R T

O F F


A F 8 0 0

A T C C E N T E R!!!!!!!!!!!!!!!! – – – – – – – – – – – – – N O T I F Y

– – – – – K Z A K : N O T I F I E D – – – – –

A T C M E N U


S T A T U S >

APPENDIX G


2 - CPDLC LOGON When the ATC center initialises the CPDLC connection, the display on the DCDU changes, and the active ATC is displayed on the DCDU. The ATC center has performed the logon operation and the communication is established.

MSG +

MSG -

PGE +

PGE -

PRINT

BRT

DIM

A C T I V E A T C : K Z A K C T L

The aircraft is now able to exchange datalink messages. Here is how to check the connection status: Select the Connection Status page.

D IR

F U E LP R E D


N A VA T C




B R T

O F F


A F 8 0 0

A T C C E N T E R!!!!!!!!!!!!!!!! – – – – – – – – – – – – – N O T I F Y

A T C M E N U


S T A T U S >

APPENDIX G


The active ATC is displayed. Note: As a general rule, the connection should be completed 15 to 45 mn before entering a CPDLC airspace.

D IR

F U E LP R E D


N A VA T C




B R T

O F F

C O N N E C T I O N S T A T U SA C T I V E A T C

K Z A K

A T C M E N U

< R E T U R N

N E X T A T C

– – – –

– – – – – – – – A D S : O N – – – – – – –* S E T O F F

N O T I F I C A T I O N >

– – – – – – – D I S C O N N E C T *

Notice also the default status of the ADS function, set to ON. This means that ADS is ready to work (armed), as soon as an ATC will have given an ADS contract to the aircraft.

APPENDIX G


3 - LOGON TO NEXT ATC The datalink communication transfer to the next ATC, also known as Next Data Authority, is initialised by the current ATC and automatically performed by the ATSU. This process is totally transparent to the crew. This is simply indicated by a SERVICE TERMINATED message sent by the ATC. The aircraft is in cruise, close to leaving the KZAK CTL and to entering the KOAK.

MSG +

MSG -

PGE +

PGE -

PRINT

BRT

DIM

R E C A L L *


On the connection status page, KZAK is the active ATC. There is no NEXT ATC.

D IR

F U E LP R E D


N A VA T C




B R T

O F F

< L A T R E Q

<WH E N C A N WE

<M S G L O G

<N O T I F I C A T I O N A T S U D L K

< R E T U R N

V E R T R E Q >

O T H E R R E Q >

T E X T >

R E P O R T S >

C O N N E C T I O N


A T C M E N U

APPENDIX G


D IR

F U E LP R E D


N A VA T C




B R T

O F F


K Z A K

A T C M E N U

< R E T U R N

N E X T A T C

– – – –

– – – – – – – – A D S : O N – – – – – – –* S E T O F F


– – – – – – – D I S C O N N E C T *

Upon reception by the aircraft of an ATC message, both ATC MSG lights flash and as it is a normal message, the first telephone ring is delayed by 15 s, then it will be repeated every 15 s. Press on the ATC MSG pushbutton to extinguish the lights and stop the aural signal.

ATCMSG

ATCMSG

APPENDIX G


The message received from KZAK CTL is displayed on the DCDU, indicating that the next ATC is KOAK. Press the CLOSE softkey to store the message. On the connection status page, the next ATC is displayed: this is a "NO ANSWER" message.

MSG +

MSG -

PGE +

PGE -

PRINT

BRT

DIM

1 1 0 7 Z F R O M K Z A K C T L

C L O S E *

N E X T D A T A A U T H O R I T Y :K O A K

D IR

F U E LP R E D


N A VA T C




B R T

O F F


K Z A K

A T C M E N U

< R E T U R N

N E X T A T C

K O A K

– – – – – – – – A D S : O N – – – – – – –* S E T O F F


– – – – – – – D I S C O N N E C T *

The message is closed: the DCDU screen is cleared. The active ATC is still KZAK and will change only when KZAK terminates the connection. The message can be recalled by pressing the RECALL softkey on the DCDU or displayed in the MSG LOG page on the MCDU.

MSG +

MSG -

PGE +

PGE -

PRINT

BRT

DIM

R E C A L L *


APPENDIX G


An uplink ATC message is received: both ATC MSG lights flash and as it is a normal message, the first telephone ring is delayed by 15 s, then it will be repeated every 15 s. Press on the ATC MSG pushbutton to extinguish the lights and stop the aural signal.

When the new ATC center initialises the connection, the SERVICE TERMINATED message received from KZAK CTL is displayed on the DCDU. The ATC center has performed the logon operation and the communication is established. Press the CLOSE softkey to store the message.

MSG +

MSG -

PGE +

PGE -

PRINT

BRT

DIM

1 1 1 0 Z F R O M K Z A K C T L

C L O S E *< O T H E R

S E R V I C E T E RM I N A T E D

The message is closed: the DCDU screen is cleared. The new active ATC (KOAK CTL) is displayed on the DCDU.

MSG +

MSG -

PGE +

PGE -

PRINT

BRT

DIM

R E C A L L *

A C T I V E A T C : K O A K C T L

ATC MSG ATC

MSG

APPENDIX G


4 - CLEARANCE In this scenario the aircraft receives the answer to its previous request and later on, a lateral clearance. An uplink ATC message is received: both ATC MSG lights flash and as it is a normal message, the first telephone ring is delayed by 15 s, then it will be repeated every 15 s. Press on the ATC MSG pushbutton to extinguish the lights and stop the aural signal. The received message is displayed on the DCDU. On the first line, in green, the indication about the time and the issuer of the message (here, KZAK CTRL). On the second line, in white, the reply indication, including the sending time of the aircraft's request. On the remaining lines, the ATC answer. To ease the reading, uplink messages are in white with the main parameters highlighted in cyan. In order to reply WILCO to the message, select the WILCO softkey.

MSG +

MSG -

PGE +

PGE -

PRINT

BRT

DIM

1 4 2 5 Z F R O M K Z A K C T L O P E N

* U N A B L E S T B Y *

W I L C O *< O T H E R

( R E P L Y T O 1 4 1 9 Z R E Q )A T A L C O A C L B T O & M A I N T F L 3 9 0

Once selected, the WILCO status is displayed in cyan inverse video on the top right corner. Each answer selected by the crew will be displayed at this place in this manner before being physically sent. In case of mistake, the CANCEL soft key enables the crew to cancel the current selection and to re-select another answer. The SEND* function is now available for the sending of the selected answer (WILCO) Press the SEND softkey.

ATCMSG ATC

MSG

APPENDIX G


MSG +

MSG -

PGE +

PGE -

PRINT

BRT

DIM

1 4 2 5 Z F R O M K Z A K C T L W I L C O

* C A N C E L

S E N D *< O T H E R


As already seen, the SENDING/SENT information is shown. The SEND status is in green inverse video when SEND has been selected, and the message content changes to green once sent. The parameter ALCOA turns magenta indicating that the FMS is currently monitoring the related deferred clearance. This is confirmed by the MONITORING information displayed on the DCDU bottom centre. This means that when closing to ALCOA, the FMS will recall the message to remind the crew about this clearance.

MSG +

MSG -

PGE +

PGE -

PRINT

BRT

DIM


M O N I T O R I N G * C A N C E L



MSG +

MSG -

PGE +

PGE -

PRINT

BRT

DIM


S E N T



APPENDIX G


During CPDLC exchanges, the FMS processes the ATC conditional or deferred clearances that are linked to navigation. Then, when approaching a clearance condition, the FMS is able to recall messages to alert the pilots. About 30 s before the clearance condition, the FMS automatically displays the deferred clearance text on the DCDU. This is indicated by the REMINDER information and the visual and aural alerts: Press on the ATC MSG pushbutton to extinguish the lights and stop the aural signal. As the clearance condition is fulfilled, the clearance text is shown in green. The answer to the clearance is also displayed at the top right corner. The time and active ATC fields at the top of the screen are no longer displayed. Press the CLOSE softkey to store the message.

MSG +

MSG -

PGE +

PGE -

PRINT

BRT

DIM

W I L C O

R E M I N D E R

C L O S E O T H E R

A T A L C O A C L B T O & M A I N T F L 3 9 0

ATC MSG ATC

MSG

APPENDIX G


5 - WHEN CAN YOU… In this scenario, the ATC sends a question message containing the element “WHEN CAN YOU”. The received message s displayed on the DCDU. The CAN and CANNOT softkeys are available. Press the CAN softkey. The response message is automatically created.

MSG +

MSG -

PGE +

PGE -

PRINT

BRT

DIM


* C A N N O T

C A N *

WH E N C A N Y O U A C C E P TF L 3 7 0

The OPEN message status is replaced by CAN status in inverse video. The text of the reply is displayed with the data field to fill in by means of the MCDU. Now, the CANCEL and MODIFY softkeys are available. Note that the SEND function is not available, as the message is still incomplete: the user must press MODIFY in order to fill the brackets, or else CANCEL the message. Press the MODIFY softkey.

MSG +

MSG -

PGE +

PGE -

PRINT

BRT

DIM

1 1 5 4 Z F R O M K Z A K C T L C A N

* C A N C E L M O D I F Y *

S E N D

WH E N C A N Y O U A C C E P TF L 3 7 0– – – – – – – – – – – – – – – – – – – – – – – –WE C A N A C C E P T F L 3 7 0 B Y []

APPENDIX G


Under the reply, the MCDU FOR EDIT information is displayed. The MESSAGE EDITION page comes into view on the MCDU. Enter the time parameter in the MCDU scratchpad and press the line key adjacent to the BY data field.

MSG +

MSG -

PGE +

PGE -

PRINT

BRT

DIM


M C D U F O R E D I T * C A N C E L M O D I F Y

S E N D

WH E N C A N Y O U A C C E P TF L 3 7 0– – – – – – – – – – – – – – – – – – – – – – – –WE C A N A C C E P T F L 3 7 0 B Y []

D IR

F U E LP R E D


N A VA T C




B R T

O F F

A T C

M OD I F D I S P LP A G E

C A N C E L

M E S S A G E M OD I F Y

A D D T E X T

T O K Z A K C T L

*

B Y

[ ]

WE C A N A C C E P T F L 3 7 0

1 2 H 3 0

APPENDIX G


The time (foreseen to reach the flight level 370) is displayed on the MCDU. It is possible to add free text to the reply by selecting ADD TEXT. This leads to the MCDU TEXT page:

D IR

F U E LP R E D


N A VA T C




B R T

O F F

A T C

M OD I F D I S P LP A G E

C A N C E L


A D D T E X T

T O K Z A K C T L

>

* *

B Y

1 2 H 3 0

WE C A N A C C E P T F L 3 7 0

It is possible to enter up to 4 lines of free text, or to chose one of the proposed reasons. For this example, chose the DUE TO A/C PERFORM. key. The selected text is displayed in cyan.

D IR

F U E LP R E D


N A VA T C




B R T

O F F

T E X T 1 / 2 """"####

A T C M E N U

< R E T U R N

*

*

I N P U T S

E R A S E A T C

M OD I F D I S P L

D U E T O

M E D I C A L ####

D U E T O""""WE A T H E R

D U E T O

T E C H N I C A L ####

D U E T O""""T U R B U L E N C E

A T P I L O T S

D I S C R E T I O N####

– – – – – – F R E E T E X T – – – – – – –

[ ]

D U E T O""""A / C P E R F O RM .

APPENDIX G


Press the line key adjacent to the ATC MSG DISPL* command on the MCDU. This displays the prepared message on the DCDU.

D IR

F U E LP R E D


N A VA T C




B R T

O F F

T E X T 1 / 2 """"####

A T C M E N U

< R E T U R N

*

*

I N P U T S

E R A S E A T C

M OD I F D I S P L

D U E T O

M E D I C A L ####


D U E T O



A T P I L O T S


– – – – – – F R E E T E X T – – – – – – –

[ ]

D U E T O

A / C P E R F O RM .

The MCDU paged is refreshed, with the default "ATC TEXT DISPL" text in line 6R, but unavailable (no star). Options are all available again to allow for further message completion if required. As the created message is too long to be displayed on 1 page of the DCDU, page1/2 appears on the DCDU. The SEND function is not available (no star) until all pages of the prepared message have not been visualized: press on the PAGE + softkey.

MSG +

MSG -

PGE +

PGE -

PRINT

BRT

DIM



S E N D

WH E N C A N Y O U A C C E P TF L 3 7 0– – – – – – – – – – – – – – – – – – – – – – – –WE C A N A C C E P T F L 3 7 0 B Y 1 2 H 3 0

P G E 1 / 2

APPENDIX G


D IR

F U E LP R E D


N A VA T C




B R T

O F F

T E X T 1 / 2 """"####

A T C M E N U

< R E T U R N

I N P U T S

E R A S E A T C

T E X T D I S P L

D U E T O

M E D I C A L ####


D U E T O



A T P I L O T S


– – – – – – F R E E T E X T – – – – – – –

[ ]


The SEND softkey is now available. Press the SEND softkey.

MSG +

MSG -

PGE +

PGE -

PRINT

BRT

DIM

C A N


S E N D *

1 2 H 3 0 D U E T O A / C P E R F O RM A N C E

P G E 2 / 2

MSG +

MSG -

PGE +

PGE -

PRINT

BRT

DIM


S E N T

C L O S E *

WH E N C A N Y O U A C C E P TF L 3 7 0– – – – – – – – – – – – – – – – – – – – – – – –WE C A N A C C E P T F L 3 7 0 B Y 1 2 H 3 0

P G E 1 / 2

Under the reply, the SENDING information is displayed TEMPORARILY. The message body changes to green once sent.

APPENDIX H


APPENDIX H

OPERATIONAL SCENARIOS FANS A+

1 - INITIAL NOTIFICATION The aircraft is in flight, for a flight from Los Angeles (KLAX) to Auckland (NZAA). The first ATC for this flight is KZAK control and the crew wants to logon to it. The first step is to notify the ATC center of the aircraft datalink capability. First, select the ATC Menu page on the MCDU then select the NOTIFICATION page.

A T S U D A T A L I N K

< A T C M E N U A O C M E N U >

APPENDIX H


< L A T R E Q

<WH E N C A N WE

<M S G R E C O R D

<N OT I F I C A T I ON A T S U D L K

< R E T U R N

V E R T R E Q >

OT H E R R E Q >

T E X T >

R E P O R T S >

C O N N E C T I O N


A T C M E N U 1 / 2 """" ####

The ATC FLT NBR is provided by the FMGEC (set on the INIT page). The system has stored the last active ATC center of the previous flight, here KZAK. In our example, this is the first ATC for your flight. Press NOTIFY* in order to notify the KZAK ATC center.

N O T I F I C A T I O N A T C F L T N B R

A F 8 0 0

A T C C E N T E R

K Z A K – – – – – – – – – – – – – N O T I F Y *

A T C M E N U


S T A T U S >

APPENDIX H


KZAK is displayed in green. It means that the ATC has been notified of the aircraft datalink capability. It does not mean that the connection has been performed. This is confirmed on the DCDU by the default message. Once notified, the connection operation is initialised by the ATC at their discretion.


A F 8 0 0

A T C C E N T E R !!!!!!!!!!!!!!!! – – – – – – – – – – – – – N OT I F Y

K Z A K

A T C M E N U


S T A T U S >

A T C N O T I F I E D

NOTE : the last 6 notified centers can be displayed on the MCDU.

NOTE : all the notification history will be deleted after each flight, 2 minutes after the engine shut down.

APPENDIX H


2 - CPDLC LOGON When the ATC center initialises the CPDLC connection, the display on the DCDU changes, and the active ATC is displayed on the DCDU. The ATC center has performed the connection operation and the communication is established.


The aircraft is now able to exchange datalink messages. Here is how to check the connection status: Select the Connection Status page.


A F 8 0 0

A T C C E N T E R !!!!!!!!!!!!!!!! – – – – – – – – – – – – – N OT I F Y

K Z A K

A T C M E N U


S T A T U S >

A T C N O T I F I E D

APPENDIX H


The active ATC is displayed. Note: As a general rule, the connection should be completed 15 to 45 mn before entering a CPDLC airspace.

C O N N E C T I ON S T A T U SA C T I V E A T C

K Z A K

A T C M E N U

< R E T U R N

N E X T A T C

– – – –

– – – – – – – – – A D S : A RM E D – – – – –* S E T O F F

N OT I F I C A T I ON >

– – – – – – – D I S C ON N E C T * M S G L A T E N C Y

N ON E

A D S D E T A I L

Notice also the default status of the ADS function, set to “ARMED”. This means that ADS is ready to work (armed : ready to accept contract with ground ATC centers)

APPENDIX H


3 - CONNECTION TO NEXT ATC The datalink communication transfer to the next ATC, also known as Next Data Authority, is initialised by the current ATC and automatically performed by the ATSU. This process is totally transparent to the crew. This is simply indicated by a SERVICE TERMINATED message sent by the ATC. The aircraft is in cruise, close to leaving the KZAK CTL and to entering the KOAK.

R E C A L L *


< L A T R E Q

<WH E N C A N WE

<M S G R E C O R D

<N OT I F I C A T I ON A T S U D L K

< R E T U R N

V E R T R E Q >

OT H E R R E Q >

T E X T >

R E P O R T S >

C O N N E C T I O N


A T C M E N U 1 / 2 """" ####

On the connection status page, KZAK is the active ATC. There is no NEXT ATC.

APPENDIX H



K Z A K

A T C M E N U

< R E T U R N

N E X T A T C

– – – –

– – – – – – – – – A D S : A RM E D – – – – –* S E T O F F


– – – – – – – D I S C O N N E C T * M S G L A T E N C Y

N O N E

A D S D E T A I L

Upon reception by the aircraft of an ATC message, both ATC MSG lights flash and as it is a normal message, the first telephone ring is delayed by 15 s, then it will be repeated every 15 s. Press on the ATC MSG pushbutton to extinguish the lights and stop the aural signal.

ATCMSG

ATCMSG

APPENDIX H


The message received from KZAK CTL is displayed on the DCDU, indicating that the next ATC is KOAK. Press the CLOSE softkey to store the message. On the connection status page, the next ATC is displayed: this is a "NO ANSWER" message.

1 1 0 7 Z F R O M K Z A K C T L

C L O S E

N E X T A T C : K O A K C T L

When the connection is established with the next ATC center, we can show it on the MCDU page in the NEXT ATC field.

C O N N E C T I ON S T A T U SA C T I V E A T C

K Z A K

A T C M E N U

< R E T U R N

N E X T A T C

K O A K

– – – – – – – – – A D S : A RM E D – – – – –* S E T O F F


– – – – – – – D I S C O N N E C T * M S G L A T E N C Y

N ON E

A D S D E T A I L

The message is closed: the DCDU screen is cleared. The active ATC is still KZAK and will change only when KZAK terminates the connection. The message can be recalled by pressing the RECALL softkey on the DCDU or displayed in the MSG RECORD page on the MCDU.

APPENDIX H


R E C A L L *


An uplink ATC message is received: both ATC MSG lights flash and as it is a normal message, the first telephone ring is delayed by 15 s, then it will be repeated every 15 s. Press on the ATC MSG pushbutton to extinguish the lights and stop the aural signal. When the SERVICE TERMINATED message is received from KZAK CTL , it is displayed on the DCDU. The ATC center has performed the connection operation and the communication is established. Press the CLOSE softkey to store the message.

1 1 1 0 Z F R O M K Z A K C T L


S E R V I C E T E R M I N A T E D

The message is closed: the DCDU screen is cleared. The new active ATC (KOAK CTL) is displayed on the DCDU.

ATC MSG

ATCMSG

APPENDIX H


4 - CLEARANCE The exchange of messages described in this scenario and the DCDU associated HMI are the same for FANS A and FANS A+. Refer to Appendix G (Operational scenarios FANS A - Deferred clearance) for further details. 5 - WHEN CAN YOU In this scenario, the ATC sends a question message containing the element “WHEN CAN YOU”. The received message is displayed on the DCDU.


* C A N N O T M O D I F Y *


W H E N C A N Y O U A C C E P T

F L 3 7 0

– – – – – – – – – – – – – – – – – – – – – – – –

W E C A N A C C E P T F L 3 7 0 N O W

[ 1 5 4 9 Z ]

Press the CANNOT softkey. The response message is automatically created. The text of the reply is displayed with the data field to fill in by means of the MCDU. Press the MODIFY softkey.





F L 3 7 0

– – – – – – – – – – – – – – – – – – – – – – – –

W E C A N N O T A C C E P T F L 3 7 0

APPENDIX H


Under the reply, the MCDU FOR MODIF information is displayed.


* C A N C E L

M O D I F Y *



F L 3 7 0

– – – – – – – – – – – – – – – – – – – – – – – –

W E C A N N O T A C C E P T F L 3 7 0

M C D U F O R M O D I F

The MESSAGE EDITION page comes into view on the MCDU. Press the CAN key on the MCDU, and it’s possible to enter the time parameter in the MCDU scratchpad and press the line key adjacent to the BY data field.

A T C

MO D I F D I S P L *

P A G E

C A N C E L

M E S S A G E MO D I F Y

A D D T E X T >*

C A N N O T F L 3 7 0

""""C A N F L 3 7 0

M E

A T C R E P O R T S

< R E T U R N

A T C

M O D I F D I S P L

P A G E

C A N C E L

M E S S A G E M O D I F Y

A D D T E X T >*

*

""""C A N N OT F L 3 7 0

C A N F L 3 7 0 A T

1 5 4 9 Z

M E

A T C R E P O R T S

< R E T U R N

APPENDIX H


A T C

M O D I F D I S P L

P A G E

C A N C E L


A D D T E X T >*

*

""""C A N N O T F L 3 7 0

C A N F L 3 7 0 A T

1 5 4 9 Z

1 5 5 5 Z

M E

A T C R E P O R T S

< R E T U R N

By pressing ATC MODIF DISPL, the DCDU message can be modified with the new time.

A T C

M O D I F D I S P L

P A G E

C A N C E L


A D D T E X T >*

*

""""C A N N O T F L 3 7 0

C A N F L 3 7 0 A T

1 5 5 5 Z

M E

A T C R E P O R T S

< R E T U R N

At this moment, crew can add text by pressing modify which cause TEXT page to be displayed on the MCDU.


* C A N N O T M O D I F Y *



F L 3 7 0

– – – – – – – – – – – – – – – – – – – – – – – –

W E C A N A C C E P T F L 3 7 0 A T

1 5 5 5 Z

APPENDIX H


A T C

M OD I F D I S P L

P A G E

C A N C E L


A D D T E X T >*

*

""""C A N N OT F L 3 7 0

C A N F L 3 7 0 A T

1 5 5 5 Z

M E

A T C R E P O R T S

< R E T U R N

T E X T 1 / 2 """"####

A T C M E N U

< R E T U R N

A L L F I E L D S

E R A S E A T C

T E X T D I S P L

D U E T O

M E D I C A L ####

D U E T O

""""WE A T H E R D U E T O



A T P I L O T S


– – – – – – F R E E T E X T – – – – – – –

[ ]


T E X T 1 / 2 """"####

A T C M E N U

< R E T U R N

*

*

I N P U T S

E R A S E A T C

M OD I F D I S P L

D U E T O

M E D I C A L ####

D U E T O

""""WE A T H E R D U E T O



A T P I L O T S


– – – – – – F R E E T E X T – – – – – – –

[ ]

D U E T O

A / C P E R F O RM .

APPENDIX H


The SEND softkey is now available. Press the SEND softkey.


S E N D *

1 5 5 5 Z

D U E T O A / C P E R F O R M A N C E

P G E

2 / 2

1 1 5 4 Z F R O M K Z A K C T L

S E N T

C L O S E *


F L 3 7 0

– – – – – – – – – – – – – – – – – – – – – – – –

W E C A N A C C E P T F L 3 7 0 A T

1 5 5 5 Z

P G E

1 / 2

Under the reply, the SENDING information is displayed TEMPORARILY. The message body changes to green once sent.

APPENDIX I


APPENDIX I

OPERATIONAL SCENARIOS ATS623

DEPARTURE CLEARANCE (DCL) On the DCDU, the default screen is displayed, indicating that the ARINC 623 ATC applications are available. The applications can be used as they are, no prior connection with the ground is required. (Note: this screen is displayed when there are ATC applications)

The Departure Clearance application is an ARINC 623 ATC application: these can be reached through the ATSU MENU by selecting the prompt ATS623, or directly by selecting the ATC COM hardkey:

M C DU ME N U

<F M1

<AT S U

APPENDIX I


Select the Departure Request application:

A T C M E N U

A T S U D L K

R E T U R N<

2 / 2 """" ####

– – – – – A T S 6 2 3 P A G E – – – – – –

<D E P A R T R E Q A T I S >

<O C E A N I C R E Q

Amber boxes represent fields that must be filled in order to send the Departure Clearance request: the function REQ DISPL (to display the request on the DCDU) will only be available (star present) when all mandatory fields are filled. The flight number is displayed in green: this colour indicates that the parameters is automatically set by the system (it comes from the FMS), and it is not modifiable. Parameters in cyan indicate modifiable parameters. Here the system has automatically filled the origin and destination airports (taken from the FMS). These are also mandatory parameters: if they are cleared, amber boxes will appear. Type in the aircraft type, and insert it in the corresponding field.

A T S 6 2 3 D E P A R T R E Q

A T C D E P A R T

R E Q D I S P L A T C M E N U

< R E T U R N

M O R E

F R E E T E X T >

A T C F L T N B R

A F R 0 0 6

F R O M / T O

L F P G / K J F K G A T E

[ ]

A / C T Y P E

!!!!!!!!!!!!!!!!

A T I S C O D E

!!!!

– – – – – – – – F R E E T E X T – – – – – – –

[ ]

A 3 2 0

APPENDIX I


Type in the ATIS code and insert it in the corresponding field.


A T C D E P A R T

R E Q D I S P L A T C M E N U

< R E T U R N

M O R E

F R E E T E X T >

A T C F L T N B R

A F R 0 0 6

F R O M / T O

L F P G / K J F K

G A T E

[ ]

A / C T Y P E

A 3 2 0

A T I S C O D E

!!!!

– – – – – – – – F R E E T E X T – – – – – – –

[ ]

H

As all mandatory fields are completed, the star appears in front of REQ DISPL, indicating that this function is available. For this example, let us add free text: type in the text and insert it.


A T C D E P A R T

R E Q D I S P L * A T C M E N U

< R E T U R N

M O R E

F R E E T E X T >

A T C F L T N B R

A F R 0 0 6

F R O M / T O

L F P G / K J F K

G A T E

[ ]

A / C T Y P E

A 3 2 0

A T I S C O D E

H– – – – – – – – F R E E T E X T – – – – – – –

[ ]

C H A R T E R E D F L I G H T

APPENDIX I


Type in the gate number (optional parameter) and insert it.


A T C D E P A R T


< R E T U R N

M O R E

F R E E T E X T >

A T C F L T N B R

A F R 0 0 6

F R O M / T O

L F P G / K J F K

G A T E

[ ]

A / C T Y P E

A 3 2 0

A T I S C O D E

H– – – – – – – – F R E E T E X T – – – – – – –


A 6 5

To add more free text, select the prompt MORE FREE TEXT.


A T C D E P A R T


< R E T U R N

M O R E

F R E E T E X T >

A T C F L T N B R

A F R 0 0 6

F R O M / T O

L F P G / K J F K

G A T E

A 6 5

A / C T Y P E

A 3 2 0

A T I S C O D E

H– – – – – – – – F R E E T E X T – – – – – – –


APPENDIX I


3 more lines of free text can be added. The first line of free text is already displayed on this page. Type in one line of text and insert it.

M O R E F R E E T E X T

A T C D E P A R T

R E Q D I S P L * D E P A R T R E Q

< R E T U R N

C H A R T E R E D F L I G H T [ ] [ ] [ ]

1 7 5 P A X O N B O A R D

It is possible to display the clearance request on the DCDU from this page also: select REQ DISPL.

M O R E F R E E T E X T

A T C D E P A R T

R E Q D I S P L * D E P A R T R E Q

< R E T U R N



[ ] [ ]

APPENDIX I


The Departure Clearance request is displayed on the DCDU. At it takes more than 1 page, page 1/2 is indicated. It is not possible to send the message before all pages have been visualised or printed: select PGE+ to see next page.

1 0 5 6 Z T O L F P G C T L O P E N

* C A N C E L

S E N D

D E P A R T U R E R E Q U E S T

A F R 0 0 6

F R O M : L F P G G A T E : A 6 5

T O : K J F K A T I S : H

A / C T Y P E : A 3 2 0

P G E

1 / 2

Page 2/2 is displayed and it is now possible to send the message: select SEND.

O P E N

* C A N C E L

S E N D *

A / C T Y P E : A 3 2 0



P G E

2 / 2

The message switches to green inverse video, indicating that is has been sent. The first page is displayed, with the SENDING indication.

1 0 5 6 Z T O L F P G C T L

C L O S E


A F R 0 0 6

F R O M : L F P G G A T E : A 6 5


A / C T Y P E : A 3 2 0

P G E

1 / 2

S E N D I N G

APPENDIX I


The SENT information indicates that the message has been received by the ground network. It is now possible to close the message. Closing the message stores it in the message log. Select CLOSE.

1 0 5 6 Z T O L F P G C T L

C L O S E *


A F R 0 0 6

F R O M : L F P G G A T E : A 6 5


A / C T Y P E : A 3 2 0

P G E

1 / 2

S E N T

The default screen is displayed, and the previous message can be recalled if required.

R E C A L L *

The flashing "ATC message" pushbuttons and the aural warning (telephone ring) indicate that a message from the ATC has been received: extinguish the alert by pushing a pushbutton.

ATC MSG

ATCMSG

APPENDIX I


The received message is displayed on the DCDU. As this new message contains several pages, "PGE 1/2" is displayed. The received message is the departure clearance. Its status for the moment is "OPEN" because no answer has been prepared yet. Proposed answers are REFUSE or ACK. It is not possible to select ACK before the whole clearance has been read, or printed. To read the following pages, select PGE+.

1 0 5 9 Z F R O M L F P G C T L O P E N

* R E F U S E

A C K < O T H E R

D E P A R T C L E A R A N C E N O 1 4 6

1 0 5 8 Z 2 5 J U N 2 0 0 0

F R O M : L F P G

A F R 0 0 6

C L R D T O : K J F K

P G E

1 / 2

The REFUSE and ACK answers are now selectable. Let us say, for this example, that you want to refuse the clearance: select REFUSE.

O P E N

* R E F U S E

A C K *< O T H E R


R W Y : 0 9 S I D : B N E 8 A

S Q K : 5 0 2 3 S L O T : 1 1 3 5 Z

F R E Q : 1 2 4 . 2 5 A T I S : H

H A V E A N I C E F L I G H T

P G E

2 / 2

On the DCDU, you can see that no datalink message has been sent to signify the refusal: you must contact the ATC by voice. The received clearance is repeated on the following pages, in green: select PGE+ to see the clearance.

APPENDIX I


1 0 5 9 Z F R O M L F P G C T L R E F U S E

* C A N C E L


C O N T A C T A T C B Y V O I C E

R E F U S E N O T S U P P O R T E D

B Y D A T A L I N K

– – – – – – – – – – – – – – – – – – – – – – – –


P G E

1 / 3

On each page of the refused clearance, the status "REFUSE" is displayed. However it is displayed in white, signifying that no downlink message has been sent.

R E F U S E

* C A N C E L



1 0 5 8 Z 2 5 J U N 2 0 0 0

F R O M : L F P G

A F R 0 0 6


P G E

2 / 3

For our example, let us finally decide that this clearance is convenient: as no message has been sent to the controller, the fact that we had refused this clearance will be transparent for the ground: the REFUSE state can be cancelled by selecting the corresponding softkey.

APPENDIX I


R E F U S E

* C A N C E L



R W Y : 0 9 S I D : B N E 8 A

S Q K : 5 0 2 3 S L O T : 1 1 3 5 Z

F R E Q : 1 2 4 . 2 5 A T I S : H

H A V E A N I C E F L I G H T

P G E

3 / 3

The clearance is displayed with the 'open' status, and the ACK and REFUSE functions are proposed: to accept the clearance, select ACK.

1 0 5 9 Z F R O M L F P G C T L O P E N

* R E F U S E

A C K *< O T H E R


1 0 5 8 Z 2 5 J U N 2 0 0 0

F R O M : L F P G

A F R 0 0 6


P G E

1 / 2

The message is displayed in the 'ACK' state. To send the DC readback, select SEND.

APPENDIX I


1 0 5 9 Z F R O M L F P G C T L A C K

* C A N C E L



1 0 5 8 Z 2 5 J U N 2 0 0 0

F R O M : L F P G

A F R 0 0 6


P G E

1 / 2

Temporarily the information 'sending' is displayed.


C L O S E< O T H E R


1 0 5 8 Z 2 5 J U N 2 0 0 0

F R O M : L F P G

A F R 0 0 6


P G E

1 / 2

S E N D I N G

When the ground service provider acknowledges reception of the message, the information 'sent' is displayed. The aircrew is informed that a confirmation of this readback must follow.

APPENDIX I




W A I T F O R C O N F I R M A T I O N

– – – – – – – – – – – – – – – – – – – – – – – –


1 0 5 8 Z 2 5 J U N 2 0 0 0

F R O M L F P G

P G E

1 / 2

S E N T

When the confirmation of the readback arrives, it is indicated to the crew with the visual and aural alerts: extinguish the alerts by pressing the ATC MSG pushbutton.

The departure clearance is confirmed. The message can now be closed (it will be stored).

1 1 0 0 Z F R O M L F P G C T L


D E P A R T M E S S A G E

A C K R E C E I V E D

1 0 5 9 Z 2 5 J U N 2 0 0 0

A F R 0 0 6

– – – – – – – – – – – – – – – – – – – – – – – –

P G E

1 / 3

ATCMSG

ATC MSG

APPENDIX J


APPENDIX J

OIT/FOT REF. 999.0001/03 NEW AIR TRAFFIC SERVICES UNIT (ATSU) AIRCRAFT INTERFACE

FROM : AIRBUS CUSTOMER SERVICES TOULOUSE TX530526 OPERATOR INFORMATION TELEX - OPERATOR INFORMATION TELEX AND FLIGHT OPERATIONS TELEX - FLIGHT OPERATIONS TELEX TO : FANS A OPERATORS ON A330/A340 (A340-500/-600 EXCLUDED) SUBJECT : A330/A340 - ATA 46 -NEW AIR TRAFFIC SERVICES UNIT (ATSU) AIRCRAFT INTERFACE SOFTWARE VERSION CLR3.6B AND FMS VERSION P2 FOR ENHANCED AUTOMATIC DEPENDENT SURVEILLANCE (ADS) OUR REF.: SE 999.0001/03/VHR DATE 07 JAN 2003 OIT CLASSIFICATION: ENGINEERING AND OPERATIONAL RECOMMENDATION I/ VALIDITY: ALL A330 AND A340 AIRCRAFT EQUIPPED WITH FANS A - FORWARD FIT: MODIFICATION 48227 EMBODIED - RETROFIT: AIRBUS SB A330-46-3006/A340-46-4010. A340-600 AND A340-500 ARE NOT CONCERNED BY THIS OIT/FOT SINCE THE SUBJECT CONFIGURATION IS BASIC AT THE ENTRY INTO SERVICE. II/ REASON THE PURPOSE OF THIS OIT/FOT IS TO ADVISE A330/A340 FANS A OPERATORS OF ATSU SOFTWARE CLR3.6B AND FMS P2 CERTIFICATION. ASSOCIATION OF ATSU SOFTWARE CLR3.6B AND FMS P2, WILL ADDRESS THE FOLLOWING ISSUES: - MISSING ADS REPORTS - DOWNSTREAM ADS REPORTS - ADS REPORTS WITH MISSING PREDICTIONS OR MISSING ETA (ESTIMATED TIME OF ARRIVAL) AT ''TO'' WAYPOINT. THIS CONFIGURATION IS ALREADY IN SERVICE ON THE A340-600 AND PROVES FULLY SATISFACTORY. III/ DESCRIPTION IIIA) ATSU ATSU SOFTWARE CLR3.6B CORRECTS MISSING ADS AND PARTIALLY ADDRESSES DOWNSTREAM ADS REPORTS (ATSU REPRESENTS 80 PERCENT OF FULL CORRECTION BY FMS P2/ATSU CLR3.6B). ATSU SOFTWARE UPGRADE TO CLR3.6B PN LA2T0S11105J0F1 (FIN 20TX) FROM CURRENT FANS A SOFTWARE CLR3.5B PN LA2T0S11105G0F1 CAN BE DONE BY ATSU SOFTWARE UPLOADING ON THE AIRCRAFT. PLEASE NOTE THAT CURRENT ATC (AIR TRAFFIC CONTROL) AND AOC (AIRLINE OPERATIONAL COMMUNICATION) APPLICATIONS, FIN 25TX, 26TX, 27TX, 28TX, 29TX, 22TX AND 24TX INSTALLED IN THE CURRENT FANS A CONFIGURATION REMAIN COMPATIBLE WITH CLR3.6B. UPLOADING OF 20TX SOFTWARE HOWEVER CAUSES ERASURE OF ALL APPLICATIONS PREVIOUSLY

APPENDIX J


LOADED, THUS THE COMPLETE ATSU SOFTWARE MUST BE RELOADED DURING THE UPGRADE TO CLR3.6B. CLR3.6B SOFTWARE CAN BE USED WITH ATSU HARDWARE PN LA2T0G20503B040 OR PN LA2T0G20503B050. ATSU CLR3.6B CERTIFICATION AND RETROFIT ARE COVERED THROUGH: - MOD 50323 - AIRBUS FRANCE AVIONICS AND SIMULATION PRODUCTS VSB REFERENCE LA2T0-46-008 DISPATCHED ON 09TH OCTOBER 2002 - SB A330-46-3011 OR SB A340-46-4011 BOTH EXPECTED FOR DISPATCH BY THE 28TH FEBRUARY 2003. PRODUCTION EMBODIMENT RANK FOR ATSU CLR3.6B IS MADE/SCHEDULED FROM A330 MSN 510 AND A340 MSN 528. IIIB) FMS FMS P2 ADDRESSES ADS REPORTS WITH MISSING POSITION AND REDUCES OCCURRENCE RATE OF MISSING ETA/ALTITUDE AT ''TO'' WAYPOINT, AND COMPLETES CORRECTION TO DOWNSTREAM ADS REPORTS (FMS P2 REPRESENTS 20 PERCENT OF FULL CORRECTION BY FMS P2/ATSU CLR3.6B). FOR FMS P2 UPGRADE, TWO CASES MUST BE DISTINGUISHED: 1/ A330 FMS P2CD7 FOR PW-RR ENGINES/FMS P2B7 FOR GE ENGINES UPGRADE FROM FMSP1CD7/P1B7 CONSISTS IN: - FM OPERATIONAL SOFTWARE (FIN 1CA0M3) UPGRADE TO PN PS4087700-902 FROM PN PS4087700-901 - FM PERFORMANCE DATABASE (FIN 1CA0M2) UPGRADE TO PN PS4087705-903 FROM PN PS4087705-901 FMGEC HARDWARE AND FG OBRM ARE NOT IMPACTED BY THIS CHANGE ON A330. CAUTION: FM OPERATIONAL SOFTWARE (FIN 1CA0M3) UPGRADE MUST BE DONE ON BOTH FMS ON THE AIRCRAFT VIA THE MDDU. INDEED, USE OF THE CROSSLOADING FUNCTION FOR FM OPERATIONAL SOFTWARE (FIN 1CA0M3) UPGRADE ON SECOND FMS IS FORBIDDEN DUE TO A P1 SOFTWARE UPLOAD LIMITATION, ADDRESSED THROUGH P2 UPGRADE. BUT FMS CROSSLOADING CAN BE USED FOR SECOND FMS UPLOADING WITH FM PERFORMANCE DATABASE (FIN 1CA0M2), OPERATIONAL PROGRAM CONFIGURATION (OPC), AIRLINE MODIFIABLE INFORMATION (AMI) AND NAVDATABASE. 2/ A340 FMS P2A10 UPGRADE FROM P1A9 FOR CFMI ENGINES CONSISTS IN: - FMGEC HARDWARE CHANGE TO PN C12858AA03 FROM PN C12858AA02 VIA FG OBRM REPLACEMENT - ABOVE MENTIONED FM PERFORMANCE DATABASE (FIN 1CA0M2) AND FM OPERATIONAL SOFTWARE (FIN 1CA0M3) UPGRADES, APPLY ALSO TO THE A340 (SAME SOFTWARE PN) AND ARE ALSO TO BE DONE ON AIRCRAFT. THE SAME CROSSLOADING LIMITATIONS OF ABOVE CAUTION PARAGRAPH APPLY TO P2A10 UPGRADE ON A340. FMS P2 CERTIFICATION AND RETROFIT WILL BE COVERED THROUGH: - MOD 50716/SB A330-22-3042 FOR A330 PW-RR - MOD 50717/SB A330-22-3043 FOR A330 GE - MOD 50718/SB A340-22-4035 FOR A340 CFM.

APPENDIX J


MODIFICATION 50716 AND 50717 EXPECTED FOR CERTIFICATION BY MID JANUARY 2003, MODIFICATION 50718 BY MID FEBRUARY 2003. AIRBUS SBS ARE EXPECTED TO BE DISPATCHED BY THE 28TH FEBRUARY 2003. THE OPERATIONAL PROGRAM CONFIGURATION (OPC), THE AIRLINE MODIFIABLE INFORMATION (AMI) AND EVEN THE NAVDATABASE CYCLES PREVIOUSLY USED ON FMS P1 REMAIN COMPATIBLE WITH FMS P2. THOSE SOFTWARE WILL HOWEVER NEED TO BE RELOADED AFTER FM PERFORMANCE AND OPERATIONAL SOFTWARE UPLOAD. PRODUCTION EMBODIMENT RANK FOR FMS P2 IS SCHEDULED FROM: - A330 RR/PW: MSN 526 - A330 GE: MSN 530 - A340 CFMI: MSN538 IV) RECOMMENDATION IN ORDER TO EASE ATSU CLR3.6B AND FMS P2 RETROFIT ON ALL AIRCRAFT TYPES, CORRESPONDING AIRBUS SB'S WILL NOT BE PHYSICALLY LINKED. THIS WILL ALLOW PROCEEDING SEPARATELY WITH ATSU THEN FMS RETROFIT. HOWEVER, IN ORDER TO ENSURE SUBSTANTIAL ADS PERFORMANCE IMPROVEMENT, IT IS HIGHLY RECOMMENDED TO PROCEED FIRST WITH ATSU SOFTWARE UPGRADE, THAT CORRECTS THE MAJOR ADS ISSUE, I.E. MISSING ADS REPORT. ASSOCIATION OF FMS P2 WITH ATSU CLR3.5B WOULD DEGRADE ADS PERFORMANCE. AIRLINES ARE HOWEVER RECOMMENDED TO TAKE APPROPRIATE ACTIONS TO ENSURE THAT WITHIN A REASONABLE TIME, FMS P2 UPGRADE IS MADE ON TOP OF ATSU CLR3.6B. V) RETROFIT ATSU CLR3.6B/FMS P2 RETROFIT, MONITORED BY AIRBUS (SET4), WILL START SOON AFTER SB ISSUE AND WILL BE ANNOUNCED BY A RETROFIT INFORMATION LETTER. EACH OPERATOR WILL THEN BE CONTACTED INDIVIDUALLY BY AIRBUS FRANCE AND THALES AVIONICS, THROUGH A CUSTOMIZED RETROFIT PLANNING LETTER (RPL), IN ORDER TO FORMALIZE THE LOGISTICAL ASPECTS OF THE RETROFIT CAMPAIGN. VI) OPERATIONAL REPERCUSSIONS ONCE BOTH FMS P2 AND ATSU CLR3.6B ARE RETROFITTED ON THE FANS A FLEET OF A GIVEN AIRLINE, THE RECOMMENDATION OF FOT REFERENCE STL 999.0022/02 REV01- JC/FPA DATED 24 MAY 2002 QUOTED HEREAFTER BECOMES OBSOLETE AND SHOULD NOT BE FOLLOWED ANYMORE : QUOTE - DURING FLIGHTS ON NORTH ATLANTIC ROUTES, IT HAS BEEN REPORTED THAT, SOMETIMES, ADS REPORTS ARE NOT TRIGGERED WHEN OVERFLYING A WAYPOINT. WHEN THE FMS2 IS THE MASTER, AND SEQUENCES A WAYPOINT BEFORE FMS1, IT MAY OCCUR THAT THE ATSU DOES NOT DETECT THE WAYPOINT CHANGE EVENT. TO AVOID MISSING ADS REPORTS, WHEN OVERFLYING A WAYPOINT, DO NOT USE AP2 DURING ADS OPERATIONS. UNQUOTE

APPENDIX J


BUT, THE OTHER RECOMMENDATIONS MADE IN THE SAME FOT REMAIN APPLICABLE AS THEY CONCERN NOMINAL SYSTEM OPERATION. THOSE FLIGHT OPERATION RECOMMENDATIONS ARE REPEATED THEREAFTER AS A REMINDER: IN ORDER TO IMPROVE ADS OPERATIONAL EFFICIENCY, AIRBUS HAS THE FOLLOWING RECOMMENDATIONS: - DO NOT TRY TO LOGON / NOTIFY THE ATC CENTRE, IF AIRCRAFT REGISTRATION AND FANS CAPABILITY HAVE NOT BEEN DECLARED TO CONCERNED ATC CENTRES, OR IF AGREEMENT FOR ADS (FANS) UTILIZATION HAS NOT BEEN OBTAINED FROM THESE ATC. - DO NOT PERFORM SPONTANEOUS FANS TESTING WITH ATC CENTRES, WHEN THEY HAVE NOT BEEN PREVIOUSLY NOTIFIED OF A GIVEN AIRCRAFT'S INTENTION TO OPERATE IN FANS MODE. - TO USE THE ADS SYSTEM, THE FOLLOWING RULES MUST BE OBSERVED: - THE ADS SYSTEM MUST BE SET TO ON, PRIOR TO PERFORMING AN ATC NOTIFICATION. THE ADS IS NORMALLY SET TO ON BY DEFAULT. THIS CAN BE CHECKED BY SELECTING "ATSU" ON THE MCDU MENU PAGE, THEN "ATC MENU" ON THE ATSU DATALINK PAGE, AND "CONNECTION STATUS" ON THE ATC MENU PAGE. - ONCE THE ATC CENTRE HAS BEEN NOTIFIED ("NOTIFIED" IS DISPLAYED ON THE MCDU), THE ADS WORKS TRANSPARENTLY TO THE FLIGHT CREW AND SHOULD NOT BE SET TO OFF, UNLESS INSTRUCTED TO DO SO (E. G. ATC REQUEST). IF THE ADS IS SET TO OFF, THE ATC CENTRE CAN NO LONGER BE PROVIDED WITH ADS REPORTS. - DO NOT ACTIVATE THE ADS EMERGENCY MODE, WITHOUT GOOD REASON. - DO NOT MODIFY THE SCAN MASK SETTING, IF NOT REQUIRED BY AIRLINE POLICY. THE SCAN MASK IS A LIST OF THE VHF DATALINK SERVICE PROVIDERS, USED BY ATSU, TO OPERATE IN VHF DATALINK. MODIFICATION OF THE SCAN MASK SETTING MAY RESULT IN THE LOSS OF AIR-GROUND VHF DATALINK COMMUNICATION. AIRLINES MUST DEFINE A SORTED LIST, BASED ON THEIR RESPECTIVE AGREEMENT WITH DATALINK SERVICE PROVIDERS. VII) REFERENCE DOCUMENTS TFU 46.22.00.001: ADS ISSUES. DETAILS ADS ISSUES EXPERIENCED WITH ATSU CLR3.5B/ FMS P1, AND SOLUTIONS DESIGNED THROUGH ATSU CLR3.6B/ FMS P2. QUESTIONS ABOUT THE TECHNICAL CONTENT OF THIS OIT ARE TO BE ADDRESSED TO MR. C. CASSIAU-HAURIE, DEPT. SEE4, PHONE +33/(0)5 62 11 05 25, FAX +33/(0)5 61 93 44 25. QUESTIONS CONCERNING THE OPERATIONAL CONTENT OF THIS FOT ARE TO BE ADDRESSED TO MR. JACQUES CASAUBIEILH, DEPT. STLS / PHONE +33/(0)5 61 93 40 41, FAX +33/(0)5 61 93 29 68. BEST REGARDS. P. GLAPA C. MONTEIL VICE PRESIDENT, SYSTEMS & POWERPLANT VICE PRESIDENT ENGINEERING SERVICES FLIGHT OPERATIONS CUSTOMER SERVICES DIRECTORATE SUPPORT AND LINE ASSISTANCE

APPENDIX K


APPENDIX K FANS A AIRWORTHINESS SUMMARY

(Ref. 555.1221/00) 1 - PURPOSE AND SCOPE The purpose of this document is to describe the characteristics of the operational environment and the interoperability, safety and performance requirements that have been considered for the development and airworthiness approval of the Airbus Industries AIM FANS A avionics package that supports Air Traffic Services datalink applications. It also summarises the main results and achievements of interoperability, safety and performance demonstrations that have been conducted by Airbus Industries. This document is an outcome of the AIM FANS A Airworthiness Approval process intended to be widely distributed to any party planning to make use of data communications for Air Traffic Services purposes. This document is primarily intended for Operators, ATC Service Providers and National Aviation Authorities. They should refer to this document when deciding on how to implement operations based on data communications for ATS purposes. It may also be used by Operators as substantiating data in order to help in obtaining operational changes. This document contains : - Section 2 : the description of the operational environment in which the AIM FANS A package is intended to be used. This description was used as the basis for the end-to-end Hazard Analysis, - Section 3 : the listing of all industry standards considered for the development of the datalink applications, and the record of all clarifications, additions and/or deviations to those standards, applicable to the AIM FANS A avionics systems, - Section 4 : the list of all assumptions placed on the ATS Ground Systems and Communication Service Providers that must be fulfilled, - Section 5 : an overview of the interoperability, safety and performance demonstrations achieved during the airworthiness approval process of the AIM FANS A package. This section also provides a set of flight crew procedures, - Section 6 : a proposal for a list of checks and verifications that Operators and ATC providers may wish to perform before starting operations. The scope of this document is limited to Air Traffic Services datalink communications implemented in the AIM FANS A avionics package. These functions to be considered are : . ATS Facilities Notification (AFN), . Controller-Pilot DataLink Communication (CPDLC) . Automatic Dependent Surveillance (ADS) The underlying communication network is the ACARS Air-Ground Network. This document does not cover : . the Airline Operational Communication (AOC) applications : these applications are considered as « user-modifiable software » and are therefore not covered by the Airworthiness Approval granted for the basic AIM FANS A package. The definition of the AOC applications and obtaining its subsequent approval is the responsibility of the operator, . the ground-to-ground ATS communications, . the process for declaring an ATS Ground System as « operational ».

APPENDIX K


2 - OPERATIONAL ENVIRONMENT DESCRIPTION The AIM FANS A avionics package has been designed to be operated in an operational environment having the characteristics specified below. Any operational environment that fulfills these characteristcs is classified as « FANS A Code 1 » according to an Airbus Industries internal terminology. These characteristics have been considered during the end-to-end Functional Hazard Analysis (FHA) conducted in the frame of the AIM FANS A Airworthiness Approval. Therefore, Operators or National Aviation Authorities willing to implement operations using AIM FANS A datalink communication capabilities must ensure the foreseen environment satisfies these characteristics.

The characteristics of a FANS A Code 1 operational environment are the following :

ENVIRONMENT - Airspace type : oceanic / Remote - Traffic Density : low - Traffic Complexity : in convoy - Datalink Operations : En-Route / Cruise - Airspace Management : procedural (based on CPDLC Position Reports and/or ADS information) - Aircraft Separation Minima : lateral : 50 NM

longitudinal : 50 NM vertical : 2000 ft, 1000 ft with RVSM

COMMUNICATION, NAVIGATION, SURVEILLANCE CAPABILITIES

Communications Datalink communications is assumed to be the primary means of communication between Air Traffic Controller and Flight Crew. However, all existing voice communication media must be available for back-up communications and reversion to conventional ATM operations must be made using the following communication means as appropriate :

- VHF - direct HF - third party HF - SATCOM voice

Note : other communication means do exist to enable quick ATC centre – flight crew communications, but no benefit has been claimed for the use of these means in the end-to-end Functional Hazard Analysis. These are :

- CPDLC free text - VHF with other aircraft in the vicinity - Any other usable means (e.g. passenger phone).

Navigation

RNP10 navigation performance has been assumed as an acceptable performance to allow, in conjunction with both communication and surveillance means, a 50x50 NM aircraft separation minima.

Surveillance CPDLC and/or ADS reports are the primary means of surveillance. Voice position report (using VHF, HF or SATCOM voice as appropriate) must be kept as back-up means.

APPENDIX K


3 - INDUSTRY STANDARDS FOR AVIONICS SYSTEM

Industry Standards define the interoperability requirements for Air Traffic Services supported by data communications. Industry has recognised that some of these requirements needed additions, clarifications and/or changes. All amendments to these initial standards have been validated by Communication Service Providers, ATS Providers and their system suppliers within the frame of standardisation activities led by the EUROCAE WG53 / RTCA SC-189 joint group.

Note : results of this standardisation activity is now published by EUROCAE under document ED-100.

This section lists the interoperability requirements resulting from this joint group that Airbus Industries has elected to apply in the development of the AIM FANS A avionics systems.

3.1 - Datalink Applications 3.1.1 - ATS Facilities Notification (AFN)

AIM FANS A system complies with ARINC 622-2 specification, Section 3 for the AFN application. Deviations to this specification have been made as indicated in Appendix #1 « Amendments to ARINC 622-2 for AFN application ».

3.1.2 - Controller Pilot DataLink Communications (CPDLC) AIM FANS A system complies with DO-219 MOPS (dated August 27, 1993), section 2.2.2 through

2.2.6. Deviations to this standard have been made as indicated in Appendix #2 « Amendments to DO-219 for CPDLC application ». In addition, specific design choices have been made that particularise the AIM FANS A package :

- DO-219 does not specify message pairing for all uplink messages. Appendix 3 « CPDLC Message Pairing » provides information as to the mapping between uplink report/confirmation request and corresponding downlink reports generated by the AIM FANS A system.

- Datalink communications involving [Position] or [RouteClearance] variables activate interface and functions with the on-board Flight Management System (FMS). Particular attention must be paid to the encoding by the ground system of these elements to ensure proper treatment by the on-board FMS once the uplink message is delivered to the aircraft. These specific guidelines are provided in Appendix 4 « [Position] and [RouteClearance] Variable Processing ».

- Finally, Appendix 5 « CPDLC Error Processing » gives the list of conditions under which the CPDLC application transmit an error message. Signification of the associated error code used in the [ErrorInformation] element is also given in this Appendix.

3.1.3 - Automatic Dependent Surveillance (ADS)

The AIM FANS A system complies with DO-212 MOPS (dated October 26, 1992) section 2.2.1. Deviations to this standard have been made as indicated in Appendix 6 « Amendments to DO-212 for ADS application ».

Note : appendices assume previous knowledge of AFN, CPDLC and ADS MOPS.

APPENDIX K


3.2 - Communications protocols 3.2.1 - ACARS Convergence Function (ACF) The AIM FANS A system complies with :

- ARINC 622-2 Specification, Section 2 for the ACARS Compatible System with no deviation - ARINC 622-2 Specification, Section 4 for the Support of Bit-Oriented Applications. Deviations to this

specification have been made as indicated in Appendix 7 « Amendments to ARINC 622-2 for Application Interface ».

3.2.2 - Communication protocols The AIM FANS A system complies with the following communication protocols :

- ARINC 620 « Datalink Ground System Standard and Interface Specification » - ARINC 619 « ACARS Protocols for Avionics End Systems » - ARINC 618 « Air Ground Character Oriented Protocol Specification »

3.3 - Communication means The AIM FANS A system is able to exchange datalink messages for ATS purposes over the following communication media :

- SATCOM - VHF Data Radio

APPENDIX K


4 - INTEROPERABILITY & SAFETY REQUIREMENTS FOR ATS GROUND SYSTEMS Datalink communications require that end-to-end requirements be specified and complied with by all systems involved in the realisation of the functions (i.e. ATS Systems, Communication Service Providers and Airborne Avionics). Airworthiness Approval of the AIM FANS A ensures that the avionics package complies with the requirements and industry standards listed in Section 3 of this document. Formally speaking, industry standards apply to aircraft systems only. In order to ensure end-to-end interoperability, it has been found necessary to produce interoperability requirements applicable to Communication Service Providers’ systems and to ATS Providers’ systems. This activity has been done within the EUROCAE WG53 / RTCA SC-189 joint group. In addition, while conducting the end-to-end Functional Hazard Analysis, Airbus Industries has made some assumptions concerning design features of the ATS Ground Systems and/or ATC Controller’s behaviours and procedures. These assumptions are used in the FHA to mitigate the effects of functional failure and incorrect behaviours. These assumptions become Safety Requirements that must be considered by ATS Service Providers. This section lists the resulting Interoperability and Safety requirements applicable to Communication Service Providers’ systems and/or ATS Providers’ systems. Airbus Industries assumed that these requirements would be satisfied in order to ensure continued interoperability and safety of the AIM FANS A package. 4.1 - INTEROPERABILITY & TECHNICAL REQUIREMENTS FOR ATS GROUND SYSTEMS 4.1.1 - Communication services

- All FANS A communications shall comply with ARINC Specifications 618, 620, and 622. - All FANS A uplink traffic shall be identified by the use of “A” labels as described in ARINC

Specification 620. - All FANS A downlink traffic shall be identified by the use of “B” labels as described in ARINC

Specification 620. - Recording of datalink messages : on-ground recording of all datalink messages, including time

stamp, shall be provided. - ATS Providers shall have the capability to request notification of successful delivery for uplink

messages, via the Message Assurance (MAS) function (as described in ARINC Specification 620). - Every uplink message from an ATS Provider shall use the aircraft registration number which is

contained within the portion of the AFN logon message (FN_CON) that is encapsulated by the Cyclical Redundancy Check (CRC).

- Since FANS A downlink messages do not include a Message Function Identifier (MFI), the ATS Provider shall use the following uplink Standard Message Identifiers (SMI), as defined in ARINC Specification 622 for each application :

- “ATC” for CPDLC application, - “AFU” for AFN application, - “RAR” for ADS application.

- For FANS A uplink messages, the optional MFI shall not be used; that is, the address will immediately follow “/” in the free text format. Note : uplink messages containing a MFI will be discarded by the AIM FANS A avionics package.

- As the Communication Service Provider determines the routing of FANS A messages to the aircraft, the following text elements (described in ARINC Specification 620, Section 3.7) shall not be used by an ATS Provider in uplink messages : AP, GL, TP because the CSPs have the responsibility for routing of uplink messages.

APPENDIX K


4.1.2 - Datalink Applications The ATS Ground Systems supporting Air Traffic Services Datalink Applications shall implement datalink applications compatible with :

- ARINC 622-2 Specification Section 2 for the ACARS Convergence Function, as amended according to the table included in Appendix 8 « Amendments to A622 ACARS Convergence Function for ATS Ground Systems ».

- ARINC 622-2 Specification Section 3 for the AFN application, as amended according to the table included in Appendix 9 « Amendments to A622 AFN Application for ATS Ground Systems ».

- DO-219 MOPS, Sections 2.2.2 through 2.2.6 for the CPDLC application, as amended according to the table included in Appendix 10 « Amendments to DO-219 CPDLC Applicaion for ATS Ground Systems ».

- DO-212 MOPS, Section 2.2.1 for the ADS application, as amended according to the table included in Appendix 11 « Amendments to DO-212 ADS Application for ATS Ground Systems »

4.2 - INTEROPERABILITY & TECHNICAL REQUIREMENTS FOR COMMUNICATION SERVICE PROVIDERS Where the term “ATS contracted CSP” is used in this Section, it refers to the particular CSP contracted by an ATS Provider to provide all FANS A datalink services (e.g. VHF and SATCOM). The term “alternate ATS CSP” applies to another CSP whose network is needed by the ATS Provider to communicate with some aircraft.

- All FANS A communications shall comply with ARINC Specifications 618, 620, and 622. - All FANS A uplink traffic shall be identified by the use of “A” labels or Message Function Identifiers

(MFIs) as described in ARINC Specification 620. - All FANS A downlink traffic shall be identified by the use of “B” labels or Message Function

Identifiers as described in ARINC Specification 620. - Recording of datalink messages : on-ground recording of all datalink messages, including time

stamp, shall be provided. - CSPs shall support the message assurance function as described in ARINC Specification 620. If the

ATS Provider requests Message Assurance (MAS), the ATS contracted CSP shall provide one of the following notifications to the ATS Provider for each uplink message :

- "success" (MAS/S) indicating that the uplink message has been received and positively acknowledged by the aircraft.

- "failure" (MAS/F) indicating that the all parts of the uplink message have not been received and positively acknowledged by the aircraft, or have been delayed.

- "not known" (MAS/X) indicating that the CSP is unable to provide an indication of delivery for this uplink message.

- The CSPs shall use unique uplink block identifiers (UBIs) for uplink messages to a given aircraft. - From the downlink message, the CSP shall extract the address of the ATS Provider to which the

message will be delivered. - The CSP shall translate the message from air-ground (type-A) format to ground-ground (type-B)

format. - When a downlink message is received by the Central Processor of a CSP, it shall be routed to the

unique address of the ATS Provider. - The CSP shall use either of the following mechanisms in the CP to provide this routing:

- mapping of 4 character supplemental address to the corresponding 7 character IATA Type B address, or

- use of actual 7 character supplemental address in the downlink message.

- The 7 character address assignment of each ATS Provider is unique and shall be configured in the networks of all CSPs.

APPENDIX K


- If the addressed ATS Provider is not connected to the ground network of the CSP which received

the downlink message, the message shall be forwarded to the correct CSP’s network via a connection between the networks of the CSPs.

- Each CSP offering FANS A communication service to an ATS Provider shall support an internetworking function.

- Communication shall only be attempted via a maximum of two media or CSP. - The internetworking function shall address and deliver the message to the appropriate CSP for

delivery (based on current media advisory information or default delivery preferences), with the request for Message Assurance delivery confirmation.

- If successful delivery (indicated by receipt of an aircraft ACK as described in ARINC Specification 618) is achieved, a Message Delivery Confirmation message shall be returned to the internetworking function.

- Upon receipt of the Message Delivery Confirmation message the internetworking function shall forward this to the ATS Provider, if requested as the message assurance.

- If delivery is unsuccessful (indicated as described in ARINC Specification 618), either an Untransmittable Message Assurance or an Undeliverable Message Assurance shall be returned to the internetworking function.

- Receipt of these messages by the internetworking function shall result in either : - another attempt at message delivery as required by the routing logic in the internetworking

function or; - the Untransmittable Message Assurance or Undeliverable Message Assurance being forwarded

to the ATS Provider, if requested. - If VHF is available then uplink delivery shall be attempted via VHF. - If VHF is available and delivery is not successful or VHF is unavailable and the aircraft is a

contracted user and is logged-on to the CSPs satellite service, uplink delivery shall be attempted via satellite.

- If VHF is available and the attempt at delivery via VHF was not successful, uplink delivery shall be attempted via the satellite communications facilities of an alternate CSP.

- If communication is not possible via the ATS contracted CSP and the aircraft is using the air-ground facilities of an alternate CSP, then uplink delivery shall be attempted via the alternate CSP.

- If the first uplink delivery attempt was made via an alternate CSP (VHF) provider and was unsuccessful, the second uplink delivery attempt shall be made via the aircraft’s contracted satellite datalink service provider.

- Media Advisory downlinks shall be delivered to the internetworking functions of all CSPs, which use the media advisory message.

- In the absence of media advisory messages or if the first attempt to deliver a message has failed then the internetworking function shall forward the message to the next CSP as determined by contractual arrangements of the particular Operator.

4.3 - SAFETY REQUIREMENTS FOR ATS GROUND SYSTEMS & COMMUNICATION SERVICE

PROVIDERS Airbus Industries has performed an end-to-end Functional Hazard Analysis for the AIM FANS A functions where Functional Failures and Incorrect Behaviour of the functions were analysed and evaluated for their effects and impacts on flight crew, ground ATC and airspace. Doing so, a number of detection means, protections or barriers, and procedures were assumed to be implemented in the ATS ground systems. These assumptions made on the ground systems have been presented to the JAA Team during the AIM FANS A Airworthiness Approval process. They have all been accepted as being realistic assumptions for an ATS Provider implementing datalink communications. However, these assumptions turn out to be Safety Requirements that ATS providers must comply with prior to start actual operations based on CPDLC and ADS in order to ensure adequate safety level is attained.

APPENDIX K


4.3.1 - GROUND PROCEDURES

- GP#1 : Area of control

The ATCO shall not issue a clearance to an aircraft that is not in his area of control. - GP#3 : Entering aircraft check

When the ATC controller receives the first CPDLC Position Report from an aircraft, he must check that this aircraft is in his FIR.

- GP#4 : Flight Plan/Flight Number check During any notification procedure (AFN), the ATC ground system or controller must check that the

flight number and A/C Tail Number match with those of the registered Flight Plan. - GP#10 : Non reception of an expected ADS report

In case of signaled non-reception of an expected ADS report, the ATC controller shall take appropriate corrective action ASAP (e.g. by sending a demand contract or establishing a new periodic contract with the aircraft.

- GP#13 : CPDLC report delay If an A/C has to report via CPDLC its position at a given time, and fails to report its position within

Tr=3minutes, the ATC controller shall take appropriate action to establish communication. If communication is not established within Tc=8minutes from the time the report should have been received, an alternative form of separation shall be applied.

4.3.2 - GROUND TECHNICAL REQUIREMENT - GT #1 : Ground/Ground communications

A telephone back-up is assumed for inter-facility data communication (ground/ground) and procedures are established for its use.

- GT #2 : CPDLC and ADS use Processing of CPDLC and ADS position reports shall be developed to allow primary means of

surveillance (e.g. separation assurance, up to reduction of separation). - GT #3 : Alert of non-reception of CPDLC/ADS report Controller shall be alerted in case of non-reception of expected ADS report or CPDLC position report. - GT #6 : communication outage information

The communication service provider shall inform ATS srvice providers involved in the operation of the datalink system in case of communication outage (satellite, RGS)

- GT #7 : Internetworking Internetworking between service providers shall ensure correct process of ATC datalink messages. - GT #8 : Error detection The ATC system must be able to detect that the aircraft is deviating from its assigned route. If the

deviation exceeds 7.5NM, data of the predicted and A/C intent groups may prove to be incorrect. In this situation, the ATC system should base extrapolation of the aircraft trajectory on track data rather than on predicted group and intent group data.

4.3.3 - COMMON TECHNICAL REQUIREMENTS - CT #1 : Back-up communication

The ATC centres and the aircraft shall have backup communication systems. All voice capabilities must be retained (HF, VHF, SATCOM).

- CT #2 : Timers There shall exist timers for the ATC controllers and flight crews to monitor the air/ground processing

status of a message. These timers must be consistent with the communication performance objectives : - response time for donwlink message (one way) : 1 minute 95% of the time - response time for uplink message (round trip) : 2 minutes 95% of the time. - CT #6 : CRC

CRC must be implemented against air/ground segment corruption of each uplink or downlink message. For interoperability reasons, this 16 bit CRC has been agreed as an accpetable means of compliance with this objective.

APPENDIX K


5 - INTEROPERABILITY, SAFETY & PERFORMANCE DEMONSTRATIONS ACHIEVED FOR AIM FANS A SYSTEM This section provides the results and achievements of Interoperability, Safety and Performance demonstrations conducted by AIRBUS INDUSTRIES in the frame of the Airworthiness Approval of the AIM FANS A package. These demonstrations were conducted according to the AIRBUS INDUSTRIES document « FANS A : Interoperability, Safety and Performance Demonstration Test Plan » that has been agreed by the JAA. In addition, this section provides with inputs for procedures to be applied by the flight crew. 5.1 - INTEROPERABILITY DEMONSTRATIONS Airbus Industries has demonstrated compliance to industry standards as indicated in Section 3 of this document thanks to a combination of simulator tests and flight tests. In both cases, the avionics package under test was in a configuration representative of the AIM FANS A production package configuration. Peer ground systems used for Interoperability demonstrations were a combination of simulated ATC system and several actual ATC systems where AFN, CPDLC and ADS applications are recognised as « operational » for ATS purposes (i.e. daily used). The AIM FANS A package complies with Interoperability requirements listed in Section 3, and AFN, CPDLC and ADS applications may be used with ATS Ground Systems compliant with Interoperability requirements listed in Section 4 of this document. 5.2 - SAFETY DEMONSTRATIONS Based on the end-to-end Functional Hazard Analysis conducted by Airbus Industries, a list of Failure Conditions has been deduced and allocated to the avionics package. Safety Objectives were specified for each Failure Condition. Failure Condition allocated to the aircraft were ranked from MINOR to MAJOR effects, according to classification per JAR 25.1309. Airbus Industries has conducted a System Safety Analysis of the AIM FANS A package in order to demonstrate compliance to these Safety Objectives : all Safety Objectives are satisfied. The following assumptions were made as part of the System Safety Analysis of the AIM FANS A system :

- the flight crew follows, as a minimum, the procedures listed in Section 5.5 of this document. These crew procedures were used in the System Safety Analysis as detection, protection or barriers to the analysed Failure Conditions. All these procedures are taken into account in the Airbus Industries Flight Crew Operating Manual (FCOM) for FANS A functions. Operators should be encouraged to follow the procedures recommended in this manual to ensure proper operation with AIM FANS A system.

5.3 - PERFORMANCE DEMONSTRATIONS 5.3.1 - Achieved Time Accuracy All messages are timestamped based on UTC time information from GPS with a +/- 2seconds accuracy.

- Uplinks messages are timestamped when they are put in the DCDU queue for display. - Downlink messages are timestamped when the Flight Crew depresses the SEND soft key on the

DCDU.

APPENDIX K


5.3.2 - Achieved Communication Performances Airbus Industries has demonstrated communication performances based on actual flight tests with one simulated ATC ground system, with a representative combination of uplink and downlink and use of VHF and SATCOM. The times from more than 500 messages were used to conduct a statistical analysis. Additionally, Airbus Industries conducted specific flight tests in operational environment connected with operational ATC ground systems. Again, the times from more than 500 messages were used to conduct a statistical analysis. The Communication Performances demonstrated by Airbus Industries in the frame of the AIM FANS A Airworthiness Approval process are the following : - Round-Trip transit time for uplink messages is less than 2 minutes for more than 95% of the

uplink ATC messages This time is the measure between the time an uplink message is sent by the ATC Ground System and the time the Message Assurance (MAS) issued by the avionic system is received by the ATC Ground System.

- One-Way transit time for downlink messages is less than 1 minute for more than 95% of the

downlink messages This time is the measure between the time a downlink message is timestamped by the avionics system and the time this message is received by the ATC Ground System.

These communication performance values were used in the end-to-end Functional Hazard Analysis and subsequent System Safety Analysis conducted by Airbus Industries. Note : these communication performances have been established where appropriate coverage of the

communication media (VHF or Satellite) was available. In particular, satellite datalink communications are based on a constellation of 4 INMARSAT satellites that can provide virtually world-wide coverage between 75°N and 75°S latitudes. Use of satellite datalink communications outside of these latitudes may either not be possible, or may exhibit degraded performances.

5.4 - AIM FANS A Adventitious Characteristics The following are differences between the desired FANS A requirements and the actual implementation. Only differences which have a potentially significant impact on ATC systems/operations are described. For some items there is a requirement placed on ATC to work around the problem; the remaining items are for information only. 5.4.1 - AFN

None 5.4.2 - ADS

1. When an Intermediate Projected Intent group contains default values, the three last bits of the group are set to 1 instead of 0. Note that these bits are padding bits to achieve an integral number of octets. Requirement on ATC : ignore the value of the three last bits of an Intermediate Projected Intent group.

2. Upon receipt of a Cancel Emergency Mode Request containing the contract number of an existing event contract, a Negative Acknowledgement should be sent. Instead, the request is acknowledged and the event contract is cancelled. Note that the emergency mode will be cancelled on that connection. Requirement on ATC : none.

APPENDIX K


APPENDIX K


5.4.3 - CPDLC 1. The BACK ON ROUTE (dM#41) message element cannot be generated. The crew has to send this

information using a free-text (dM#67). Requirement on ATC: none. Crew Procedure : manually send a free-text message with the "BACK ON ROUTE" text when

appropriate.

2. When the optional [legtype] is not included in the uplink HOLD AT [position] MAINTAIN [altitude] INBOUND TRACK [degrees] [direction] TURNS [legtype] (uM#91) message element, the aircraft sends back an error message. Requirement on ATC : insert the optional [legtype] in message element uM#91.

3. Transfer of connection while pending uplink messages exist disconnects both the current and next data authorities. Requirement on ATC : pending uplink messages must be closed before sending END SERVICE.

4. Display of the satellite channel frequency is incorrect. Requirement on ATC : do not send the [Frequencysatchannel] variable.

5. The uplink WHEN CAN YOU ACCEPT [speed] (uM#151) message element with a choice 4 or 5 (speedground or speedgroundmetric) locks CPDLC. Requirement on ATC : do not send a ground speed in message element uM#151.

6. The CLEARED [routeclearance] (uM#80) message element containing more than 82 place-bearing-distance cannot be loaded. Requirement on ATC : do not send more than 82 place-bearing-distance in message element

uM#80.

7. Upon receipt of the [trackdetailmessage] (uM#178) message element, an ERROR [errorinformation] with the [invaliddata] value should be sent. Instead the ERROR message will contain the [insufficientstoragecapacity] value. Requirement on ATC : none.

8. An uplink message containing more than three confirm message elements (uM#132 to uM#147) cannot be processed. Requirement on ATC : do not send an uplink message containing more than three confirm message

elements.

APPENDIX K


5.5 - Input for Flight Crew Procedures The following flight crew procedures are used in the System Safety Analysis as detection, protection or barriers to the Failure Conditions. All these procedures are taken into account in the Airbus Industries Crew Operating Manual (FCOM) for FANS A functions. Operators should be encouraged to follow the procedures recommended in this manual to ensure proper operation with AIM FANS A system. - FP #1 : Initial Notification procedure

The Flight Crew must not initiate a notification procedure with ATC that have no juridiction on their flight (i.e. that are neither current controlling ATC nor next controlling ATC).

- FP #2 : Flight Ident check

The Flight Crew shall check that correct Flight Number and Aircraft Tail Number are entered in the avionics before initiating any Notification Procedure.

- FP #3 : Next controlling ATC check

The Flight Crew shall check that the next controlling ATC designated in the NEXT DATA AUTHORITY CPDLC message is as per their flight plan.

- FP #4 : CPDLC connection check

The Flight Crew shall check that the establishment of the CPDLC connection has been made with the expected ATC centre. If not, this may lead to lost messages.

- FP #7 : PF / PNF mutual information The PF and PNF should inform each other of all the received messages by reading them aloud.

- FP #8 : Positive or Negative answer

The Flight Crew must answer all clearances requesting an answer and in particular, tell the ATC Controller ASAP the clearances they cannot comply with. They may justify (by free text) the reason why they cannot comply with the clearance.

- FP #9 : Display of ATC clearances.

The DCDU is the reference equipment for the display of any ATC message. The Flight Crew shall not rely on the use of the PRINTER for decision making.

- FP #11 : deviation procedure

Except in emergency, before deviating from his assigned flight plan, the Flight Crew must request the deviation from the ATC Controller and receive appropriate clearance. If the aircraft has lost communication, the Flight Crew shall follow the procedure defined in the SPOM Part 5 Chapter 2.2 (Deviation from centreline). If the Flight Crew realizes that the aircraft has deviated from its route (e.g. in case of navigation failure or error), they shall readily inform the ATC Controller.

- FP #17 : Deferred Clearance, ALTITUDE.

For deferred clearance related to altitude, the Flight Crew must report when reaching the assigned altitude.

- FP #18 : Deferred Clearance, HEADING.

For deferred clearance related to heading, the Flight Crew must report when reaching the assigned heading.

- FP #19 : Deferred Clearance, SPEED.

For deferred clearance related to speed, the Flight Crew must report when reaching the assigned speed. - FP #20 : Position comparison

The Flight Crew should compare the CPDLC Position Report with current aircrfat position in FMS before sending.

APPENDIX K


6 - PROPOSED COMPLEMENTARY VERIFICATIONS BEFORE STARTING OPERATIONS This section is proposing a list of verifications that an Operator may consider prior to start operations using data communications in order to ensure correct functioning of the AIM FANS A system. Indeed, most of these checks aim at verifying that the Operator is correctly registered into its selected Communication Service Provider. These checks cannot be performed during the Airworthiness Approval of the avionics package since they depend on each Operator. In addition, this section proposes a list of functional tests that Operators and/or ATS Service Providers may wish to perform before starting operations. All verifications and tests contained in this section are only provided to assist Operators deciding to use datalink communications with AIM FANS A package. 6.1 - Proposed verifications 1. The Operator will ensure that it has the appropriate contract(s) with one or more CSP for the intended

operational environment. 2. Operators may make use of different Communication Service Providers and/or media depending on

the availability of services and their individual contractual arrangements. Operators will ensure that all CSP with whom they have contracts have the appropriate labels configured to support the FANS A messages. Note : as satellite datalink is usually global, an Operator generally needs to contract with only one

CSP for satellite datalink service. VHF datalink facilities, on the other hand, are supported in different regions by different CSPs. This means that Operators may contract with more than one CSP for VHF datalink service. In a given region an Operator may receive VHF datalink service from one CSP and satellite datalink service from another CSP. There are cases where a number of CSPs support VHF datalink service in the same region. Where this occurs, the Operator’s contractual arrangements will determine the choice of VHF CSP by the aircraft.

3. The requirement for a particular medium on a particular route may be specified by the appropriate

States based on factors such as performance and coverage. Such requirement can lead to a need for carriage of specific communication equipment. The Operator will ensure the aircraft configuration comply with such requirement.

6.2 - Proposed tests Some functional tests may be performed with an aircraft on ground and an ATS Provider system to ensure the correct functioning of the AIM FANS A system on the aircraft. The objectives of these tests are :

- Ability to establish, maintain and terminate data link connections via real subnetworks (correct addressing, use of Satcom and VHF data link subnetworks)

- Ability to encode/decode data link messages, - Demonstration of message pairing (i.e., an answer correctly refers to a request, is understood as

such and is operationally meaningful), Following minimum tests are proposed : a. Demonstration of CPDLC exchanges

The objective is to reflect CPDLC operations with one real ATC ground system: establishment and termination of a CPDLC connection, exchange of clearances and reports. Message pairing and usability of data will be checked.

APPENDIX K


b. Demonstration of ADS reporting

The objective is to reflect ADS operations with one real ATC ground system: establishment and termination of an ADS connection, reporting in normal mode and transition to emergency mode. Processing and usability of data will be checked.

c. Robustness to duplicate logons

The objective is to check that duplicate logons do not affect established CPDLC and ADS connections.

If two real ATS Provider systems can participate to the test, the following scenario is also worth testing :

d. Ability to transfer a CPDLC connection In any case, the Operator and the ATS Provider must ensure that:

- Aircraft flight number and tail number (included in the Notification message) will be recognized by the ATS Provider system,

- Network addresses, choice of medium and choice of communication service provider are adequate.

Scenarios for each of the above proposed tests are detailed in Appendix #12 with following terminology:

FN_CON: manual Notification (downlink) FN_AK: Notification Acknowledgement (uplink) CR1: CPDLC Connection Request (uplink) CC1: CPDLC Connection Confirm (downlink, system-generated) NDA: NEXT DATA AUTHORITY ATC name DR1: CPDLC or ADS connection termination (downlink, system-generated).

APPENDIX # 1

Amendments to ARINC 622-2 for AFN application

ATS Facilities Notification (AFN) FANS A complies with ARINC Specification 622-2, Section 3 except as noted below.

ARINC 622 section Description 3.3.3 AFN-Active Flag The ‘Active Flag’ value is not significant. The aircraft will accept FN_CAD messages from any ATS Provider

system. 3.4 Timers / Reason Codes

ATST1 value will be 10 minutes.

3.5.3 AFN Message Header

The optional 24-bit ICAO address will not be provided.

Time stamp will be provided (HHMMSS). flt_no value must be as filed in field 7 of the ICAO flight plan. ‘Flight ID’ defined in ARINC Specification 620

will not be used. Where an Aircraft Registration Number is less than seven characters, the Aircraft Registration Number will be

placed in the right of the field tail_no and the remainder of the field padded out with period [.] characters. 3.5.4 AFN Contact Message

[ap_name] fields will reflect the applications basically available in the aircraft and will not reflect the applications available (i.e. not failed or not off) at the time the AFN Contact Message is initiated.

The optional FCO AIF and version number will not be used. Attachment 2, table 2-1

Version number will be 01 for ADS and CPDLC.

Attachment 2, table 2-1

The Application Name ‘ATC’ is used for CPDLC.

3.5.5 AFN Acknowledge Message

Only the overall reason code in the FN_AK will be used to determine whether the response is positive or not (i.e. the AFN logon is successful or not).

APPENDIX # 2

Amendments to DO 219 MOPS for CPDLC application

Controller Pilot Data Link Communication (CPDLC) FANS A complies with DO-219 except as noted below. DO-219 section Description 2.2.2.1 Connection Initiation

The CPDLC application will interface with: The ACARS Compatible System defined in section 2 of ARINC Specification 622-2, The Application Interface defined in section 4 of ARINC Specification 622-2.

2.2.2.1.1.a.2, 2.2.2.1.2.a.3.i Connection Initiation

Tp4 timer requirements are not applicable.

2.2.2.1.2.a, 2.2.2.1.3.a Connection Initiation

If a valid "Connect Request" (IMI=CR1) is received from a facility designation which is already connected, the CPDLC application will send the “Connect Confirm” (IMI=CC1) containing a message with the [versionnumber] (dM73) message element only. NOTE: This situation happens when the flight crew manually notifies (AFN) an ATS Provider system which has already established a CPDLC connection. Pending messages in the aircraft will not be affected.

2.2.2.2.1.a Connection Termination

If a message is received with an END SERVICE (uM161) message element only and pending uplink messages exist, the CPDLC application will send "Disconnect Request" (IMI=DR1) containing a message with the ERROR [errorinformation] (dM62) message element with the [endServiceWithPendingMsgs] value for the active connection only.

2.2.2.3.b Next ATC Data Authority Retention

If the connection with the next ATC Data Authority has not been established, the next ATC Data Authority facility designation will be retained even after an END SERVICE (uM161) message element has been received. NOTE: This next ATC Data Authority facility designation will be subsequently cleared upon manual Notification (AFN).

2.2.3.3 Message Structure and Content

The Response Attribute of uplink message element #177 will be NE.

Uplink and downlink messages will be paired as detailed in Appendix #3. Position and routeclearance will be processed as detailed in Appendix #4. The uplink message element #178 will be considered to be undefined.

The downlink message element #80 is defined. -- DEVIATING [distanceoffset] [direction] OF ROUTE Resp ( N ) dM80DistanceoffsetDirection [80] DM80DistanceoffsetDirection, The alert attribute for this message is medium. The urgency attribute for this message is normal.


An optional time stamp field is defined in the header of CPDLC messages. ATCmessageheader ::= SEQUENCE { msgidentificationnumber Msgidentificationnumber, msgreferencenumber Msgreferencenumber OPTIONAL, timestamp Timestamp OPTIONAL } Msgidentificationnumber ::= INTEGER (0..63) Msgreferencenumber ::= INTEGER (0..63) Timestamp ::= SEQUENCE { timehours Timehours, timeminutes Timeminutes, timeseconds Timeseconds } Timeseconds ::= INTEGER (0..59) -- Units = 1 Second, Range (0..59) All downlink CPDLC messages will contain a timestamp which indicates the originators send time and should use a time source which is referenced to UTC.


Three optional fields are added to the position report. Positionreport ::= SEQUENCE { positioncurrent [0] Positioncurrent, timeatpositioncurrent [1] Timeatpositioncurrent, altitude [2] Altitude, fixnext [3] Fixnext OPTIONAL, timeetaatfixnext [4] Timeetaatfixnext OPTIONAL, fixnextplusone [5] Fixnextplusone OPTIONAL, timeetadestination [6] Timeetadestination OPTIONAL, remainingfuel [7] Remainingfuel OPTIONAL, temperature [8] Temperature OPTIONAL, winds [9] Winds OPTIONAL, turbulence [10] Turbulence OPTIONAL, icing [11] Icing OPTIONAL, speed [12] Speed OPTIONAL, speedground [13] Speedground OPTIONAL, verticalchange [14] Verticalchange OPTIONAL, trackangle [15] Trackangle OPTIONAL, trueheading [16] Trueheading OPTIONAL, distance [17] Distance OPTIONAL, supplementaryinformation [18] SupplementaryinformationOPTIONAL, reportedwaypointposition [19] Reportedwaypointposition OPTIONAL, reportedwaypointtime [20] Reportedwaypointtime OPTIONAL, reportedwaypointaltitude [21] Reportedwaypointaltitude OPTIONAL } Reportedwaypointposition ::= Position Reportedwaypointtime ::= Time Reportedwaypointaltitude ::= Altitude Reportedwaypointposition. Specifies the previously reported point in the aircraft’s route. Reportedwaypointtime. Specifies the time an aircraft crossed the previously reported point in the route. Reportedwaypointaltitude. Specifies the altitude an aircraft crossed the previously reported point in the route.

2.2.4.1.b Message Identification Number

In cases where the Message Identification Number, time stamp and content are equal to those of a pending message, as per section 2.2.6.4, the aircraft will discard the duplicate message and generate no error message.

2.2.4.1.e Message Identification Number

When only one Message Identification Number is available in the aircraft for subsequent transmission of messages, the CPDLC application will send for all connections the “Disconnect Request” which contains the ERROR [errorinformation] (dM62) message element with the [noAvailableMsgIdentificationNumber] value.

2.2.4.2.a Message Reference Number

If a message is received with a Message Reference Number which does not equal the Message Identification Number of a pending message, as per section 2.2.6.4, and does not contain either the ERROR [errorinformation] (uM159)

message element or SERVICE UNAVAILABLE (uM162) message element, then CPDLC will send a message containing the ERROR [errorinformation] (dM62) message element and discard the received message.

2.2.4.2.a Message Reference Number

If a message is received with a Message Reference Number which does not equal the Message Identification Number of a pending message, as per section 2.2.6.4, and contains either the ERROR [errorinformation] (uM159) message element or SERVICE UNAVAILABLE (uM162) message element, then CPDLC will not send a message containing the ERROR [errorinformation]

2.2.4.2.b Message Reference Number

The CPDLC application will assign a Message Reference Number equal to the Message Identification Number for the associated uplink message for each downlink message initiated for transmission with a WILCO (dM0), UNABLE (dM1), STANDBY (dM2), ROGER (dM3), AFFIRM (dM4), NEGATIVE (dM5), [versionnumber] (dM73) or ERROR [errorinformation] (dM62) (with the exception below) message element. If the message header of the uplink message associated to a downlink ERROR [errorinformation] (dM62) message element does not contain enough bits to constitute a Message Identification Number, then ATCComm will not assign a Message Reference Number for the ERROR [errorinformation] (dM62) message element.

2.2.5.1 Urgency The Urgency Attribute has been implemented according to the existing cockpit philosophy. 2.2.5.2 Alert The Alert Attribute has been implemented according to the existing cockpit philosophy. 2.2.5.3.a.1, 2.2.5.3.a.2 2.2.5.3.a.3 Response

The ERROR [errorinformation] (dM62) and NOT CURRENT DATA AUTHORITY (dM63) message elements are also acceptable responses.

2.2.5.4 Recall The Recall Attribute has been implemented according to the existing cockpit philosophy. 2.2.6.3 Message Display Message Display has been implemented according to the existing cockpit philosophy. 2.2.6.8 Message Errors Error processing is detailed in Appendix #5.

APPENDIX K

236 Flight Operations Support & Line Assistance Getting to grips with FANS – Ref STL 945.7011/03

Appendix #3

CPDLC Uplink/Downlink Message Pairing

The following mapping between uplink report/confirmation requests (uM#) and downlink reports (dM#) applies.

uM#

Message Element dM#

Message Element

127 REPORT BACK ON ROUTE 41 BACK ON ROUTE 128 REPORT LEAVING [altitude] 28 LEAVING [altitude] 129 REPORT LEVEL [altitude] 37 LEVEL [altitude] 130 REPORT PASSING [position] 31 PASSING [position] 131 REPORT REMAING FUEL AND

SOULS ON BOARD 57 [remainingfuel] OF FUEL REMAINING

AND [remainingsouls] SOULS ON BOARD

132 CONFIRM POSITION 33 PRESENT POSITION [position] 133 CONFIRM ALTITUDE 32 PRESENT ALTITUDE [altitude] 134 CONFIRM SPEED 34 PRESENT SPEED [speed] 135 CONFIRM ASSIGNED ALTITUDE 38 ASSIGNED ALTITUDE [altitude] 136 CONFIRM ASSIGNED SPEED 39 ASSIGNED SPEED [speed] 137 CONFIRM ASSIGNED ROUTE 40 ASSIGNED ROUTE [routeclearance] 138 CONFIRM TIME OVER

REPORTED WAYPOINT 46 REPORTED WAYPOINT [time]

139 CONFIRM REPORTED WAYPOINT

45 REPORTED WAYPOINT [position]

140 CONFIRM NEXT WAYPOINT 42 NEXT WAYPOINT [position] 141 CONFIRM NEXT WAYPOINT

ETA 43 NEXT WAYPOINT ETA [time]

142 CONFIRM ENSUING WAYPOINT 44 ENSUING WAYPOINT [position] 144 CONFIRM SQUAWK 47 SQUAWKING [beaconcode] 145 CONFIRM HEADING 35 PRESENT HEADING [degrees] 146 CONFIRM GROUND TRACK 36 PRESENT GROUND TRACK

[degrees] 147 REQUEST POSITION REPORT 48 POSITION REPORT [positionreport] 175 REPORT REACHING [altitude] 72 REACHING [altitude] 180 REPORT REACHING BLOCK

[altitude] TO [altitude] 76 REACHING BLOCK [altitude] TO

[altitude] 181 REPORT DISTANCE [tofrom]

[position] 78 AT [time] [distance] [toFrom] [position]

182 CONFIRM ATIS CODE 79 ATIS [atiscode]

APPENDIX K

Flight Operations Support & Line Assistance 237 Getting to grips with FANS – Ref STL 945.7011/03

Appendix #4

[Position] and [RouteClearance] Variable Processing

Loadable Uplink Message Elements Most CPDLC uplink message elements are merely displayed to the pilot for action. However, some may be loaded into the flight management function of the aircraft. The following table lists those message elements which can be loaded.

uM# Crossing Constraints 51 CROSS [position] AT [time] 52 CROSS [position] AT OR BEFORE [time] 53 CROSS [position] AT OR AFTER [time] Route Modifications 79 CLEARED TO [position] VIA [routeclearance] 80 CLEARED [routeclearance] 83 AT [position] CLEARED [routeclearance]

[position] Variable Loading The following rules for [position] loading apply to standalone [position] variables, as in message element uM77, and to those embedded in the [routeclearance] variable. In the message structure defined in section 4.6.3.3, the [position] variable is defined as a choice of ‘fixname’, ‘navaid’, ‘airport’, ‘latitudeLongitude’, or ‘placebearingdistance’. The first three choices have "overlapping" definitions. [Fixname] is an IA5String (Size(1..5)); [navaid] is an IA5String (Size(1..4)); and [airport] is an IA5String (Size(4)). Consequently, a 1, 2, or 3 character identifier could be encoded as a [fixname] or [navaid], and a four character identifier could be encoded as any of the first three [position] choices. The FMS Navigation Data Base (NDB) is configured to the ARINC 424 specification, which defines the record structure and naming conventions for NDB data. When the FMS receives an uplink message with a loadable message element containing the [position] variable, it uses the [position] choice to determine which of its NDB records to search for a matching identifier. This is required in order for the FMS to be able to load the uplinked [position] into the FMS flight plan. For example, if an uplink message with a [position] choice of 'navaid' is received, the FMS will search only the NDB Navaid record for a matching identifier. Similarly, the ‘airport’ choice leads to a search of the NDB airport record and the ‘fixname’ choice leads to a search of the NDB waypoint record and the NDB non-directional beacon record (explained further below).

APPENDIX K


If a match is not found, then the FMS will not load the specified [position] into the FMS flight plan. Limiting the search in this manner (i.e., as opposed to searching all NDB records, irrespective of the [position] choice) decreases, but does not eliminate, the likelihood of the FMS finding duplicate matching identifiers. The FMS will create a waypoint at the specified [position] when the ‘latitudeLongitude’ choice is selected. If the ‘placebearingdistance’ choice is selected, the [fixname] must match an identifier in the FMS Navigation Database (waypoint, navaid, airport, or non-directional beacon), otherwise, the [fixname] and the corresponding [placebearingdistance] are not loadable. It must be noted that in the case of the FMS finding duplicate matching identifiers, or a FMS Navigation Database unsuccessfull match , a downlink ERROR message element will not be generated. 6.2.1 - [routeclearance] Variable Loading The following table describes how the constituent variables of the [routeclearance] variable will be loaded into the FMS flight plan. NOTE: FMSs have the capability to store two flight plans. The flight plan along which the aircraft is to be flown is called the active flight plan. The "selected route" in which the [routeclearance] variable is loaded is the secondary flight plan.

Table - [routeclearance] Variables

Variable Name Loaded into the

selected route as: Additional information

[airportdeparture] Origin airport for the selected route

The [airportdeparture] variable is not loadable if the [airport] identifier does not match an identifier in the FMS Navigation Database. Otherwise, the [airportdeparture] is loadable.

[airportdestination] Destination airport for the selected route

The [airportdestination] variable is not loadable if the [airport] identifier does not match an identifier in the FMS Navigation Database. Otherwise, the [airportdestination] is loadable.

[runwaydeparture] [runway] [runwaydirection] [runwayconfiguration]

Departure runway direction and configuration for the selected route

The [runwaydeparture] variable is not loadable if the [runway] [runwaydirection] and [runwayconfiguration] do not match a runway identifier for the applicable origin airport in the FMS Navigation Database. Otherwise, the [runwaydeparture] is loadable.

[proceduredeparture] [procedurename] [procedure] [proceduretransition]

Departure procedure and departure transition for the selected route

The [proceduredeparture] is not loadable if the [procedure], or [procedure] and [proceduretransition], do not match a departure procedure identifier, or departure procedure and transition identifiers, for the applicable origin airport in the FMS Navigation Database. Otherwise, the [proceduredeparture] is loadable.

[runwayarrival] [runway] [runwaydirection] [runwayconfiguration]

Arrival runway direction and configuration for the selected route

The [runwayarrival] variable is not loadable if the [runway] [runwaydirection] and [runwayconfiguration] do not match a runway identifier for the applicable destination airport in the FMS Navigation Database. Otherwise, the [runwayarrival] is loadable

[procedureapproach] [procedurename] [procedure] [proceduretransition]

Approach procedure and approach transition for the selected route

The [procedureapproach] is not loadable if the [procedure], or [procedure] and [proceduretransition], do not match an approach procedure identifier, or approach procedure and transition identifiers, for the applicable destination airport in the FMS Navigation Database. Otherwise, the [procedureapproach] is loadable

[procedurearrival] [procedurename] [procedure] [proceduretransition]

Arrival procedure and arrival transition for the selected route

The [procedurearrival] is not loadable if the [procedure], or [procedure] and [proceduretransition], do not match an arrival procedure identifier, or arrival procedure and transition identifiers, for the applicable destination airport in the FMS Navigation Database. Otherwise, the [procedurearrival] is loadable

[airwayintercept] The first airway in the en route portion of the selected route; the FMS automatically selects the point at which the airplane should join the airway.

The [airwayintercept] is not loadable.

Variable Name Loaded into the selected route as:

Additional information

[routeinformation] [publishedidentifier] [latitudelongitude] [placebearingplacebearing] [placebearingdistance] [airwayidentifier] [trackdetail]

En route data for the selected route

The FMS ignores (and does not attempt to load) any [trackdetail] encoded in the [routeinformation] portion of a [routeclearance] variable. Any [publishedidentifier] [fixname], [placebearingdistance] [fixname] or [placebearingplacebearing] [fixname], for which the [fixname] does not match an identifier in the FMS Navigation Database (waypoint, navaid, airport, or non-directional beacon), is not loadable. Any [airwayidentifier] which does not match an airway identifier in the FMS Navigation Database is not loadable. Any [airwayidentifier] for which the point at which the airplane is to join the airway is not defined by a [publishedidentifier] or by another [airwayidentifier] immediately preceding the [airwayidentifier] in the [routeinformation] is not loadable. Any [airwayidentifier] for which the point at which the airplane is to leave the airway is not defined by a [publishedidentifier] or by another [airwayidentifier] immediately following the [airwayidentifier] in the [routeinformation] is not loadable. The ATS Provider system should include the optional [latitudelongitude] with any [publishedidentifier] for which duplicates exist. The FMS attempts to load all other [routeinformation] variables into the selected route in the order in which they occur in the [routeinformation] variable.

[routeinformationadditional] [atwalongtrackwaypoint- sequence] [atwalongtrackwaypoint]

Place-bearing-distance

When the [aTWalongtrackwaypoint] [position], [aTWdistance], and [aTWdistancetolerance] are all loadable (see below), the FMS converts these and then inserts the result into the correct location in the selected route

[routeinformationadditional] [atwalongtrackwaypoint] [position]

If the [position] does not match a loadable [publishedidentifier] or [placebearingdistance] in the uplinked [routeinformation], or does not match a waypoint on an airway defined by an [airwayidentifier] in the uplinked [routeinformation], then the [position] (and the [aTWalongtrackwaypoint]) is not loadable. Otherwise, the [position] is loadable and is used to convert the along track waypoint to a PBD, as stated above.

[routeinformationadditional] [atwalongtrackwaypoint] [aTWdistance] [aTWdistancetolerance] [distance]

ATW that would not fall between the [position] and the preceding or following waypoint are not loadable. The [distance] and [aTWdistancetolerance] are used to convert the along track waypoint to a PBD, as stated above.

[routeinformationadditional] [atwalongtrackwaypoint] [speed]

Speed constraint for the corresponding PBD

[speed] with a speed choice other than choice 0 (speedindicated) or choice 1 (speedindicatedmetric) is not loadable.

Variable Name Loaded into the selected route

as: Additional information

[routeinformationadditional][aTWalongtrackwaypoint- sequence][aTWaltitudesequence] [aTWaltitude] [aTWaltitudetolerance] [altitude]

AT, AT OR ABOVE or AT OR BELOW altitude constraint for the corresponding PBD

Following altitudes are not loadable: [altitude] with an altitude choice other than choice 0 (altitudeqnh), 1 (altitudeqnhmeters), 6 (altitudeflightlevel), or 7 (altitudeflightlevelmetric), [aTWaltitudesequence] with a choice of 2 (altitude window), a single [aTWaltitude] which is at or above the current cruise altitude.

[routeinformationadditional] [reportingpoints] [latlonreportingpoints] latitudereportingpoints] [latitudedirection] [latitudedegrees] [longitudereportingpoints] [longitudedirection] [longitudedegrees] [degreeincrement]

Latitude/longitude waypoint or series of latitude/longitude waypoints

If a latitude defined by a [latitudedirection] and [latitudedegrees], or a longitude defined by a [longitudedirection] and [longitudedegrees], does not intersect the selected route, then the [latlonreportingpoints] is not loadable. If a latitude defined by a [latitudedirection] and [latitudedegrees], or a longitude defined by a [longitudedirection] and [longitudedegrees], does intersect the selected route, then the FMS will insert a latitude/longitude waypoint at the intersection point. If the [degreeincrement] is included, then the FMS will insert reporting points at intervals along the selected route, as defined by the [degreesincrement] along the direction of flight starting at the intersection point.

[routeinformationadditional][interceptcoursefromsequence] [interceptcoursefrom]

NOT USED The FMS ignores (and does not attempt to load) any [interceptcoursefrom] encoded in the [routeinformationadditional]

[routeinformationadditional] [holdatwaypointsequence] [holdatwaypoint]

Hold position and associated data for a given holding pattern in the selected route

[routeinformationadditional] [holdatwaypoint] [position]

Position for a given hold in the selected route

If the [position] does not match a loadable [publishedidentifier],[ latitudelongitude], or [placebearingdistance] in the uplinked [routeinformation], or does not match a waypoint on an airway defined by an [airwayidentifier] in the uplinked [routeinformation], then the [position] (and the [holdatwaypoint]) is not loadable. Otherwise, the [position] is loadable.

[routeinformationadditional] [holdatwaypoint] [holdatwaypointspeedlow]

Speed constraint associated with a given hold in the selected route

The [holdatwaypointspeedlow] variable is not loadable.

[routeinformationadditional] [holdatwaypoint] [aTWaltitude] [aTWaltitudetolerance] [altitude]

AT, AT OR ABOVE or AT OR BELOW altitude constraint associated with a given hold in the selected route

The [aTWaltitude] variable is not loadable.



[routeinformationadditional] [holdatwaypoint] [holdatwaypointspeedhigh]

Speed constraint associated with a given hold in the selected route

The [holdatwaypointspeedhigh] variable is not loadable.

[routeinformationadditional] [holdatwaypoint] [direction]

Turn direction associated with a given hold in the selected route

If the [direction] choice is anything other than choice 0 (left) or 1 (right), then the [direction] is not loadable. Otherwise, the [direction] is loadable.

[routeinformationadditional] [holdatwaypoint] [degrees]

Inbound course associated with a given hold in the selected route

[degrees] is loadable, irrespective of the [degrees] choice

[routeinformationadditional] [holdatwaypoint] [EFCtime]

Expect Further Clearance Time associated with a given hold in the selected route

The [EFCtime] variable is not loadable.

[routeinformationadditional] [holdatwaypoint] [legtype]

Leg Distance, if specified for a given hold in the selected route. Otherwise, Leg Time associated with a given hold in the selected route

The [legdistance] with a choice of 1 (legdistancemetric) is not loadable.

[routeinformationadditional] [waypointspeedaltitude]

Speed, altitude, and associated position for a given waypoint speed and altitude or altitude-only or speed-only constraint in the selected route

For a given [position], the [waypointspeedaltitude] variable should appear only once in the uplinked [routeinformationadditional].

[routeinformationadditional] [waypointspeedaltitude] [position]

Position of a waypoint in the selected route which has a corresponding speed and altitude or altitude-only or speed-only constraint

If the [position] does not match a loadable [publishedidentifier], [latitudelongitude], or [placebearingdistance] in the uplinked [routeinformation], or does not match a waypoint on an airway defined by an [airwayidentifier] in the uplinked [routeinformation], then the [position] (and the [waypointspeedaltitude]) is not loadable. Otherwise, the [position] is loadable.



[routeinformationadditional] [waypointspeedaltitude] [speed]

Speed portion of speed and altitude or speed-only constraint for a waypoint in the selected route

The [speed] variable with a speed choice other than choice 0 (speedindicated) or choice 1 (speedindicatedmetric) is not loadable.

[routeinformationadditional] [waypointspeedaltitude] [ATWaltitudesequence]

AT, AT OR ABOVE, or AT OR BELOW altitude constraint or window altitude constraint for the corresponding [waypointspeedaltitude] [position]

Following altitudes are not loadable: [altitude] with an altitude choice other than choice 0 (altitudeqnh), 1 (altitudeqnhmeters), 6 (altitudeflightlevel), or 7 (altitudeflightlevelmetric), [aTWaltitudesequence] with a choice of 2 (altitude window), a single [aTWaltitude] which is at or above the current cruise altitude.

[RTArequiredtimeofarrival] RTA on the specified position in the selected route

Only one [RTArequiredtimeofarrival] variable is loadable.

[RTArequiredtimeofarrival] [position]

position of a waypoint in the selected route which has an RTA applied to it

If the [position] does not match a loadable [publishedidentifier], [latitudelongitude], or [placebearingdistance] in the uplinked [routeinformation], or does not match a waypoint on an airway defined by an [airwayidentifier] in the uplinked [routeinformation], then the [position] (and the [waypointspeedaltitude]) is not loadable. Otherwise, the [position] is loadable.

[RTArequiredtimeofarrival] [RTAtime]

[RTAtime] for the specified [position]

[RTArequiredtimeofarrival] [RTAtolerance]

[timetolerance] for the specified [position]

The [RTAtolerance] is not loadable.

[routeclearance] Variable Encoding The following table describes how the constituent variables of the [routeclearance] variable will be encoded when an element containing the [routeclearance] variable is sent in a downlink message. The constituent variables of the [routeclearance] variable are all optional. If the data associated with a particular variable do not exist in the "selected route", then no data are encoded for that variable. The "selected route" is the secondary FMS flight plan in constructing a downlink route clearance request or the active flight plan when responding to a CONFIRM ASSIGNED ROUTE message element. Table - [routeclearance] Variable Encoding Table Variable Name Data Source [airportdeparture] Origin airport for the selected route. [airportdestination] Destination airport for the selected route. [runwaydeparture] Departure runway ([runwaydirection] and [runwayconfiguration]) for the selected route. [proceduredeparture] Departure procedure and departure transition for the selected route. [runwayarrival] Arrival runway ([runwaydirection] and [runwayconfiguration]) for the selected route. [procedureapproach] Approach procedure and approach transition for the selected route. [procedurearrival] Arrival procedure and arrival transition for the selected route. [airwayintercept] NOT USED. [routeinformation] En route data for the selected route. All [routeinformation] variables are encoded in the order in which they occur in

the selected route. [routeinformationadditional] [atwalongtrackwaypoint- sequence]

NOT USED - ATWs (Along Track Waypoints) are stored in the FMS and sent in downlinks as PBDs.

[routeinformationadditional] [reportingpoints]

NOT USED.

[routeinformationadditional] [interceptcoursefrom]

NOT USED.

[routeinformationadditional] [holdatwaypoint]

Hold data and associated position for each holding pattern in the selected route.

[routeinformationadditional] [holdatwaypoint] [position]

Position for a given hold in the selected route. If the [position] variable does not match an identifier in the FMS's Navigation Database or is not a Place Bearing Distance, then the [position] is encoded as choice value 3 (latitudelongitude). Otherwise, the [position] is encoded as choice value 0 (fixname), 1 (navaid), 2 (airport), or 4 (placebearingdistance), as appropriate.

[routeinformationadditional] [holdatwaypoint] holdatwaypointspeedlow]

NOT USED.

Variable Name Data Source [routeinformationadditional] [routeinformationadditional] [holdatwaypoint] [holdatwaypointspeedhigh]

NOT USED.

[routeinformationadditional] [holdatwaypoint] [direction]

Turn direction (left or right) associated with a given hold in the selected route.

[routeinformationadditional] [holdatwaypoint][degrees]

Inbound course associated with a given hold in the selected route. When possible, [degrees] are encoded as choice value 1 (degreestrue). Otherwise , [degrees] are encoded as choice value 0 (degreesmagnetic).

[routeinformationadditional] [holdatwaypoint][EFCtime]

NOT USED.

[routeinformationadditional] [holdatwaypoint] [legtype]

Leg Distance, if specified for a given hold in the selected route. Otherwise, Leg Time associated with a given hold in the selected route. If a Leg Distance is specified, then [legdistance] is encoded as choice value 0 (legdistanceenglish).

[routeinformationadditional] [waypointspeedaltitude]

Speed and altitude constraint and associated position for each waypoint speed and altitude constraint in the selected route.

[routeinformationadditional] [waypointspeedaltitude] [position]

Position of a waypoint which has a corresponding altitude or speed or speed and altitude constraint. If the [position] variable does NOT match an identifier in the FMS's Navigation Database or is not a Place Bearing Distance, then the [position] is encoded as choice value 3 (latitudelongitude). Otherwise, the [position] is encoded as choice value 0 (fixname), 1 (navaid), 2 (airport), or 4 (placebearingdistance), as appropriate.

[routeinformationadditional] [waypointspeedaltitude] [speed]

Speed portion of a speed or speed/altitude constraint for a waypoint in the selected route. The [speed] is encoded as choice value 0 (speedindicated).

[routeinformationadditional] [waypointspeedaltitude] [ATWaltitudesequence]

Altitude portion of an altitude or speed/altitude or window altitude constraint associated with a waypoint in the selected route. The [altitude] is encoded as choice value 0 (altitudeqnh) or as choice value 6 (altitudeflightlevel). If a window constraint exists for a given waypoint, then the [ATWaltitudetolerance] for the lower of the two altitudes is encoded as choice value 1 (at or above) and the [ATWaltitudetolerance] for the higher of the two altitudes is encoded as choice value 2 (at or below). (tbc)

[RTArequiredtimeofarrival] RTA data for a position in the selected route. FMS can only have one at a time. [RTArequiredtimeofarrival] [position]

Position of a waypoint which has a defined RTA. If the [position] variable does NOT match an identifier in the FMS's Navigation Database or is not a Place Bearing Distance, then the [position] is encoded as choice value 3 (latitudelongitude). Otherwise, the [position] is encoded as choice value 0 (fixname), 1 (navaid), 2 (airport), or 4 (placebearingdistance), as appropriate.

APPENDIX K


Appendix #5

CPDLC Error Processing

The following lists the conditions under which the CPDLC application will transmit an error message. These conditions are listed by the error code that will be transmitted in the downlink ERROR [errorinformation] message element. Imbedded Message Identifiers (IMI) of the ERROR [errorinformation] message element are detailed. 0. applicationError The CPDLC application receives an uplink message (IMI=AT1) with one of the following combinations: message element 160 (NEXT DATA AUTHORITY [icaofacilitydesignation]) and any other message element, message element 159 (ERROR [errorinformation]) and any other message element, message element 162 (SERVICE UNAVAILABLE) and any other message element. 1. duplicateMsgIdentificationNumber The CPDLC application receives an uplink message (IMI=AT1) with an MIN equal the MIN of a previous uplink which is still pending. 2. unrecognizedMsgReferenceNumber The CPDLC application receives an uplink message (IMI=AT1) with an MRN and there is no pending downlink message with a matching MIN. (Downlink IMI=AT1). The CPDLC application receives an uplink with IMI=CR1 and the uplink includes an MRN. (Downlink IMI=DR1). 3. endServiceWithPendingMsgs The CPDLC application receives an uplink message (IMI=AT1) containing element 161 and no other element and there are pending uplink messages, (downlink IMI=DR1), or The CPDLC application receives an uplink message (IMI=AT1) containing element 161 plus another element requiring WILCO/UNABLE response and there are pending uplink messages and the pilot sends WILCO. (Downlink IMI=DR1). 4. endServiceWithNoValidResponse The CPDLC application receives an uplink message (IMI=AT1) containing element 161 and another element requiring no response or a response other than WILCO/UNABLE. (Downlink IMI=DR1). 5. insufficientMsgStorageCapacity The CPDLC application receives an uplink message (IMI=AT1) when the message storage or processing capacity is full. (Downlink IMI=AT1). 6. noAvailableMsgIdentificationNumber The CPDLC application has only one MIN available that is not being used for a pending downlink message (or a downlink message not acknoweldged by the network) (Downlink IMI=DR1) 7. commandedTermination The pilot disconnects the CPDLC application or changes the entered flight number. (Downlink IMI=DR1). 8. insufficientData The CPDLC application receives an uplink message (IMI=CR1 or AT1) containing no message element. (If the uplink IMI=CR1, the downlink IMI=DR1. If the uplink IMI=AT1, the downlink IMI=AT1). 9. unexpectedData The CPDLC application receives an uplink message during a CPDLC inhibition phase.

APPENDIX K


10. invalidData The CPDLC application receives an uplink with IMI=CR1 and either datum in element 163 is invalid. (Downlink IMI=DR1). The CPDLC application receives an uplink message (IMI=AT1) with element 178 or 183-255, (downlink IMI=AT1), or The CPDLC application receives an uplink message (IMI=AT1) with a variable outside its valid range. (Downlink IMI=AT1). The CPDLC application receives an uplink message (IMI=AT1) containing an IA5String (e.g. element 169 [freetext]) and the string contains a character which the DCDU can not display. (Downlink IMI=AT1). The CPDLC application receives an uplink message (IMI=CR1 or AT1) without enough bits to define the header and one valid element, (If the uplink IMI=CR1, the downlink IMI=DR1. If the uplink IMI=AT1, the downlink IMI=AT1). or The CPDLC application receives an uplink message (IMI=AT1) without enough bits to define all variables required for each element, (downlink IMI=AT1), or The CPDLC application receives an uplink message (IMI=AT1) containing an IA5String and the string contains fewer characters than specified, (downlink IMI=AT1), or The CPDLC application receives an uplink (IMI=AT1) with more than 5 message elements. (Downlink IMI=AT1). The CPDLC application receives an uplink message (IMI=AT1) with more pad bits than required to make a full octet, (downlink IMI=AT1), or The CPDLC application receives an uplink message (IMI=AT1) containing an IA5String and the string contains more characters than specified, (downlink IMI=AT1), or The CPDLC application receives an uplink message with IMI=CR1 and an element other than 163, (downlink IMI=DR1), or The CPDLC application receives an uplink message with IMI=CR1 and element 163 plus any other element. (Downlink IMI=DR1). 11. reservedErrorMsg Not Used

Appendix 6

Deviation to DO-212 for ADS application

FANS A complies with DO-212, except as noted below.

DO-212 section Description 2.2.1.1 Application Interface 2.2.1.3.2 Context Management Interface

The ADS application will interface with: The ACARS Compatible System defined in section 2 of ARINC Specification 622-2, The Application Interface defined in section 4 of ARINC Specification 622-2.

2.2.1.1.1.2.a Connection Denial

Not applicable.

2.2.1.2.d Processing of Uplinks

Any downlinking of an Acknowledgement message or a Non-Compliance Notification message will reset the counter of consecutive Non-Acknowledgement messages.

2.2.1.2.1.d Periodic Contract Request

The ADS application will support a periodic reporting interval of 64 seconds on any or all connections. If a periodic reporting interval which is less than 64 seconds is requested, the ADS application will respond with a Non-compliance Notification and will establish a periodic contract with a 64-second reporting period.

2.2.1.2.1.g Periodic Contract Request

The contract number will be modified based upon the new contract number.

2.2.1.2.5.a Cancel emergency Mode Request

When an emergency periodic contract exists and the ADS application receives a Cancel Emergency Mode Request, the ADS application will perform the following in the listed order: cancel the emergency periodic contract, send immediately an Acknowledgement message to the Cancel Emergency Mode Request, establish a normal periodic contract with the same reporting rate and the same on-request groups as existed before the emergency mode was canceled, send the first normal periodic report with respect to the period.

2.2.1.2.5 Cancel emergency Mode Request

When the ADS application receives a Cancel Emergency Mode Request with a contract number that matches the contract request number of an active emergency periodic contract on that connection, a Negative Acknowledgement with a negative acknowledgement reason of 6 will be sent (i.e., the contract number in a Cancel Emergency Mode Request cannot be the same as the contract number of an existing contract on that connection).

2.2.1.3.1 Flight Crew Interfaces

The flight crew will have the means to initiate/terminate the ADS application's emergency mode and to terminate all ADS connections.

2.2.1.3.1.1.a Create Emergency Mode Indication

When a normal periodic contract exists before the creation of emergency mode, its reporting rate will be retained and applied to the default emergency periodic contract. When a default emergency periodic contract is created, the first emergency periodic report will be sent immediately.

2.2.1.3.1.1.c Create Emergency Mode Indication

If a new connection is established while the ADS application is in emergency mode, then an event contract request during connection establishment will result in an event contract only. The connection will be in emergency mode and no default emergency periodic contract will be established. If a new connection is established while the ADS application is in emergency mode, then a normal demand contract request during connection establishment will result in a Negative Acknowledgement with a negative acknowledgement reason of 4.

DO-212 section Description Figure 2-11 Airframe Identification Group will not be provided in ADS reports. Figure 2-13 ATC mandatory and non-mandatory waypoints (e.g., inserted by the pilot) will be reported in the Predicted Route Group.

When the Predicted Route Group is required, the ETA field will contain the estimated time to go (ETG) from aircraft position to the next waypoint.

Figure 2-14 In the True Track field definition, the validity and the sign bits are in reverse order. ATC mandatory and non-mandatory waypoints (e.g., inserted by the pilot) and computed vertical profile points will be reported in the Intermediate Projected Intent Group. A maximum of 10 Intermediate Projected Intent points will be provided.

Figure 2-15 The fixed projected point is the predicted aircraft location along the flight plan at the end of the requested time interval. If the predicted aircraft location at the requested time is beyond the end of route, then the last waypoint of the route will be reported as the fixed projected point.

Table 2-4 The unit for altitude is feet. The valid range for Distance is 0-8191.750 nm. The default value is 8191.875 nm. The valid range for ETA and Projected Time is 16382 seconds. The default value is 16383 seconds.

2.2.1.4.i Message Generation

If Aircraft Intent Groups are requested in a valid Demand Contract Request, then the ADS application will send the initial response within 60 seconds of receipt of the contract request.

2.2.1.4.l Message Generation

The ADS application will send the initial response within 5 seconds of receipt of a contract request (except as noted above). The ADS application will send subsequent periodic reports within 5 seconds of detecting the expiry of the reporting interval. The ADS application will send event reports within 5 seconds of detecting the event occurrence.

2.2.1.4.3.d Non-Compliance Notification

This applies when the requested reporting rate is less than 64 seconds.

2.2.1.5.a Abnormal Connection Termination

When the ADS application receives a disconnect indication, all connections will be canceled.

APPENDIX #7 Amendments to ARINC 622-2 Section 4 for Application Interface

FANS A complies with ARINC Specification 622-2, Section 4 except as noted below.

ARINC 622 section Description 4.5 CMA Provisions Not applicable. 4.6 FIS Provisions Not applicable. 4.1 ACARS- Application Interface

Application name AIF and Version number of this application will not be used.

4.4 ATCComm Provisions

ATCComm is also known as CPDLC.

APPENDIX #8 AMENDMENTS TO A622 ACARS Convergence Function for ATS Ground Systems

ARINC 622 section Description 2.0 ACARS Compatible System

ATS Provider systems are required to support both avionics architectures (ATS applications in ACARS management function unit or in ACARS management function peripheral) if they intend to support the aircraft types covered in this document. This implies that both routings of ATS messages will be available in ATS Providers systems.

2.2.3 ACARS Compatible System CRC

In the event that the appended CRC does not match the calculated CRC, the message shall be discarded.

Attachment 2, table 2-1 For ADS, only the following IMI shall be used: ADS. Attachment 2, table 2-1 For CPDLC, only the following IMIs shall be used: AT1, CR1, and DR1.

APPENDIX #9 AMENDMENTS TO A622 AFN Application for ATS Ground Systems

ARINC 622 section Description 3.3.2 Request for Notification

The active ATS Provider system (i.e., the current ATC Data Authority) shall be able to forward AFN logon information.

3.4 Timers / Reason Codes

ATST3 value shall be greater than ATST1 value. NOTE: ATS Provider systems should use 15 minutes for ATST3.

3.5.3 AFN Message Header

Where an Aircraft Registration Number is less than seven characters, the Aircraft Registration Number shall be placed in the right of the field tail_no and the remainder of the field padded out with period [.] characters.

Attachment 2, table 2-1 Version number shall be 01 for ADS and CPDLC.

APPENDIX #10

AMENDMENTS TO DO-219 CPDLC Application for ATS Ground Systems

DO-219 section

Description

2.2.1 The CPDLC application shall interface with: The ACARS Compatible System defined in section 2 of ARINC Specification 622-2, The Application Interface defined in section 4 of ARINC Specification 622-2.

2.2.2 A CPDLC application built to the functional capability described here shall be version number 01. 2.2.2.1 The ATS Provider System shall initiate connections with aircraft by sending the “Connect Request” (IMI=CR1) containing a message

with the [icaofacilitydesignation][tp4table] (uM163) message element only. 2.2.2.1.1.c If no connections are established or in the process of being established, upon receipt of any message, the ATS Provider system shall

ignore that message. 2.2.2.1.2.c If a "Connect Request" (IMI=CR1) is pending, upon receipt of a message other than the corresponding "Connect Confirm" (IMI=CC1),

the ATS Provider system shall ignore that message. 2.2.3.3.a CPDLC message structure and content shall conform to the abstract syntax in this section. 2.2.3.4.a CPDLC shall use ISO/IEC 8825-2:1996 Packed Encoding Rules (PER) – Basic Unaligned, to encode/decode the ASN.1 message

structure and content specified in section 2.2.3.3 or a functionally equivalent means which provides the same result. 2.2.3.4.b Encoded messages shall be padded with bits set to the zero value at the end of the message to achieve an integral number of octets. 2.2.4 If a message is received and there are not enough bits to constitute a header, CPDLC shall send a message with the ERROR

[errorinformation] (uM159) message element and discard the received message. 2.2.4.1.b If the received downlink message has a “Y” Response type, the ATS Provider system shall use the Message Identification Number for

that received message as the Message Reference Number for the message containing the response message element(s). 2.2.4.1.c If a message is received containing a Message Identification Number equal to that of a pending message, as specified in section

2.2.6.4, CPDLC shall send a message containing the ERROR [errorinformation] (uM159) message element with the [duplicateMsgIdentificationNumber] value and discard the received message

2.2.4.1.d On a given connection, CDPLC shall assign a Message Identification Number for each message initiated for transmission. 2.2.4.1.e Each assigned Message Identification Number shall be unique from any Message Identification Number for a pending message, as per

section 2.2.6.4.

2.2.4.1.g If a pending message, as per section 2.2.6.4, has been deleted, CPDLC shall not allow the Message Identification Number for that message to be made available for re-use except as specified in paragraph 2.2.6.4.c.

2.2.4.2.a If a message is received with a Message Reference Number which does not equal the Message Identification Number of a pending

message, as per section 2.2.6.4, and does not contain either the ERROR [errorinformation] (uM159) message element or SERVICE UNAVAILABLE (uM162) message element, then CPDLC shall send a message containing the ERROR [errorinformation] (uM159) message element and discard the received message.

DO-219 section

Description

2.2.4.2.b If a message is received with a Message Reference Number which does not equal the Message Identification Number of a pending message, as per section 2.2.6.4, and contains either the ERROR [errorinformation] (uM159) message element or SERVICE UNAVAILABLE (uM162) message element, then CPDLC shall not send a message containing the ERROR [errorinformation].

2.2.4.2.e If a message is received by an ATS Provider system with a Message Reference Number which does not equal the Message Identification Number of a pending uplink message in the ATS Provider system, then the message shall be discarded.

2.2.4.2.f On a given connection, the ATS Provider system shall assign a Message Reference Number equal to the Message Identification Number for the associated downlink message for each uplink message sent with an UNABLE (uM0), STANDBY (uM1), REQUEST DEFERRED (uM2), ROGER (uM3), AFFIRM (uM4), NEGATIVE (uM5), ERROR [errorinformation] (uM159), or SERVICE UNAVAILABLE (uM162) message element, or any other uplink message transmitted in response to a downlink message element with a “Y” response attribute.

2.2.4.2.g The [versionnumber] (dM73) message element sent with the “Connect Confirm” (IMI=CC1) shall contain a Message Reference Number corresponding to the associated Message Identification Number of the [ICAOfacilitydesignation][tp4table] (uM163) message element sent with the“Connect Request” (IMI=CR1).

2.2.5 For a given message, Urgency, Alert, Response, and Recall types will be assigned for each message element as specified in section 2.2.3.3. For a message containing multiple message elements, the message element type with the highest precedence shall be assigned for each attribute for that message, as determined from Table 2-4 through Table 2-8 from Section 2.2.3.1.

2.2.5.3.b Only one closure response shall be allowed for a given message. 2.2.5.3.c When an unacceptable closure response to an uplink message is received by the ATS Provider system (e.g. ROGER in response to a

message with a W/U Response type), the ATS Provider system shall discard the message. 2.2.6 If a message is received and insufficient storage exists to handle the message, CPDLC shall send a message containing the ERROR

[errorinformation] (uM159) message element with the [insufficientMsgStorageCapacity] value and discard the received message. 2.2.6.1.a If a message is received and any message element number is not represented in section 2.2.3.3, CPDLC shall send a message with

the ERROR [errorinformation] (uM159) message element with the [invalidData] value and discard the received message. 2.2.6.1.b If a message is received and there are more than 5 message elements, CPDLC shall send a message with the ERROR

[errorinformation] (uM159) message element and discard the received message. 2.2.6.1.c CPDLC shall not permit a message with missing mandatory data to be transmitted.

2.2.6.1.d If a message is received and there are message elements containing an IA5 string character not supported, CPDLC shall send a message with the ERROR [errorinformation] (uM159) message element and discard the received message.

2.2.6.2 If a message is received and any message Data Type is not as represented in section 2.2.3.3, CPDLC shall send a message with the ERROR [errorinformation] (uM159) message element with the [invalidData] value and discard the received message.

2.2.6.4.a A message shall be retained by CPDLC as a pending uplink message until at least one of the following conditions have been met: 1.The message has a "W/U", "A/N", or "R" Response type and a message which contains a closure response as indicated in section 2.2.5.3.a with a Message Reference Number equal to the Message Identification Number for the uplink message has been sent by aircraft or received by the ATS Provider system. 2. This connection has been terminated.

DO-219 section

Description

2.2.6.4.c If a downlink message has a "Y" Response type, that message shall be retained by CDPLC as a pending downlink message until at least one of the following conditions have been met: 1. A message with a Message Reference Number equal to the Message Identification Number for the downlink message has been sent by the ATS Provider system or received by aircraft, and that the received message did not have a STANDBY or REQUEST DEFERRED message element. 2. This connection has been terminated.

2.2.6.8 When a message error is detected, CPDLC shall send a response message containing the ERROR [errorinformation] (uM159) message element with the value selected in accordance with the specific requirements of section 2.2.

2.2.2.1 After successful completion of the AFN logon, the ATS Provider system shall send a CPDLC Connect Request (IMI = CR1 and contains message element uM163 [ICAO facility designation]) to the aircraft.

2.2.2.2 If address forwarding is carried out using ground-ground communications networks or by the AFN Address Forwarding, the CPDLC NEXT DATA AUTHORITY [icaofacilitydesignation] (uM160) message element shall be sent by the active ATS Provider system before forwarding the AFN logon information to the next ATS Provider system.

The [position] variable does not allow a position to be defined as a latitude or longitude only. To overcome this limitation some ATS Providers define a latitude or longitude using the ‘fixname’ choice. For example CROSS 140W AT FL330 or AT 5S CLIMB TO AND MAINTAIN FL310, with 140W and 5S being defined as ‘fixname’. However, if minutes of latitude or longitude are used, e.g., CROSS 4030N AT FL330, this may correspond to an actual fix as defined by the ARINC 424 specification in the aircraft Nvigation Data Base. It should be noted that this fix could be geographically different from the intended position in the ATS Provider instruction. This situation should be avoided.

In order to assure that the data are loaded correctly, the following constituent variables of the [routeclearance] variable should not be used with elements uM79 and uM83: airportdeparture, proceduredeparture, procedureapproach, procedurearrival, and airwayintercept.

APPENDIX #11

AMENDMENTS TO DO-212 ADS Application for ATS Ground Systems

DO-212 section Description 2.2.1 ADSF Operation When the ATS Provider system requests a capability not supported by an aircraft, the aircraft shall recognize that fact, and the

Non-compliance Notification message shall inform the ATS Provider system that this capability is not supported. 2.2.1.1 Application Interface

The ATS Provider system shall interface with: The ACARS Compatible System defined in section 2 of ARINC Specification 622-2, The Application Interface defined in section 4 of ARINC Specification 622-2.

2.2.1.1.1 Connection An ADS application built to the functional capability described here shall be version number 01 To establish an ADS connection, the ATS Provider system shall send an ADS contract request (IMI = ADS and containing one

or more contract request messages as defined in section 2.2.1.2). 2.2.1.2.b Processing of Uplinks

The first octet of an ADS request shall define the type of request being made. Valid requests shall be: Cancel All Contracts and Terminate Connection (tag value 1, see subparagraph 2.2.1.2.4); Cancel Contract (tag value 2, see subparagraph 2.2.1.2.3); Cancel Emergency Mode (tag value 6, see subparagraph 2.2.1.2.5); Periodic Contract (including Demand Contract) (tag value 7, see subparagraph 2.2.1.2.1); Event Contract (tag value 8, see subparagraph 2.2.1.2.2); and Emergency Periodic Contract (tag value 9, see subparagraph 2.2.1.2.1). When a valid request tag is encountered, the aircraft shall interpret the data as defined in the referenced section and operate as defined in subparagraph 2.2.1.4.

2.2.1.2.e.2 Processing of Uplinks

If the aircraft cannot comply with a particular Event Contract Request, and no other events were requested with the contract request, then the ATS Provider system and the aircraft shall both transition to a state as if the contract request were fulfilled.

2.2.1.2.1.a Periodic Contract Request

The Periodic Contract Request shall be interpreted as a mandatory request tag octet and a mandatory contract request number octet followed by optional groups of data. The optional groups of data shall be: reporting rate tag octet followed by the reporting rate octet; on-request group tag octet followed by the on-request group modulus octet followed by zero or more octets of parameter data, as required. These optional groups of data may appear in any order following the contract request number.

2.2.1.2.1.b.1 Periodic Contract Request

The reporting rate, or interval, octet shall define how often the Basic ADS Group is sent.

2.2.1.2.1.b.3 Periodic Contract Request

The format of the reporting rate octet shall be defined as follows. Bits 6 through 1 shall define the rate, in binary format. Bits 8 and 7 shall define the Scaling Factor (SF) to be used when computing the reporting interval, using the following table:

2.2.1.2.1.c Periodic Contract Request

The following algorithm shall be used to determine the reporting interval:

2.2.1.2.2.a Event Contract Request

The Event Contract Request shall be interpreted as a mandatory request tag octet and a mandatory contract request number octet followed by optional groups of data. These optional groups of data shall be: vertical rate change tag octet followed by vertical rate change threshold octet; waypoint change tag octet; lateral deviation change tag octet followed by the lateral deviation change threshold octet; and altitude range tag octet followed by the ceiling and floor altitude data, each two octets in length.

2.2.1.2.2.b.1 Event Contract Request

The optional data shall define the event that is used to generate an event report.

2.2.1.2.4 Cancel All Contracts and Terminate Connection

Under normal operations, the ADS connection shall be terminated by the ATS Provider system sending the Cancel All Contracts And Terminate Connection request.

2.2.1.4.a.3 Message Generation

The ADS-report tag contained in the Basic ADS Group shall define the type of report generated : emergency periodic (including demand), normal periodic (including demand) or event.

2.2.1.4.b.7 Message Generation

The time stamp shall be expressed as the time elapsed since the most recent hour. Time shall be rounded, not truncated, to accurately yield the value loaded into the time stamp field.

2.2.1.4.d.1 Message Generation

When the Aircraft Intent Group is required, its content shall be determined as follows. The fixed projected point shall be determined by the predicted location of the aircraft in X minutes, where X is the aircraft intent projection time contained in the Periodic Contract Request. Intermediate projected intent points shall be any points between the aircraft's present position and the fixed projected point where an altitude, track or speed change is predicted to occur.

2.2.1.4.f Message Generation

The report generated for a vertical rate event shall contain the Earth Reference Group.

2.2.1.4.g Message Generation

The report generated for a waypoint change event shall contain the Predicted Route Group.

2.2.1.4.1 Acknowledgement Message

The ADS contract request number contained in the Acknowledgement message shall correspond to the ADS contract request number being acknowledged.

2.2.1.4.2.a Negative Acknowledgement

The ADS contract request number contained in the Negative Acknowledgement message shall correspond to the ADS contract request number being negatively acknowledged. The Negative Acknowledgement reasons shall be as defined in Table 4.5-6. The extended data octet shall only be used with Negative Acknowledgement reasons 1, 2 and 7, and shall contain the data defined in Table 4.5-6. The extended data octet shall not be sent for other Negative Acknowledgement reasons.

2.2.1.4.2.b Negative Acknowledgement

For Negative Acknowledgement reason 7, the first octet of the request will have contained a number not defined for uplink requests. The second octet of the request shall be assumed to be the ADS contract request number (returned in the second octet of the Negative Acknowledgement).

2.2.1.4.3.a Non-Compliance Notification Message

The Non-compliance Notification message shall consist of the following mandatory five octets: non-compliance notification tag, ADS contract request number that cannot be complied with, the number of on-request groups and events that cannot be complied with, the tag of the first on-request group or event that cannot be complied with, and a fifth octet containing coded data.

2.2.1.4.3.b.1 Non-Compliance Notification Message

The most significant bit (bit 8) of the fifth octet shall define whether the on-request group is undefined or unavailable. A one shall indicate undefined, a zero shall indicate unavailable.

2.2.1.4.3.b.3 Non-Compliance Notification Message

If unavailable, the next bit (bit 7) shall define whether the entire on-request group or event is unavailable. A one shall indicate that the entire on-request group or event is unavailable, and the remainder of the octet shall not be used. A zero shall indicate that one or more parameters of an on-request group are not available. Bits 6 and 5 are reserved. The remaining four bits in the fifth octet shall contain the number of parameters that are not available.

2.2.1.4.3.c Non-Compliance Notification Message

If parameters are not available, as many parameter octets as needed shall follow the fifth octet, to define the unavailable parameters. Each parameter octet that follows shall be divided in half, each half shall contain a parameter number. This parameter number shall be in reference to the location of the parameter in the on-request group. If an odd number of parameters is unavailable, the last four bits of the last parameter octet shall be all zeros.

2.2.1.4.3.d Non-Compliance Notification Message

When the aircraft uses the Non-compliance Notification message to indicate that it is not going to support a reporting interval of less than the minimum reporting interval, the reporting rate tag shall be contained in octet four, the first bit of octet five shall be set to zero, and the second bit of octet five shall be set to one. The remaining bits of octet five shall not be used.

APPENDIX K


Appendix #12

Scenario and message sequence chart for proposed tests

1. Demonstration of CPDLC exchanges This scenario is supposed to reflect real CPDLC operations with one ATS Provider system. Notification, establishment of a CPDLC connection, several exchanges of messages (or combination of messages) and ground-initiated termination of the connection will be executed. As a minimum, altitude clearances and position reports must be exchanged. Message pairing (appropriate and meaningful answers) and state of messages (open or not) will be observed.

aircraft ATC

FN_CON

FN_AK

CR1

CC1

Exchange of CPDLCmessages

END SERVICE

DR1

APPENDIX K


2. Demonstration of ADS reporting This scenario intends to reflect real ADS operations with one ATS Provider system. Periodic, event and demand contracts will be established in normal mode. Then emergency mode will be created. Reporting intervals, on-request groups and events will be adapted to test means. As a minimum, a periodic contract requesting Predicted Route group and an event contract including Waypoint Change should be established. Note: except the Notification (FN_CON), all exchanges will be transparent to the crew. Results will be visible at the ATS Provider system level.

aircraft ATCFN_CON

FN_AK

1st ADS Contract Request

Acknowledgement+Report

Creation ofemergency mode

ADS reporting

ADS normalmode

ADS emergencymode

ADS reporting

Cancellation ofemergency mode

ADS reporting

Contract All Contracts andTerminate Connection

Request

ADS normalmode

APPENDIX K


3. Robustness to duplicate logons In this scenario, a CPDLC connection is established with the ATS Provider system. Then the crew sends a Notification to this ATS Provider system. From the crew perspective, the CPDLC connection should not be affected. To complement this scenario, an uplink clearance (e.g., CLIMB TO altitude) can be sent but not responded by the crew before the second Notification attempt. Similarly a downlink clearance request (e.g., REQUEST speed) can be sent but not responded by the ATC controller before the second Notification attempt. The respective answers must be sent after the second Notification. From the crew perspective, the processing of messages should not be affected.

aircraft ATC

FN_CON

FN_AK

CR1

CC1

CPDLC connectionestablished

FN_AK

CR1

CC1

FN_CON

aircraft ATC

FN_CON

FN_AK

CR1

CC1

CPDLC connectionestablished

FN_AK

CR1

CC1

FN_CON

APPENDIX K


4. Transfer of CPDLC connection This scenario requires two ATS Provider systems and they must be able to transfer a CPDLC connection from one to the other. This ability must be checked and may require coordination with the appropriate ATS Provider staff. In this scenario, a CPDLC connection is established with an ATS Provider system (ATC 1). The whole sequence of transfer from ATC 1 to ATC 2 is initiated by ATC 1. The level of automation will depend on the test means. The crew will verify on cockpit displays that the controlling ATS Provider system has become ATC 2. Note: FN_CAD, FN_RESP and FN_COMP are system-generated downlinks. In this specific scenario, FN_CON will also be system-generated. These messages will therefore be transparent to the crew.

ATC 1 aircraft ATC 2

NDA

FN_CAD

FN_CON

FN_AK

FN_RESP

FN_COMP CR1

CC1MONITOR + END SERVICE

WILCO

DR1

APPENDIX K



AIRBUS SAS All right reserved

The statement herein do not constitute an offer. They are based on the assumptions shown and are expressed in good faith. Where the supporting grounds for these statements are not shown the Company will be pleased to explain the basis thereof.

Customer Services 31707 Blagnac Cedex France

Telephone +33 (0) 5 61 93 33 33 Ref. STL 945.7011/03

Printed in France

Documents

Getting to Grips With FANS