Controller–pilot data link communications

From Wikipedia, the free encyclopedia
Jump to: navigation, search

Controller–pilot data link communications (CPDLC), also referred to as controller pilot data link (CPDL), is a method by which air traffic controllers can communicate with pilots over a datalink system.

Necessity[edit]

The standard method of communication between an air traffic controller and a pilot is voice radio, using either VHF bands for line-of-sight communication or HF bands for long-distance communication (such as that provided by Shanwick Oceanic Control).

One of the major problems with voice radio communications used in this manner is that all pilots being handled by a particular controller are tuned to the same frequency. As the number of flights air traffic controllers must handle is steadily increasing (for instance, Shanwick handled 414,570 flights in 2007, an increase of 5% - or 22,000 flights - from 2006[1]), the number of pilots tuned to a particular station also increases. This increases the chances that one pilot will accidentally override another, thus requiring the transmission to be repeated. In addition, each exchange between a controller and pilot requires a certain amount of time to complete; eventually, as the number of flights being controlled reaches a saturation point, the controller will not be able to handle any further aircraft.

Traditionally, this problem has been countered by dividing a saturated air traffic control sector into two smaller sectors, each with its own controller and each using a different voice communications channel. However, this strategy suffers from two problems:

  • Each sector division increases the amount of "handover traffic". That is the overhead involved in transferring a flight between sectors, which requires a voice exchange between the pilot and both controllers, plus co-ordination between the controllers.
  • The number of available voice channels is finite, and, in high density airspace, such as central Europe or the Eastern US Seaboard, there may not be a new channel available.

In some cases it may not be possible or feasible to further divide down a section.

A new strategy is needed to cope with increased demands on air traffic control, and data link based communications offers a possible strategy by increasing the effective capacity of the communications channel.

Use of CPDLC[edit]

The datalink control and display unit (DCDU) on an Airbus A330, the pilot interface for sending and receiving CPDLC messages.

Controller–pilot data link communication (CPDLC) is a means of communication between controller and pilot, using data link for ATC communication. At the highest level, the concept is simple, with the emphasis on the continued involvement of the human at either end and the flexibility of use.

The CPDLC application provides air-ground data communication for the ATC service. This includes a set of clearance/information/request message elements which correspond to voice phraseology employed by air traffic control procedures. The controller is provided with the capability to issue level assignments, crossing constraints, lateral deviations, route changes and clearances, speed assignments, radio frequency assignments, and various requests for information. The pilot is provided with the capability to respond to messages, to request clearances and information, to report information, and to declare/rescind an emergency. The pilot is, in addition, provided with the capability to request conditional clearances (downstream) and information from a downstream air traffic service unit (ATSU). A “free text” capability is also provided to exchange information not conforming to defined formats. An auxiliary capability is provided to allow a ground system to use data link to forward a CPDLC message to another ground system.

The sequence of messages between the controller at an ATSU and a pilot relating to a particular transaction (for example request and receipt of a clearance) is termed a ‘dialogue’. There can be several sequences of messages in the dialogue, each of which is closed by means of appropriate messages, usually of acknowledgement or acceptance. Closure of the dialogue does not necessarily terminate the link, since there can be several dialogues between controller and pilot while an aircraft transits the ATSU airspace.

All exchanges of CPDLC messages between pilot and controller can be viewed as dialogues.

The CPDLC application has three primary functions:

  • the exchange of controller/pilot messages with the current data authority,
  • the transfer of data authority involving current and next data authority, and
  • downstream clearance delivery with a downstream data authority.

Simulations carried out at the Federal Aviation Administration's William J. Hughes Technical Center have shown that the use of CPDLC meant that "the voice channel occupancy was decreased by 75 percent during realistic operations in busy en route airspace. The net result of this decrease in voice channel occupancy is increased flight safety and efficiency through more effective communications."[2]

Implementation[edit]

Today, there are two main implementations of CPDLC:

  • The FANS-1/A system that was originally developed by Boeing, and later adopted by Airbus, is primarily used in oceanic routes by widebodied long haul aircraft. It was originally deployed in the South Pacific in the late 1990s and was later extended to the North Atlantic. FANS-1/A is an ACARS based service and, given its oceanic use, mainly uses satellite communications provided by the Inmarsat Data-2 (Classic Aero) service.
  • The ICAO Doc 9705 compliant ATN/CPDLC system, which is operational at Eurocontrol's Maastricht Upper Airspace Control Centre and has now been extended by Eurocontrol's Link 2000+ Programme to many other European Flight Information Regions (FIRs). The VDL Mode 2 networks operated by ARINC and SITA are used to support the European ATN/CPDLC service.

The following UACs offer CPDLC services:

  • Karlsruhe UAC (EDUU), controlling Rhein UIR (above FL245)[3]
  • London ACC (EGTT), controlling London UIR (above FL195 or FL285)
  • Maastricht UAC (EDYY), controlling Amsterdam FIR, Hannover UIR and Brussels UIR (above FL245)[4]
  • Scottish ACC (EGPX), controlling Scottish UIR (above FL195, FL245 or FL255)

Following the PETAL I and II (Preliminary Eurocontrol Trial Air Ground Data link) trials in 1995 including NEAN (VDL Mode 4), today both ATN (VDL Mode 2) and FANS 1/A services are supported.

More than 40 major airlines participate in the CPDLC programme with Maastricht UAC. Average end to end response times (ATC-cockpit-ATC) are well below 30 seconds. More than 30,000 LOG-ON’s were reported in 2007, leading to over 82,000 CPDLC uplinks, each saving precious frequency time.

ATC clearance (ACL), aircraft communication messages (ACM), and check mike (AMC) services are supported, including the automatic uplink of the SSR transponder code into the cockpit.

CPDLC will probably be a major enabler for following on projects as monitor message, route clearance uplink, 2-4 D trajectories, continuous descent approaches, and constraint coordination also.

Safety[edit]

All CPDLC deployments must be supported by an approved safety case demonstrating that all safety objectives for the applicable airspace have been met. EUROCAE ED-120 (RTCA DO-290) is the safety and performance requirements (SPR) for continental airspace and should be consulted for the safety objectives relevant to the use of CPDLC in continental airspace.

ED-120 provides a hazard analysis and identifies the hazards applicable to systems implementing the ATC services that CPDLC deployments are currently providing. It then derives the safety objectives for such systems and the safety requirements with which they must comply.

Implementers of both ground and airborne systems must comply with these safety requirements if their products are to be approved and/or certified for operational use.

Safety objectives identified by ED-120/DO-290 include the need to ensure that messages are neither corrupted nor mis-delivered. Equally important is the need for accurate timestamping and the rejection of out-of-date messages. A consequence of these requirements is that CPDLC implementations, both on aircraft and at ATC centres, must have access to an accurate clock (to within 1 second of UTC). For aircraft, this is typically provided by GPS.

See also[edit]

References[edit]

External links[edit]