RTCA SC-214/EUROCAE WG-78

dimerusticΔίκτυα και Επικοινωνίες

23 Οκτ 2013 (πριν από 4 χρόνια και 20 μέρες)

126 εμφανίσεις

RTCA SC
-
214/EUROCAE WG
-
78

Air Traffic Services Safety and Interoperability Requirements

General Information

Paper Reference:

POS
-
PL
-
JSRI
Position on
Trajectory
Synchronization

Revision:

A

Dat e:

11 Apr 2011

Status:

Individual(s) Proposal

Editor /
Author
:

GE
-

Lockheed Martin

Review Meet ing/Teleconference:

Plenary 11


15 Apr 2011

Comments Due:

ASAP

Posit ion Paper Title:

GE
-
LM

JSRI Position on Trajectory Synchronization

Abstract and Proposed Action:


In recognition of the importance of
Trajectory Based Operations (TBO), General Electric (GE) and Lockheed
Martin (LM) have created a TBO Joint Strategic Research Initiative (JSRI), which aims to generate technologies
that accelerate adoption of TBO in the Air Traffic Management (ATM) realm.
The purpose of this document is to
provide input to RTCA SC

214/EUROCAE WG
-
78 regarding Controller
-
Pilot Data Link Communication
(CPDLC) and Automatic Dependent Surveillance
-
Contract (ADS
-
C) based our experience in developing air

ground trajectory synchron
ization algorithms.
Proposed actions include:


1.

Variable definit ions related t o
CPDLC messages
uM264, uM266, uM267.

2.

The use
and concatenation
of dM122,
uM74,
uM264, uM266, uM267,
uM289, uM339.

3.

Variable and message definit ion related t o ADS
-
C EPP
demand and event contract and reports.

4.

Suggest ions t o maint ain consistency in variable definitions and interface bet ween FMS (ARINC 702), ICAO Flight Plan (ICAO 444
4),
and Dat a Comm SPR.








Key words (Opt ional):

ATS; Datalink; Communications

Distribution

SC
-
214/WG
-
78Groups

Additional Names

Additional Names

Additional Names

Plenary




CSG




VSG






























1


RTCA SC
-
214/EUROCAE WG
-
78, Data Communications Standards

(Berlin, Germany, 11
-
15 April 2011)

GE
-
LM JSRI
Position on Trajectory Synchronization

1

Introduction

In recognition of the importance of Trajectory Based Operations (TBO), General Electric (GE) and
Lockheed Martin (LM) have created a TBO Joint Strategic Research Initiative (JSRI), which aims to
generate
technologies that accelerate adoption of TBO in the Air Traffic Management (ATM) realm. TBO
is not realizable without improving the coordination and interoperability of air and ground systems. By
leveraging GE’s Flight Management System (FMS) and aircraft
expertise with Lockheed Martin’s Air
Traffic Control (ATC) domain expertise, the JSRI aims to explore and evaluate trajectory synchronization
and negotiation concepts that bring airspace operations closer to the business

optimal goal in a safe and
efficien
t manner
[1]
[2]

(See attachment 1 and 2
)
.

The purpose of this document is to provide input to
RTCA SC

214/EUROCAE WG
-
78 regarding
Controller
-
Pilot Data Link Communication (
CPDLC
)

and
Automatic Dependent Surveillance
-
Contract (
ADS
-
C
)

based
on
our experience in developing air

ground
trajectory synchronization
algorithms
.

Reference to the
SC
-
214/WG
-
78 Data Communications Safety and
Perf
ormance Requirements (
SPR)

[3]

are p
rovided where applicable.

2

Trajectory Synchronization

The
JSRI air
-
ground trajectory synchronization consists of the following

four steps:

1.

Flight Plan Verification

and Consolidation
: Validate major flight plan elements (including terminal
procedures
,

en route airways
, and waypoints
) between the two
flight plans
, removing elements or
inserting new ones
as

needed.

This will create a partially consolidated flight plan.

2.

Restriction Compliance Verification

and Consolidation
: Validate that all applicable
altitude and
speed constraint
s are
included in
both
flight plans
, adding restrictions to the flight
plan

if needed.

This will create a final consolidated flight plan.

3.

Build Synchronized Trajectory: Construct a new trajecto
ry in the ground system using the
newly
built

FMS trajectory as a reference, which now contains synchronized flight plan elements and
altitude and speed constraint
s.

4.

Monitoring Re
-
synch
ronization

Triggers: Monitor trajectory and all trigger events to de
termine
when the
dynamic re
-
synch
ronization process should be
initiated.

T
he JSRI trajectory synchronization uses CPDLC for
flight plan modifications and restrictions

uplink
and
ADS
-
C for
trajectory data
downlink.
The
ADS
-
C is also used for
event trigger
d
ownlink
. Effort
s

