Transcript Delivering CNS/ATM Services to the Aircraft

Delivering CNS/ATM Services to the
Aircraft
A discussion of the FANS/ATN accommodation question, in
the context of ground Air Traffic Service provider
communication architectures
Presented by Forrest Colliver
24/25 September 2002
ATN2002 (London)
1
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
24/25 September 2002
ATN2002 (London)
2
The CNS/ATM Deployment
Problem 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… !
24/25 September 2002
ATN2002 (London)
3
Data Link Implementation…
the Status Quo
Oceanic Data Link
Services
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
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
Broadcast Data
Link Services
24/25 September 2002
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”
ATN2002 (London)
4
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.
24/25 September 2002
ATN2002 (London)
5
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:
1.
2.
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.
24/25 September 2002
ATN2002 (London)
6
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 ?
24/25 September 2002
ATN2002 (London)
7
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
24/25 September 2002
ATN2002 (London)
8
FANS “Accommodation”
Scenarios and Consequences (4 of 4)
Characteristic
External Gateway
Internal Gateway
Multi-Protocol Host
Acquisition Cost
Relatively high per gateway
(due to technical complexity
and certification issues)
Medium per gateway
(similar to External, but with
reduced technical complexity)
Relatively low
(integrated/optimized for host)
Lifecycle Cost
High
(limited control over operating
costs and network tariffs)
High
(limited control over operating
costs and network tariffs)
Medium to Low
(better control over operating
costs and network tariffs)
Technical Complexity
High
(completely generic)
Medium
(partly optimized for ATS
center needs)
Low
(fully optimized for ATS center
needs)
Performance
Relatively lower
(due to complex functionality &
sessions per aircraft)
Medium
(partly optimized for ATS
center needs)
Relatively higher
(fully optimized for ATS center
needs)
Security Issues
Significant
(due to scope of control and
technical complexity)
Moderate
(partly optimized for ATS
center needs)
Low
(optimized for ATS center needs;
operated by ATS authority)
Liability & Certification
Complexity
High
(due to application gateway
role in end-to-end services)
Medium
(due to design assurance
requirements)
Low
(based on integration with ATS
host system & center)
Maintains ATN Baseline 1
Service Benefits
No
(due to conversion of FANS to
ATN application messages)
Possible
(depends on “application”
nature, or not, of gateway)
Yes
(maintains separate ATN/FANS
end-to-end thread)
24/25 September 2002
ATN2002 (London)
9
Ground Data Link Architecture
Basic ATN
ATN ES/BIS
ATSO
CSP
Local ATN
G/G BIS
ATN
A/G BIS
ATN
G/G BIS
WAN
(X.25, IP, FR, …)
ATN
G/G BIS
WAN
ATCC
(X.25, IP, FR, …)
Local ATN
G/G BIS
WAN
(X.25, IP, FR, …)
ATCC
ATN
A/G BIS
ATN
A/G BIS
24/25 September 2002
ATN2002 (London)
10
Ground Data Link Architecture
General ATN Backbone Extension
To other domains…
ATN ES/BIS
ATN
G/G BIS
Backbone
BIS
CSP
ATN
A/G BIS
Backbone
BIS
WAN
(X.25, IP, FR, …)
ATN
G/G BIS
Backbone
BIS
WAN
ATSO
WAN
(X.25, IP, FR, …)
ATN
G/G BIS
(X.25, IP, FR, …)
ATSO
To network management systems
24/25 September 2002
ATN2002 (London)
11
Ground Data Link Architecture
FANS Accommodation using Gateways
ATN
FANS 1/A
ATS
FANS
access
ACARS
Network
ATN
G/G BIS
FANS
ATN
GTW
ATCC
External
FANS
ATN
GTW
ATN
A/G BIS
Internal
WAN
ATN
G/G BIS
WAN
ATN
G/G BIS
WAN
ATN
G/G BIS
ATCC
CSP
24/25 September 2002
ATN2002 (London)
12
Ground Data Link Architecture
Multi-Protocol Host
Satcom
VDL Mode 2
Mode S
‘ Extended
Squitter ’
Mode S
VDL Mode 4
Stations
VHF
Satcom
UAT
National
Networks
Radarnet
ACARS
Networks
SITA-ARINC
ATN
ATN ES
Mode S
VDL 4
FANS-1
CAERAF
CTS
ATIS
Meteo
Data
24/25 September 2002
Meteo
Access
ADS
Aircraft data
CPDLC
ATCC
Access
ATN2002 (London)
FDPS
SDPS
HMI
13
Ground Data Link Architecture
ATN Design Tradeoffs
Increase capital investment
Decrease ATS operating costs
Increase ATS control of communications
Balance between ATS providers and Communication
Service providers to provide ATN service interfaces
ATS Service Providers
Communication Service Providers

End-Systems Only

Full ATN Internet Service

End-Systems and
ATN Routers Only

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
24/25 September 2002
ATN2002 (London)
14
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.
24/25 September 2002
ATN2002 (London)
15
24/25 September 2002
ATN2002 (London)
16