FIXM 3.0 Data Dictionary
Core Trajectory Data Elements
Identification
August 21, 2013
Trajectory Modeling Group
1
Participants
Bob Humbertson
Booz Allen Hamilton
Humbertson_Robert@BAH.com
Dawn McConkey
Digitalibiz, Inc.
dmcconkey@digitalibiz.com
Stephane Mondoloni
MITRE
smondoloni@mitre.org
Dan Kirk
MITRE
dkirk@mitre.org
Doug Sweet
Saab Sensis
Douglas.sweet@saabsensis.com
Bill Cotton
Aviation Management
Associates
bcotton@avmgt.com
Karl Grundmann
Aviation Management
Associates
kgrundmann@avmgt.com
Richard Heinrich
Rockwell Collins
reheinri@rockwellcollins.com
Steve Koczo
Rockwell Collins
skoczo@rockwellcollins.com
Dave Nakamura
Boeing
Dave.Nakamura@boeing.com
Buzz Campo
Metron Aviation
Buzz.camp@metronaviation.com
THALES
Laurence.mutuel@us.thalesgroup.co
m
THALES
Mike.Watson@thalesgroup.com
Laurence Mutuel
Mike Watson
2
Discussion Outline
•
•
•
•
•
Foundation and Level Setting
Core Trajectory Definition
Assumptions
Trajectory Types Considered in Analysis
Development of initial list of information items
 Team Approach
 Relationship to other documents & standards
 High-level description of trajectory items
 Future Work
• Summary of Preliminary Analysis
3
Setting the Foundation
• ICAO – FPLSG/ATMRPP
FPL 2012 implemented by November 2012
 FF-ICE Concept endorsed at AN/Conf-12
 FIXM under development
• V1.0 Aug 2012 (FPL 2012 + NAS FPL + GUFI + ED-133
initial elements)
• V1.1 Dec 2012 (+Hazardous cargo)
• V2.0 August 2013
• V3.0 Aug 30, 2013 kickoff meeting (initial 4DT elements
identified for inclusion)
• Element discussion with FIXM TRM late Sept. 2013
• V3.0 Scheduled for Release August 2014

4
Setting the Foundation (2)
• ATMRPP need first cut now on 4DT information items


Started with a long list of items for consideration
Applied Scenarios
• Future work will require more detailed scenarios and use cases
• Developed a set of assumptions and definitions that
provided scope for developing the FIXM v.3.0 Core
Trajectory Data Elements



Core vs. Extensions
Core Trajectory Definition
Purpose/Value of Core
5
Setting the Foundation (3)
• Developed initial list of information /compatibility items








Approach and assumptions
Relationship to other documents & standards
Trajectory Prediction (TP) Structure & Classification of Items
High-level description of trajectory items
Evaluation of consistence w/ info exchange with flight deck in the
future
Evaluation of other potential information or data sources
Initial set of 4D Trajectory Data Link (4DTRAD) expected in
Block 1
Future Work
6
Core trajectory definition
• Provides the user with a common, up-to-date 4D trajectory shared
among users throughout the life cycle of the flight (assumed from
pre-departure to arrival gate)
• A measure of the accuracy and integrity of the trajectory prediction
data at a specific location will vary as the flight progresses and will
be included FIXM v.3.0

Agreed in principal that accuracy / integrity can improve performance of
downstream prediction for TFM; it is not an accuracy of the actual flight
• Updates to the trajectory prediction are provided as the flight
progresses. Updates start from the current location of the flight.
Updates will be periodic and / or the result of an event
• Sources for trajectory data will vary depending on where the flight is
in its lifecycle and availability of data
7
What benefit does the Core provide?
• Provides common information set that characterizes the flight’s
trajectory


Common representation of the flight for ground based users
(ANSPs, AOCs, etc.) from pre-departure to arrival at the destination gate.
In today’s operation, there is not a common view of a flight throughout the flight’s
life cycle
• FIXM Trajectory updates can be made for some classes of users
(ANSP, dispatch, pilot, etc.)

Rules of exposure, bot internal and external require further analysis
8
Core vs Extension
Direct from FIXM Primer . . . .
• The core and extension model is commonly used in industry to control and
direct the development and growth of complex systems, when users of the
system want to pick and choose the features that are important for their
application, without being burdened by all possible features of the system ..
• Systems that wish to use FIXM features must adopt the core features, but
may also choose some subset of extension features to accomplish their
tasks.
• The extension architecture also helps to separate data elements that fill the
same role, but differ in implementation, so that the data model does not have
to contain multiple, contradictory implementations of the same data item.
• The FIXM Extension packages define attributes of the flight that are not used
universally, but are used by a subset of the flight control applications.

Note: we believe the use of “Flight control applications” is confusing. It sounds as if
FIXM is used on the flight deck
9
Assumptions
• Our analysis indicated the need for relationships with other data and
highlighted some items required to make the 4DT work
• The group focused on the 4DT itself
•
•
Analysis and scenarios indicated the need for 9 Core Data Elements, and 21
TCP types
We intend to borrow definitions from elsewhere (FIXM DD, FO Dictionary,
Concepts, etc.). Where practical
• Extensions need dealt with under a separate task and must
accommodate variations in concepts.
10
Assumptions (1)
• FIXM is a data exchange standard for ground to ground
communication
• Elements can move into Core as time progresses