ha
ve

been
taken to use both Future Air Navigation System


1/A (FANS
-
1/A) messages and
new
Aeronautical
Telecommunication Network (ATN)

messages in
SPR

[3]
.

However, t
he
baseline algorithm

will be based
on
ATN
messages

in the Data Comm SPR

only
.

3

CPDLC

Messages

3.1

Summary of

CPDLC Message

Issue
s

Related to

Trajectory Synchronization

A number of
issues related to ATN
CPDLC message elements
have been identified during the course of
JSRI trajectory synchronization algorithm

development. These issues are summarized in

Table
1
.
For
reference purposes,
the
IDs of
corresponding FANS
-
1/A messages are
also
listed

in parentheses
below
the ATN message ID
.
In the

table, a brief
description

is provided for each of the messages to explain how
these messages are used in the JSRI trajectory synchronization algorithm.


2


Table
1

Summary of
CPDLC
Issue
s

#

Message Elements

Issue

Proposed Action

1

See
ri ght
col umn

[
Route Clearance Enhanced
]

i n
messages
dM122

(dM26), uM266
(uM79), uM267 (uM80), uM268
(uM83), uM339 (N/A)

Speed constrai nt type i s not
i ncl uded for these

messages.

Add
Speed
Constraint
T
ype
.

2

Route ambi gui ty i n ATS Route
Desi gnator requi rements.

Al ways provi de the poi nt
l eavi ng current ai rway.

3

dM139

(N/A)

REQUEST DEPARTURE CLEARANCE
[
Departure Clearance Request Data
]

Approach procedure i s not
i ncl uded [
Departure Clearance
Enhanced
] i n uM264.

Add
Expected Approach
Procedure

i n
Departure
Additional Informatio
n
.

uM264

(uM73)

[
Departure Clearance Enhanced
]

4

dM122

(dM26)

REQUEST WEATHER DEVIATION TO
[
Position
] VIA [
Route Clearance
Enhanced
]

The use of dM122 is li mi ted to
weather devi ati on onl y.

Remove WEATHER
from
dM122
or add a new
message

for non
-
weather.

5

uM266

(uM79)

CLEARED
TO [
Posi tion
] VIA
[
Route
Clearance Enhanced
]

Condi ti on for prohi bi ted
opti onal vari ables not speci fi ed
.

Add condi ti on for
prohi bi ted vari abl es.

6

uM267

(uM80)

CLEARED [
Route Clearance
Enhanced
]

SPR requi res the enti re route to
be i ncl uded
.

Al l ow opti onal
Route
Information

be omi tted.

7

uM
339

(N/A)

AT [
Posi tion
]
CLEARED
TO [
Position
]
VI A
[
Route Cl earance Enhanced
]

Concatenati on
requi rement
wi th uM
289 mi s s i ng.

Add c
oncatenati on
requi rement
wi th uM
289
.

8

uM74

(same)

PROCEED DI RECT TO [
Position
]

Concatenati on
condi ti on wi th
uM
266 and uM267
mi ssi ng.

Add concatenati on
condi ti on.


3.2

Specific CPDLC Message

Element
s

and Proposed Actions

The analysis
presented in this paper
was based on the latest draft of the Data Comm SPR
[3]
.
Each
issue
is identified

by an unique item number.

Route Clearance Enhanced
Messages

1
.

Speed
Constraint Type
. This is a
lso a
n issue common to all [
Route Clearance Enhanced
]
messages. “
Speed
” in
the

ATW Along Track Waypoint


and the

Waypoint (M)
and Speed (O)
and Level (O)


subfields of
the

Route Information Additional Sec
” field is as a single value
without the associated
constraint type
to specify if it is
AT,
AT OR LESS THAN
,
or
AT OR GREATER
THAN

(CPC
-
OR
-
8

in
[3]
)
. On the other hand,
a speed
constraint
type is
explicitly
spelled out

by
speed
constraint

uplink messages
: uM55 CROSS [
Position
] AT [
Speed
]
, uM56 CROSS [
Position
] AT
OR LESS TH
AN [
Speed
]
, and uM57 CROSS [
Position
] AT OR GREATER THAN [
Speed
]
.

To be
consistent with uM55, uM56, and uM57, a


Speed
Constraint
T
ype
” variable sh
ould

be added
and associated with the above mentioned “Speed” in the “
Route Information Additional Sec

field
:

Speed
Constraint Type


Enumerated Choice:



AT



AT OR LESS THAN



AT OR GREATER THAN


3


2
.

Use of
Air Traffic Service (
ATS
)

Route D
esignator
.

In defining the route, the SPR specifies that
an “
ATS Route Designator
” may be followed
by an intersecting

ATS Route Designator


(CPC
-
OR
-
85 in
[3]
). In fact, even in the case of intersecting ATS routes, ambiguity may

