Transcript Trajectory Core Elements TBO briefout_draftVer02
FIXM 3.0 Data Dictionary Core Trajectory Data Elements Identification
August 21, 2013 Trajectory Modeling Group
1
Bob Humbertson Dawn McConkey Stephane Mondoloni Dan Kirk Doug Sweet Bill Cotton Karl Grundmann Richard Heinrich Steve Koczo Dave Nakamura Buzz Campo Laurence Mutuel Mike Watson
Participants
Booz Allen Hamilton Digitalibiz, Inc.
MITRE MITRE Saab Sensis Aviation Management Associates Aviation Management Associates Rockwell Collins Rockwell Collins Boeing Metron Aviation THALES THALES [email protected]
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 Flight Script 4DT Other Flight Data Pending Trajectory Trajectory Input Data Flight Script 4DT Trial Trajectory Trajectory Input Data Flight Script 4DT Trajectory Options Trajectory Input Data Input Data Input Data Flight Script Flight Script 4DT TOP Historical 4DT Negotiation 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