Requires governance and configuration management
• 4DT Elements identified may correspond to data available from the
aircraft/AOC/FOC, even though they may not be the source

By explicitly eliminating our consideration of direct air to ground com does not
interfere with existing efforts to define that com link. We did not try to include
explicit ground to air com (it should be included if the data can be made available
to a ground system)
• FIXM 3.0



4DT is based on support for ICAO ASBU Block 1 Capabilities (2018 – 2023)
Not all are exclusively flow management
None deal with separation
11
Assumptions (2)
• Alignment of Core 4DT Elements to FF-ICE/1 / Global Operational
Concept (ICAO Doc 9854); FICE/1.

Targeting FIXM 3.0 to support FF-ICE/1; however, due to schedule alignment it
may be that FIXM 3.0 will need to be modified to fully support the FF-ICE/1
provisions defined by ICAO. As a result, ICAO is not committed to using FIXM
3.0 for FF-ICE/1.
• Some elements already in FIXM require discussion to ensure
inclusion of 4DT.


If currently identified in FIXM, we call the Element out, but do not repeat it
Some current definitions may need refinement to ensure incorporation of 4DT
Concepts
• FIXM Data Dictionary and Models contain many elements that
further break-down identified 4DT Core (Boundary, Route, Altitude,
Point, etc.)

Some Terminology differences may need reconciled
12
Assumptions (3)
• Difference in concepts will continue to exist and will be handled
through Extensions or other means in the Standard
• Aircraft data can be passed from AOC/FOC




Some ANSPs may have the capability to integrate direct from aircraft (Extended
Projected Profile {EPP} ADS-C messages)
The B1-TBO module indicates that initial 4DTRAD will be available in this
timeframe. In support of this, the 4DT for B1-FICE is being developed to enable
any downlinked trajectory information to be integrated into the 4DT
It is not expected that the AOC/FOC will provide aircraft performance
data. However, some data provided by the AOC/FOC could be used to better
tailor ground-based aircraft performance models
The relationship to the route, the need for other items that are not the 4DT (for
example, aircraft type) to do prediction can be handled with the FIXM team,
without the need to involve our group that is defining the trajectory
13
Assumptions (4)
• The group did not consider specific FIXM trajectory needs for
UAS/RPA/RPAS (work in progress by other groups)







UAS may use the 4DT elements being defined by this group as applicable.
File and Fly levels of certification and airworthiness have been approved
AOC/FOC is assumed to be the same as a general aviation/business jet
Military/Users may end up with Extensions much as Europe is planning
UAS – Unmanned Aircraft System
RPA – Remotely Piloted Aircraft
RPAS – Remotely Piloted Aircraft System
14
Dealing with Multiple Trajectories
• There can be many trajectories associated with one flight
• We are proposing (for v3.0) only including:



Intended
Negotiation
Trajectory Options
• Some of these are temporary (e.g., options are pre-departure)
Flight Data
Intended
Trajectory
Trajectory
Input Data
Pending Trajectory
Trajectory
Input Data
Flight Script
4DT
Flight Script
Trial Trajectory
4DT
Trajectory
Input Data
Flight Script
Other Flight Data
4DT
Trajectory Options
Trajectory Options
Trajectory Options
Trajectory
Trajectory
Input
Data
Trajectory
Input Data
Input Data
Flight Script
Flight Script
Flight Script
4DT
4DT
4DT
TOP
TOP
TOP
Historical
Trajectory
TBD
4DT
Negotiation
Trajectory
Trajectory
Input Data
Flight Script
4DT
Description of Items Identified
• To be included in FIXM Data Dictionary, each identified element
must include at a minimum





Name
Definition
Has Parts
Is Part of
Range (if applicable)
• Figures of merit (FOM) have not been completed (e.g., accuracy,
performance) but will be required. However, they are not required for
FIXM 3.0 as we can define 4DT items without the FOM
16
Summary: Teams Approach
Considered
• Consistency with the NAS Enterprise Architecture and Scenarios
identified by the RTCA Trajectory Operations Working Group
• Consistency with the EUROCAE ED-133 Flight Object
Interoperability Specification
• Ability to incorporate information received from the ADS-C Extended
Projected Profile (EPP)
• Ability to represent lateral profiles (e.g., expressed as ARINC 424-19
leg types)
• Backward compatibility and support for mixed equipage operations
by ensuring that present-day data ICAO PANS-4444 Flight Plans
can be represented
17
Future Work
• Fully define the Core Elements selected
• Identify trajectory items necessary to be exchanged with operators.

These should be standardized within FIXM
• Identify surface information items, including those that impact
departure time accuracy and those necessary for exchange between
ANSPs or between ANSPs and aircraft operators
• Identify necessary 4DT Extensions
• Ensure definitions of elements from previous FIXM are not
significantly modified by the 4DT context
18
Summary of Verification Analysis
FF-ICE/1 and ASBU-Block 1
(Presented by MITRE)
19