still arise
without
providing
a

point at which the aircraft is to leave the
first ATS route
.
ICAO flight plan includes
explicit rules

(APPENDIX 2 in ICAO 4444
[4]
)

that define unambiguous routes for
composing the
flight plan
message
.
As a relevant example
, ICAO flight plan requires an explicit point being
define
d when transiting from one ATS route to the next ATS r
oute. The ICAO flight plan route
de
finition rules should be adapted by the Data Comm SPR because they are used by the same
users for
related
purposes.

Specifically:


CPC
-
OR
-
85

An
ATS Route Designator

shall be followed
either
by a
Published
Identifier

on the designated ATS route, indicating the point at which the aircraft is to
leave the airway,
regardless
whether

the next item is
or

by
an in
tersecting
ATS Route
D
esignator

or not
.

Departure Clearance
Messages dM139 and uM264

3
.

Approach Procedure
.
TBO envisions end
-
to
-
end trajectory clearances. It is thus
required

to be
able to specify the approach procedure (including the arrival runway) in uM264,
preferably
as

Expected Approach Procedure


in the “
Departure Additional
Information


field

(CPC
-
OR
-
8

in
[3]
)
.

It

is e
specially important for short flights (pop up flights) to
specify

full route including
the
app
roach pr
ocedure in the DCL
, when the scheduling horizon for a hub airport is greater than
these short flights duration
. This would save
bandwidth.

The proposed change is shown below:

Departure Additional Information (O)


Sequence:



Expected Arrival Procedure (O)



Expected Approach Procedure (O)



Special Instruction (O)

Downlink
Message
dM122

4
.

Non
-
Weather Related Deviation Request
.
In addition to avoiding weather
,
there is
also
a need
to
reques
t deviations for
business
reasons
.
For example, the air
craft

may elect to voluntarily
avoid congested airspace, or fly a more optimal route

than the previously cleared route
.
A
message should be provided to request a deviation to a position that is not related to weather;
m
essage

dM122
(dM2
6)
is limited
to weather deviation requests

(CPC
-
OR
-
5 in
[3]
)
. The term
WEATHER
should
be
remov
ed
from dM122 to make it a generic route deviation re
quest, i.e.
redefine it
as
REQUEST
DEVIATION TO [
Position
] VIA [
Route Clearance Enhanced
]
.

If it is
necessary to specify weather, d
M65

DUE TO WEATHER

can be
concatenat
ed
.
If dM122 is not
changed, another a
lternatively,
is to add
a new message
specific to r
equesting a deviation that is
not due to weather
:

dM122 REQUEST
WEATHER
DEVIATION TO [
Position
] VIA [
Route

Clearance
Enhanced
]


Or

dMxxx REQUEST DEVIATION TO [
Position
] VIA [
Route

Clearance Enhanced
]

Uplink Message uM266

5
.

Prohibited Optional Variables
.

The SPR specifies optional variables

Departure Airport

,

Departure Runway


and

Departure P
rocedu
re


sh
ould

be prohibited in the [
Route Clearance
E
nhanced
] field (CPC
-
OR
-
81

in
[3]
)

in uM266
.

This would
limit

the use of uM266
to

replacing part
of the en route portion only
,
and prevent it being effectively used
in pre
-
flight
trajectory

4


synchronization.
There is also a re
quired concatenation with uM74
PROCEED DIRECT TO
[Position]
, which would create a problem when the aircraft is still on ground. This should be
specified as a conditional requirement

(
also
see Item
8

below)
:


CPC
-
OR
-
81

The ATSU system shall be prohibited from including any of the
following in UM266:
Departure Airport
,
Departure Runway

or
Departure Procedure
,

in
the
Route Clearance Enhance
d

field

if the aircraft is already en route to its destination
.

Uplink Message
uM267

6
.

Restriction Uplink
.

Message uM267 is intended to uplink a new or modified route as [
Route
Clearance Enhanced
]. Because all fields in [
Route Clearance Enhanced
] are optional, it is possible
to use uM267 to uplink restrictions
without uplink the entire route
:

uM267
CLEARED
[
Route Clearance Enhanced
:


Route Information Additional Sec
:



ATW Along Track Waypoint
:




BTG 15nm IAS280 AT OR BEL
OW FL280



ATW Along Track Waypoint
:




OLM IAS250 12000]}


However, the SPR requires the entire route be included (CPC
-
OR
-
83

in
[3]
).

It should be
specified
in the SPR that uM267 may be used to uplink any or all parameters in the “
Route Information
Additional Sec
” field without including the “
Route Information
” field.
In this case

uM289 REST OF
ROUTE UNCHANGED

should be appended
(concatenated)
to uM267 to indicate the route
itself
is
not changed
:


