Datalink plans
Document Sample


International Civil Aviation
Organization WP/ASP02-30
6 April 2007
Information Paper Agenda Item 5.9.3
AERONAUTICAL SURVEILLANCE PANEL (ASP)
2ND WORKING GROUP MEETING
Brussels, 16 to 20 April 2007
ATC System Requirements for ADS-B
Prepared by Greg Dunstone Airservices Australia
Presented by Kojo Owusu Airservices Australia
SUMMARY
The paper discusses the attributes of an ATC system that uses ADS-B reports.
Page 1 of 6
1 Background
Airservices has operationally commissioned ADS-B for delivery of ATC services. A 5 nautical mile
separation standard has been approved and is currently in use. This paper examines the changes made
to the Australian ATC system to give effect to this move forward.
2 Introduction
The Australian ATC system is supported by the Thales Eurocat X ATC automation system. The
system comprises the following integrated elements:
Radar data processing
Flight data processing
ADS-C processing
ADS-B processing
NOTAM and MET delivery processing
Controller workstations
ATC simulator and data preparation systems
3 ATC processing features
The Australian Eurocat X system currently displays surveillance data to controllers in a priority
system whereby ADS-B is only displayed to controllers when there is no radar detection. This
technique has allowed a careful and gradual transition to ADS-B technology.
In addition, the ATC system has been modified to support numerous other aspects of ADS-B as
described in the following list. The major features are:
Display of ADS-B tracks using multiple ADS-B position symbols (high quality and low
quality)
Integrated ADS-B safety alerts (STCA, DAIW, CLAM, RAM etc)
Display of RAIM prediction to controllers
Use of ADS-B to update the flight plan
ATC simulator support of ADS-B
ADS-B bypass processing system
Australia intends to progress further with ADS-B integration, building on the experience already
gained. In particular the following additional changes have been developed but not yet implemented:
Reduction of the FANS-1/A ADS-C reporting rate when ADS-B data is received – to
save operators the cost of data communication service provider fees
Addition of ADS-B to Terminal Area Centres
Page 2 of 6
Addition of the ability to receive ADS-B data over a larger geographical area.
Transition from the display priority system to a fused data system, so that the positional
and other “aircraft state” data presented to controllers will be truly merged/ fused data
taking into account the relative strengths and weaknesses of the various surveillance
technologies. This also allows STCA between an ADS-B aircraft and a radar detected
aircraft.
4 More than position display
It can be seen from the above that the implementation of ADS-B for surveillance is more than the
presentation of ADS-B data as if it were radar. ADS-B has several characteristics that necessitate it
being treated differently from radar:
a) ADS-B has different failure modes and the controller needs to be aware that the data is ADS-
B derived – and hence probably susceptible to GPS outage effects
b) ADS-B data is derived in the aircraft. Therefore messages received at separate ground
stations will be identical. No fusion, merging or weighting of positional data is needed
because the most recent data is the most valuable. This is in contrast to radar where the error
characteristics of the data depend on the range of the target from the radar. The result is that
fusion of ADS-B data needs to be considered from a different mindset to that of radar.
Numerous other facets of ADS-B warrant different treatment including:
ADS-B data transmission usually begins whilst the aircraft is on the airport surface
Different alert flags are possible
Flight ID and 24 bit code are available for matching
4 digit SSR octal code may not be available
24 bit ICAO code is useful for matching received ADS-B messages with previously received
messages and the maintained track file of the aircraft.
Whilst management of these factors in a display system brings change and hence cost to ADS-B
deployment, the changes tend to be “one off” as they are performed in software in the ATC system for
the first ADS-B ground station used and additional costs are not borne for subsequent ADS-B ground
station deployment.
5 Conclusion
The meeting is invited to consider the ATC system requirements that will needed to support ADS-B.
The data cannot be simply treated as “another radar”.
Page 3 of 6
APPENDIX A
AUSTRALIAN ATC AUTOMATION ADS-B FEATURES
Feature Description Comment
DISPLAY Display ADS-B tracks when FOM > Indicate to controller that data
parameter source is ADS-B alone and that
continued operation may be
dependent on the GPS satellite
Display different position symbol Indicate to controller that ATC Optional use of lower
when FOM > P1 but < P2 separation is not possible with quality symbol?
this ADS-B data
RAIM display Consider if a RAIM prediction Optional warning to ATC
system is required to indicate to regarding GPS constellation
controllers or supervisor possible status
GPS outages in particular
airspace
Indicate failure of ADS-B receiver Typically this will involve
to technical or operational staff site monitor processing
Update ATC simulator to support ADS-B training must include
ADS-B ability to manage ADS-B events
such as loss of GPS
Indicate to a controller that an Advise controller that if the Aircraft could be non ADS-
aircraft is being detected by ADS-B displayed aircraft leaves radar B because it is not equipped,
whilst inside radar coverage coverage, surveillance will or because it is not within
continue with ADS-B (whereas the ADS-B coverage area.
non equipped aircraft will leave
surveillance coverage)
Decide if and how to use barometric Possible use of geometric altitude
altitude if baro is not available.
Possible use for checking QNH
value is correct?
PROCESS Ability to process all appropriate Process appropriately position,
fields of ADS-B Asterix Cat 21 velocity, Flight ID, 24 bit code,
V0.23 geo and baro altitude, SPI,
emergency indicators, FOM etc
Protect or warn against Duplicate 24 Possibility exists of 2
bit codes aircraft on same 24 bit code
Protect and manage against invalid Possibility exists of
24 bit codes receiving invalid 24 bit
codes
Allow manual uncoupling of ADS- In case of erroneous coupling
B report and flight plan allow controller to detach so that
ADS-B data does not update
flight plan
Page 4 of 6
Feature Description Comment
Allow for QNH correction of ADS- Normal QNH processing but
B data below transition applied to ADS-B
level/altitude
Vertical rate smoothing Vertical rate data from ADS-B
can be “noisy” and may need
smoothing for some applications,
especially for vertical velocity
prediction for safety alerts. Need
to consider geo and baro vertical
rates.
ADS-B data to update flight plan
ADS-B data to match to flight plan
using Flight ID in ADS-B message
to Flight ID of flight plan. May also
use 24 bit code if the code is in the
flight plan.
Support appropriate safety nets STCA, RAM, CLAM, DAIW,….
Support flight plan indicators that Advises equipage but does not
advise of ADS-B equipage confirm that it is working!
Ensure playing area accounts for New coverage may be provided
new coverage by ADS-B
ADS-B bypass processing Provide for ADS-B bypass Consider flight plan
channel if required matching, QNH correction,
extrapolation, FOM filtering
etc
Recording and replay of ADS-B Same as for radar but processing
data required for ADS-B
Management of “time of detection” Extrapolate position data or
discard old data
Allow for visibility of ADS-B Matching to flight plan may occur Aircraft transmit ADS-B
ground transmissions before departure because ADS-B messages whilst taxiing.
data may be received whilst These messages can be
taxiing received and processed.
Site monitor processing An integrity monitoring tool and Monitor position, signal
fault detection tool strength, HPL, GPS satellite
ranging errors….
Manage multiple reports Use time tag to use only the latest
report. Position is measured in the
aircraft and radar techniques of
multiradar tracking are not
appropriate.
Perform position reasonableness Detect position decoding errors,
testing as appropriate protect against spoofing
Page 5 of 6
OTHER POSSIBLE ADS-B FEATURES
Feature Description Comment
Capability to manually disable Allow data to be discarded from a Could be useful in the unlikely event
display of ADS-B returns from a designated aircraft. of erroneous data from an aircraft
particular target
Display of new alerts (if used) Lifeguard / medical and Minimum
fuel
Display of ACAS RA events A downlink message has been
defined in ICAO Doc 9871 to be
published late in 2007
=== END ===
Page 6 of 6
Get documents about "