170 likes | 480 Views
Delivering CNS/ATM Services to the Aircraft. Presented by Forrest Colliver. A discussion of the FANS/ATN accommodation question, in the context of ground Air Traffic Service provider communication architectures. The CNS/ATM Deployment Problem Statement (1 of 2).
E N D
Delivering CNS/ATM Services to the Aircraft Presented by Forrest Colliver A discussion of the FANS/ATN accommodation question, in the context of ground Air Traffic Service provider communication architectures ATN2002 (London)
The CNS/ATM Deployment Problem Statement (1 of 2) • Deploying CNS/ATM…what we’d like… • We all implement CNS/ATM the same way… • at the same pace… • based on “master plan”, standardized on a global basis. • The reality… • Regional stakeholders implement pieces of the CNS/ATM puzzle • based on local political & industrial priorities; • using available technologies & tailored operational procedures; • on an ad hoc basis. • Meanwhile, ICAO, IATA, et. al. create the “real” CNS/ATM • international operational service & technology standards; • broad user consensus and on longer-term benefits models ATN2002 (London)
The CNS/ATM DeploymentProblem Statement (2 of 2) • The result… • Competing non-interoperable CNS/ATM technologies & services • Costly & inefficient process for stakeholders & vendors • Compromised long-term CNS/ATM benefits • No obvious growth path • And of course…a lot of shouting… ! ATN2002 (London)
FANS 1/A: de-facto oceanic data link standard • Pacific region trials from 1993+; first operational use from 1998+ (for routes in remote/oceanic airspaces) • Services include FANS versions of ADS & CPDLC • Uses ACARS/AIRCOM as data link; performance and integrity acceptable in non-dense airspaces Oceanic Data Link Services • ATN : the ICAO, EUROCAE & RTCA standard for CNS/ATM • European & US trials from 1992+; operational deployment in US from 2003-2005; planning in progress in Europe • CPDLC is the benefits driver, based on positive business cases (C/AFT, RTCA, EUROCONTROL) plus user demand • Uses modern data links (VDL, SATCOM, ATM, IP etc.), thus integrity & performance suitable for high density airspaces Point-to-Point Data Link Services • Trials in Europe & US from 1995+ have matured a variety of broadcast link technologies (VDL4; Mode S, UAT) • Main user of broadcast data links remains surveillance applications based on ADS-B: from basic air/ground surveillance to autonomous aircraft surveillance systems • Broadcast media optimized for surveillance, not “data link” Broadcast Data Link Services Data Link Implementation…the Status Quo ATN2002 (London)
The point-to-point data link problem in focus… • FANS 1/A & ATN look fairly similar on the surface… • Both are point-to-point • sessions between controller, pilot and automated equipment • Both support similar applications • context management, ADS & controller/pilot communication dialogs • However… • FANS 1/A constrained by ACARS/AIRCOM and legacy architectures • Result: performance and application limitations • ATN designed for digital data links & future CNS/ATM architectures • Result: fit for ICAO CNS/ATM purpose with architectural growth potential Although significant application & performance differences exist between FANS & ATN, strong motivation for “accommodation” of FANS-equipped aircraft in ATN airspace exists, to better amortize FANS investments in these aircraft to-date. ATN2002 (London)
FANS “Accommodation”Scenarios and Consequences (1 of 4) • FANS accommodation issues thoroughly studied… • by ICAO, IATA, IRRF & other industry groups • The conclusions, unchanged since 1995 ICAO analysis: • Current FANS 1/A airborne systems cannot be accommodated transparently in an ATN (EUROCAE ED-110) airspace implementing profile-changing messages without some form of operational workaround (procedural, voice read-back, etc.) • If FANS 1/A & ATN aircraft share ATN airspace without workarounds or upgrades: • ATN services must be limited to those common with current FANS 1/A • Profile-changing messages must be excluded • Ground gateways or multi-protocol ground hosts will be required In the case of FANS accommodation in dense/continental ATN airspace, ICAO CNS/ATM data link benefits will necessarily be constrained. ATN2002 (London)
FANS “Accommodation”Scenarios and Consequences (2 of 4) However, given that “FANS accommodation” transparent to the Air Traffic Service provider is not viable, but that the coexistence of FANS & ATN aircraft in the same airspace is required, what are the available communication architectural choices ? ATN2002 (London)
FANS “Accommodation”Scenarios and Consequences (3 of 4) • External Gateways • External to the CNS/ATM provider perimeter & control • Likely operated by communication service provider, like store & forward message switch, performing FANS/ATN application conversion • Internal Gateways • Internal to the CNS/ATM provider perimeter & control • Likely operated by ATS provider, performing mainly protocol conversion • Multi-Protocol CNS/ATM Host • Implemented within CNS/ATM provider perimeter & control • Part of ATS provider ATM host system; includes both application & communication functions; preserves end-to-end service relationships with no intermediate translation functions ATN2002 (London)
FANS “Accommodation”Scenarios and Consequences (4 of 4) ATN2002 (London)
WAN (X.25, IP, FR, …) WAN (X.25, IP, FR, …) WAN (X.25, IP, FR, …) ATN ES/BIS ATN G/G BIS Ground Data Link Architecture Basic ATN ATSO CSP Local ATN G/G BIS ATCC ATN A/G BIS ATN G/G BIS Local ATN G/G BIS ATCC ATN A/G BIS ATN A/G BIS ATN2002 (London)
WAN (X.25, IP, FR, …) WAN (X.25, IP, FR, …) WAN (X.25, IP, FR, …) ATN ES/BIS ATN G/G BIS ATN G/G BIS To network management systems Ground Data Link Architecture General ATN Backbone Extension To other domains… Backbone BIS CSP ATSO ATN A/G BIS Backbone BIS Backbone BIS ATN G/G BIS ATSO ATN2002 (London)
ATN ATN G/G BIS WAN WAN WAN Ground Data Link Architecture FANS Accommodation using Gateways FANS 1/A ATS Internal FANS access FANS ATN GTW ACARS Network ATN G/G BIS ATCC External FANS ATN GTW ATN A/G BIS ATN G/G BIS ATN G/G BIS ATCC CSP ATN2002 (London)
VDL Mode 4 Stations Mode S ‘ ExtendedSquitter ’ Mode S VHF Satcom Satcom UAT National Networks VDL Mode 2 Radarnet ACARS Networks SITA-ARINC ATN VDL 4 ATN ES Mode S FANS-1 Integrated DataLink Server CAERAF CTS ATIS ADS CPDLC FDPS SDPS HMI Meteo Access ATCC Access Meteo Data Aircraft data Ground Data Link Architecture Multi-Protocol Host ATN2002 (London)
Ground Data Link Architecture ATN Design Tradeoffs Balance between ATS providers and Communication Service providers to provide ATN service interfaces ATS Service Providers Communication Service Providers • End-Systems Only • End-Systems and ATN Routers Only • Full ATN Internet Service Increase capital investment Decrease ATS operating costs Increase ATS control of communications • Partial ATN Internet Service • &/or Subnetwork Service • End-Systems, ATN Routers and some Subnetworks • Most Ground-Ground Subnetwork • & Air-Ground Subnetwork Service • End-Systems, ATN Routers and most Subnetworks • Some Ground-Ground Subnetwork & Air-Ground Subnetwork Service ATN2002 (London)
Conclusions • Numerous analyses have shown that current FANS 1/A aircraft cannot be accommodated transparently in ATN Baseline 1 airspace, without loss of benefits available to ATN aircraft. • However, FANS 1/A aircraft may be able to obtain benefits in mixed airspaces without comprising services to ATN aircraft, if ATS providers communicate to each aircraft type directly. • This approach eliminates the viability of the “external gateway”, but can be supported by the internal gateway, if properly implemented and operated. • The best ground architecture for FANS accommodation is the multi-protocol ATS host: • Since FANS and ATN aircraft can be clearly distinguished for air traffic management and communication purposes, and, • Since ATS services can be tailored to local needs. ATN2002 (London)
Questions ? ATN2002 (London)