CPC
-
OR
-
83

When UM267 is used to uplink a
Route Information

variable in the
Route
Clearance Enhanced

field, it shall include the entire route to the destination airport.


Note:

Use of uM267 to uplink
R
oute Information

will replace all parts of the current
active route in an aircraft system capable of auto
-
loading route uplinks. Therefore
Route
Information

in uM267 should be used only when diverting to an alternate airport or when
the entire route to th
e destination airport is to be changed. It can be used for partial
revisions to the route only if the unchanged downstream parts of the route are also
included in the route clearance.


CPC
-
ORec
-
x

ATSU systems should append UM289 REST OF ROUTE
UNCHANGED to

UM267 when the optional
Route Information

is not included in
Route
Clearance Enhanced

field to indicate the route itself is not changed.

Uplink Message uM
339

7
.

Concatenation with uM
289
. The SPR

require
s

(CPC
-
OR
ec
-
6

in
[3]
) that
i
f uM266 is used to
replace part of the route and then rejoin the current route after the CLEARED TO [
Position
],
uM289 REST OF ROUTE UNCH
ANGED shall be appended to UM266.

The same concatenation
should apply to uM339, which may also be used to replace part of the route

and then rejoin the
current route after the
CLEARED TO [
Position
]
:

5.2.7.11

Use of uM339


CPC
-
ORec
-
x

ATSU systems should
append uM289 REST OF ROUTE
UNCHANGED to uM339 when the aircraft is to continue on its current route after the
position in CLEARED TO [position] is reached. In this case, position must be on the
current route.


5


Uplink Message uM74

8
.

Concatenation with uM266

or

uM267
.
The SPR does not specify the condition under which the
concatenation of uM74 with uM266 or uM267 is required to provide an unambiguous intercept
point for the aircraft to acquire the new

route (5.2.7.3

in
[3]
). The concatenation should only be
required when the aircraft is already en route to its destination where the first point
in

the
uplinked
[
Route Clearance Enhanced
] is required

(CPC
-
ORec
-
11
in
[3]
)

to
be
a

point sufficient
time ahead of the aircraft.

For pre
-
flight trajectory synchronization, the aircraft is still on ground,
and thus a DIRECT TO is not necessary
:

5.2.7.3

Use of UM267 o
r UM266 Concatenated with UM74


Whenever a route clearance and a direct to clearance are uplinked in a concatenated
message the message element
u
M74 “direct to” shall follow the message element
u
M266
or message element
u
M267.


Note 1:
When the aircraft i
s already en route to its destination,
t
o remove any potential
for ambiguity in how the aircraft should proceed from its present position to intercept or
link to the route clearance enhanced field, the clearance should include an unambiguous
intercept poin
t for the aircraft to acquire the route in the route clearance uplink (e.g., by a
direct to a waypoint in the route clearance enhanced field.


4

ADS
-
C

Messages

4.1

Summary of
ADS
-
C

Issues
Related to

Trajectory Synchronization

I
ssues related to ATN ADS
-
C as identified during the course of JSRI trajectory synchronization algorithm
development are summarized in
Table
2
.

Table
2

Summary of ADS
-
C
Issue
s

#

Message
/Variable

Issue

Proposed Action

9

Both


EPP Reporting Window


and
“EPP Window”

Wi ndow is from current posi ti on onl y.
Lack of support for appli cati ons
i nterested i n end part of trajectory.

Add a new fi el d “
EPP
Window Alignment
”.

10

Downlink


EPP Data
” waypoint

Lateral Type


Lack of definition for non
-
offset related
waypoints.

Add additional lateral
types.

11

Down
link


EPP Data
” waypoint
position reporting

Reference latitude and longitude not
reported causing problems for
computed waypoints.

Add a new field

Reference Latitude
Longitude
”.

12

Both


Waypoint


Inconsistent use of variable “
Waypoint

in delineating waypoint for EPP contract
request and Projected Profile reporting.

Use separate definitions
rather

than the same

Waypoint
” variable.

14

Both


EPP Event Type
” and
triggers

Definition of certain EPP event types
missing.

Add missing EPP event
types.

14

Uplink

EPP Change event
contract request

Option not to monitor certain EPP
changes is not provided.

Don’t monitor EPP events
not requested by ATSU.

15

Downlink

EPP Change event
reporting

EPP change event reporting content and
condition of reporting not specified.

Add reporting content
and condition.



6


4.2

Specific

ADS
-
C

Issues

and Proposed Actions

The issues in
ADS
-
C

messages identified by the
JSRI
team
are mostly r
elated to variable definitions.

In
some cases a background discussion is provided first,
before the discussion of specific issues and
proposed actions
.

EPP Reporting

Window

9
.

The
EPP Reporting Window

is defined by variable “EPP Window” which can either be given as
the “Number of Waypoints” or as a “Time Interval” starting from the current aircraft position or
current time (Section 6.2.
1, ADSC
-
OR 41

in
[3]
). Often, the ground automation is interested in
the
portion

of the aircraft trajectory ending at the destination. For example,
the EPP window
starting from the current position may not include the entry fix to the destination terminal area,
which is of significant importance for traffic flow management.
For international f
lights, the
destination ATSU is likely more interested in t
he arrival trajectory than the departure trajectory.
The “EPP Window” (ADSC
-
OR 41

in
[3]
) should be able to specify if the window should start from
the current position or ending at the destination:

EPP W
indow


Sequence:



EPP Window Alignment




Enumerated Choice:





STARTING FROM CURRENT POSITION





ENDING AT DESTINATION



Choice:




Number of Waypoints




Time Interval

EPP Data Content

ADS
-
C
Exte
nded Projected Profile (EPP
)

reports downlink FMS 4D trajectories to the ground. EPP
consists of lateral waypoints and vertical reports. While EPP lateral waypoints capture the vertical
profile well, there are issues related to lateral waypoints.

These iss
ues are illustrated by the differences
between the FMS computed trajectory and ADS
-
C EPP reported trajectory

as

shown in

Figure
1

and
Figure
2
.

In these two figures, the FMS computed trajectory is shown as solid blac
k curves, and the ADS
-
C EPP reported trajectory is shown as solid blue curves.
Detailed discussions are provided for each issue
below.


Figure
1

Flyby Turn
and
Radius to Fix

Turn

Turn

Radius
r

Start of
Turn

End of Turn

Sequence Point

(Waypoint Crossing)

Flyby Waypoint

Next

Waypoint

Previous

Waypoint

Angle

of Turn
θ


d

Distance a

Turn

Radius r

Start of Turn

Waypoint

End of Turn

Waypoint

Middle of Arc

Projected Course
Intersection

Waypoint

Waypoint

Angle

of Turn
θ


d

Distance a



7



Figure
2

FMS Trajectory and EPP Report

10
.

Lateral Type
.

EPP

Lateral Type


identifies
OFFSET START, OFFSET REACHED, RETURN TO
PARENT PATH INITIATION, OFFSET
END, and OFFSET
. All other points are identified as
OVERFLY

(
ADSC
-
OR 41 in
[3]
)
. Trajectory data available on FMS intent bus (
5.2.12.2.1

in
ARINC 70
2A
-
3
[5]
)
identifies START POINT, LINE TO POINT, and ARC TO POINT. Distinguishing the difference
between line to point and arc to point is important

for the ground system to interpret
the
reported points.
As shown in
Figure
1
, without distinguishing line to point and arc to point, the
same FMS computed trajectory, one defined as a flyby turn and the other radius to fix turn,
would be reported differently by the EP
P. There is no way for the ground to reconstruct a similar
model from the two different EPP reports. The

Latitude Longitude


associated with the
waypoint
would not be properly interpreted either
(also see
11
). START POINT, LINE TO POINT,
and ARC TO POINT should be added to

Lateral Type


variable
.

Lateral T
ype


Enumerated Choice:



OFFSET START



OFFSET REACHED



OFFSET
RETURN TO PARENT PATH INITIATION



OFFSET END



OFFSET



OVERFLY

START POINT



O
VERFLY

LINE TO POINT



OVERFLY

ARC TO POINT

11
.

R
eference
Latitude and Longitude
.
The

variable


Latitude Longitude


in FMS trajectory intent
data
(
5.2.12.2.1

in ARINC 702A
-
3
[5]
) is the waypoint crossing location. For flyby turns, this is the
point on the arc that corresponding to the waypoint

(see
Figure
1
)
,
i.e. the sequence point,
not
the latitude and longitude of the waypoint.
T
his would be what
is
reported in

EPP Data

.
While
the location of named waypoint may b
e known to the ground system, this is not the case for
computed points including
points defining offset path
, as shown in
Figure
2
.
Without
the

Waypoint




≈45°







Waypoint

Offset Start

Offset End

Offset Reached

Offset

Return Initiation

Waypoint

EPP Reported

FMS Computed

Course in


8


reference latitude and latitude, accurate definition of lateral offset path will not be
downlinked.


Reference Latitude
Longitude
” should be added
(
ADSC
-
OR 41 in
[3]
):

EPP Data


Sequence:



Sequence of 1
-
128:




Latitude Longitude (M)




Fix (C2)




Reference Latitude Longitude (
C2
):





Latitude Longitude




Level (M)




Time (M)




Speed (M)




Sequence of 1
-
2:





Vertical T
ype (C2)




Lateral T
ype (C2)




Level Constraint V
alue (C2)




RTA (C2)

Variable
Waypoint

The v
ariable

Waypoint


is used
by the SPR
in two separate
place
s

(
ADSC
-
OR 41 in
[3]
)
. The intended
use
is

shown in
Table
3
.

Table
3

Intended
Us
e

of Variable
Waypoin
t

Define Delineated Waypoint in EPP Request

Report Waypoint in
Projected Profile

EPP delineated


Sequence (1..50):



Waypoint

(M)




Choi ce:





Fix Name






Sequence:







Fix

(M)







Latitude L
ongitude

(O)
1





Latitude Longitude
2





Vertical Type



EPP Tolerance V
alues

(M)

Next Waypoint

(same for
Next+1 Waypoint
)


Sequence:



Waypoint

(M)




Sequence:





Fix
Name






Sequence:







Fix

(M)







Latitude Longitude

(O)
1





Latitude Longitude
2





Vertical Type



Waypoint L
evel
(M)



Waypoint
L
ime
(M)

Note:

1. To be consi stent wi th (CPC
-
ORec
-
5),
Lati tude
L
ongitude

shoul d al ways be provi ded

for thi s opti on.

2. Thi s
is

a poi nt defi ned by
Lati tude Longitude
onl y
that does not have an i denti fi er.

Note:

1. Thi s is the opti onal reference
Lati tude
Longitude.

2. Thi s
i s

the
poi nt on the
path
, whi ch may
not
be

the same as reference
Latitude Longitude
.

12
.

Variable
Waypoint
. The two areas listed in
Table
3

use the same variable name “
Waypoint
” for
different purposes
. As such the structures of the variable in these two uses are quite different
ly
,
thus c
reating an

inconsistent definition. The SPR

should not use the same variable
name

Waypoint


for these two different purposes
.

Delineated waypoint
s

in EPP request should use
explicit
structure
, i.e.
Fix Name
, or
Latitude Longitud
e, or
Vertical Type
. Report waypoint
s

in

9


Projected Profile could use e
ither explicit
structure
, i.e.
Fix Name

and
Latitude Longitud
e and
Vertical Type
, or the variable

Waypoint


defined such

(6.2.1, ADSC
-
OR 41

in
[3]
)
.

EPP Change Event Reporting

EPP change event reporting requirements are summarized in
Table
4

(
ADSC
-
OR 36
in
[3]
)
. Listed in the
table are EPP event t
rigger
s, w
aypoint

at which change
s

are monitored, pre
-
defined

EPP Event Type
s


(Section 6.2.1, ADSC
-
OR 41

in
[3]
)
, and EPP change t
olerance
s that can be defined in the EPP change
event contract.

In the table, redline denotes i
tems not defined in the SPR.

Table
4

EPP Event Trigger and EPP Change Type

EPP Event Trigger

Waypoint

EPP Event Type

Change Tolerance

a) Acti ve waypoi nt sequenced

Acti ve

WAYPOINT SEQUENCED

N/A

b) Waypoi nt/hol di ng pattern i nserted

Speci fi ed

WAYPOINT INSERTED

N/A

c) Waypoi nt/hol di ng pattern del eted

Speci fi ed

WAYPOINT DELETED

N/A

d) Waypoi nt i nto reporti ng wi ndow

Future

NEXT WAYPOINT IN HORIZON

N/A

e) Locati on of waypoi nt changed

Speci fi ed

WAYPOINT CHANGE

EPP Waypoi nt

f) Offset
entered/modi fi ed/del eted

Any

LATERAL OFFSET CHANGE

N/A

g) Al ti tude at waypoi nt changed

Speci fi ed

LEVEL CHANGE

EPP Level

h) ETA at waypoi nt changed

Speci fi ed

ETA CHANGE

EPP Ti me, or

EPP Ti me Percentage

i ) Ai rspeed at waypoi nt changed

Speci fi ed

AIRSPEED
CHANGE

EPP Ai rspeed

j) Modi fi ed/del eted/i nserted


Al ti tude Constrai nt


Speed Constrai nt


Ti me Constrai nt (RTA)

Any


LEVEL CONSTRAINT CHANGE

SPEED CONSTRAINT CHANGE

RTA CONTRAINT CHANGE

N/A

k) RTA achi evabl e/not achi evable changed

Any

RTA STATUS CHANGE


l ) RTA at acti ve waypoi nt mi ssed

Acti ve

RTA MISSED

N/A

13
.

New
EPP Event Type
s
. In

Table
4
, EPP event types shown as redline are not defined in the SPR

(
ADSC
-
OR 41 in
[3]
)
, although the corresponding event triggers are defined
. Specifically,
to
resolve the misconnection between event triggers and event types,
WAYPOINT CHANGE
,
LEVEL
CHANGE
,
AIRSPEED CHANGE
,
and

RTA CONTRAINT CHANGE

should be added

to the
EPP Event
Type

variable (Section 6.2.1, ADSC
-
OR 41

in
[3]
).

The event types are used in the ADS contrac
t to
request the types of events to be monitored by the aircraft. They are also used in the ADS
-
C EPP
change reports to notify the ground which event has triggered the EPP change.

EPP
Event T
ype


Enumerated
Sequence:



WAYPOINT SEQUENCED



WAYPOINT
INSERTED



WAYPOINT DELETED



NEXT WAYPOINT IN HORIZON



WAYPOINT CHANGE


10




LATERAL OFFSET CHANGE



LEVEL CHANGE



ETA CHANGE



AIRSPEED CHANGE



LEVEL CONSTRAINT CHANGE



SPEED CONSTRAINT CHANGE



RTA CONTRAINT CHANGE



RTA STATUS CHANGE



RTA MISSED


Conversely, a new trigger should be added:

l)
RTA at
the
active waypoint
is
missed


(Section
6.1.16.1, ADSC
-
OR 36

in
[3]
)
.

Th
e

RTA MISSED EPP even
t type is defined but there is no
associated definition. The added trigger defines the corresponding trigger.

14
.

EPP Event Type

Request.

In the

EPP Change


request,

EPP Event Type


is specified
in
a
field
independent of
the specification of
EPP waypoints to be monitored
, which is either “
EPP
Continuous


or “
EPP Delineated

(
ADSC
-
OR 41 in
[3]
)
.
The “
EPP Change


requ
est should allow
the ATSU to specify which event types to monitor and which event types no
t

to monitor.
T
his
c
o
uld

avoid excessive EPP event reports
and to

save bandwidth
. Specifically
, if a tolerance for a
waypoint
specifically delineated

is not provided,

the corresponding event should not be
monitored for the delineated waypoint. This requires revisions in SPR Section 6.1.16.1, ADSC
-
OR
38

in
[3]

as follows:


ADSC
-
OR 38

When a tolerance is not specified, the ATSU system shall
use the default
values for these tolerances as shown in Table 6 7
not monitor the corresponding EPP
change event
.

15
.

EPP
Change

Reporting.

The

SPR does not specify which reports should be included in EPP event
ADS
-
C downlink

(6.1.16.1 in
[3]
)
. According to ICAO 9694
[6]
, the required reports include

Basic
Data


and

EPP Data

. All other ADS
-
C event reports include an
Event Indication

to identify the
event triggering the report.
When
multiple EPP change type
s occur

at the same time, only one
EPP chance report should be downlinked.

An

EPP Change Event
s


variable
should be added

to
list all EPP change event types
.
Specifically,
Table 6
-

5:
ADS C Event Types

in Section
6.1.16

Event
Types

should be updated:

6.1.
16

Event Types

(new)ADSC
-
OR 6

The ADS
-
C event types shall operate as shown in Table 6
-
5.

Table 6
-

5: ADS C Event Types

Event Type

Event
Trigger
Description

Event Reports
During Specified
Event Contract

Report Contents

Used in

……

……

……

……

……

Extended
m牯jected m牯晩le
⡅mm⤠䍨ange

See Section
6.1.16.1

See Section
6.1.16.1

Basic

EPP Data

EPP Change Events

4DTRAD,
IER


Additionally, n
ew materials shou
ld be added in Section 6.1.16.1

in
[3]
:


ADSC
-
OR xx

The EPP change event should be reported upon contract acceptance,
when no previous report containing the EPP Data has been sent, and then once each time

11


any EPP change event
occurs. When more than one EPP change event occurs at the same
time, only one EPP Change report should be downlinked, with all event types triggering
the reported listed as variable EPP Change Events.


5

Additional Discussions

There are several
additional Da
ta Comm related issues. Ongoing analyses are
being
performed
to
identify possible solutions. We also reviewed
documents related to the Data Comm SPR
[3]
, namely
ICAO 4444
[4]
, ICAO 9880
[7]
,
ARINC 702

[5]

and found some inconsistencies
. Consistency in terms of
variable definition
, data availability

and required system behavior should be maintained among these
documents.

Some of these issues ca
n be easily addressed, while others may require more fundamental
analysis. Th
is section is intended to share the information with SC
-
214/WG
-
78 related to some of th
ese
issues.

Flight Plan for EPP Request

16
.

Flight Plan for
EPP
Demand
.

More than one flight plans exist in the FMS. At intermediate
synchronization steps, a working flight p
lan
can be

used until it is fully verified and consolidated,
at which time it will be accepted by the air crew as the active flight plan

for e
xecution
. To
support trajectory downlink during trajectory synchronization,
and other potential TBO
applications,
the “
EPP Demand


request (ADSC
-
OR 41 in
[3]
) should include a field to specify
which flight plan the EPP Data
should be
based on. This field is not necessary for Periodic and
Event requests because those EPP reports are normally based
on the active flight plan.

17
.

Turn Center and Turn Radius
. In addition to additional lateral types discussed in Item
10

and the
reference latitude and longitude discussed in Item
11
,
turn information

is also vital for the
ground system to reconstruct the trajectory f
rom downlinked EPP data. As seen
in
Figure
2
,
without the knowledge of turn center and turn radius at the waypoint at the lower right corner,
there is no way for the ground to capture the complex turn.

As a result
, the accuracy of along

track distance calculation may be significantly reduced.
A rough order calculation indicates that
error due to the turn in question would be in the order of 1 radius, which in turn could result

in
an error of several miles. This error would be big enough
to invalidate the solution of arrival
scheduling algorithms
. “
Turn Center


and “
Turn Radius


should be included in the
EPP Data

(
ADSC
-
OR 41 in
[3]
)

to avoid this to happen
.
Additional analyses may be provided in future
plenary meetings to support the decision to include such information in “EPP data”.

Coordination between Different Data Link Applications

18
.

Coordination between
CPDLC Uplink and ADS
-
C EPP Report
.

Traditionally, a data link
application only talks to the same data link application. That is, CPDLC does not talk to ADS
-
C
and vice versa. As described in Section
2
, the trajectory synchronization algorithm uses CPDLC to
uplink flight plan modifications
and downlink assigned route loaded in the FMS,
and the ADS
-
C
EPP report to downlink FMS trajec
tory predictions. Due to data link latency and uncertainty
(especially in the case of VHF Data Link Mode 2), the ADS
-
C EPP report may not reflect the
intended flight
plan modifications uplinked via CPDLC

even when the ADS
-
C EPP is received after
some time
since the CPDLC uplink has been sent out
. This is a serious concern for trajectory
synchronization. This is a more fundamental issue in the data link arena. A mechanism should be
in place to coordinate, or at least to inform what uplink information has bee
n incorporated in
the ADS
-
C EPP report.

A field “CPDLC Reference” can be included in “EPP Data” to report the
latest CPDLC uplink message loaded in the FMS prior to the trajectory prediction is conducted.


12


Variable Definition

19
.

Consistent
Variable Definition in Data Comm SPR
.

In its current form, variable definitions are
provided separately for CPDLC and ADS
-
C

in the SPR
[3]
. For instance,
while the aircraft mass is
defined as “
Aircraft weight
” in CPDLC “Departure Clearance Request Data”, it is defined as
“Gross Mass” in
ADS
-
C “
EPP Data
.

Not only the terminology

is different, the variable value and
resolution are also different. While we recognize different uses of the same parameter in
different situations, an effort should be made to integrate variable definitions. This is especially
important for CPDLC and ADS
-
C as both applications are used by the same users for air
-
ground
data link communication.

Refer
ence

[1]

Klooster, J., Torres S., Earman, D., Castillo
-
Effen, M., Subbu, R., Kammer, L., Chan, D.,
and
Tomlinson, T., "Trajectory Synchronization and Negotiation in

Trajectory Based Operations",
29th
Digital Avionics Systems Conference
, Salt Lake City, October 3
-
7, 2010

[2]

Chan
, D.
, Subbu
, R.
, Castillo
-
Effen,

M.,

Tomlinson,
T.,
Torres,
S.,
Earman,
D.,
French,
S., and
Klooster,
J.,
"Trajectory Synchronization and Negotia
tion: Concepts and Evaluation Environment",
55th ATCA Annual Conference & Exposition,

October 24
-

27, 2010.

[3]

SC
-
214, “Data Communications Safety and Performance Requirements,” DO [xxx], Draft Version I

(Part3:
CPDLC

dated January 20, 2011 and Part 4: ADS
-
C dated January 4, 2011)
, SC
-
214 (Joint with
EUROCAE WG
-
78), RTCA, Washington DC, January 20, 201
1
.

[4]

ICAO, “Procedures for Air Navigation Services


Air Traffic Management (PANS
-
ATM),” Doc 4444,
15th ed, ICAO, Montrea
l, Quebec, Canada, 2007.

[5]

ARINC, “Advanced Flight Management Computer System,” ARINC 702A
-
3, Aeronautical Radio, Inc.,
Annapolis, MD, December 15, 2006.

[6]

ICAO, “Manual of Air Traffic Services Data Link Applications,” Doc 9694, 1st ed, ICAO, Montreal,
Quebec,

Canada, 1999.

[7]

ICAO, “Manual on Detailed Technical Specifications for the Aeronautical Telecommunication
Network (ATN) Using ISO/OSI Standards and Protocols,” Doc 9880, Part I


Air
-
Ground
Applications, 1st ed, ICAO, Montreal, Quebec, Canada, 2010.