1 / 19

FIXM 3.0 Data Dictionary Core Trajectory Data Elements Identification

FIXM 3.0 Data Dictionary Core Trajectory Data Elements Identification. August 21, 2013 Trajectory Modeling Group. Participants. Discussion Outline. Foundation and Level Setting Core Trajectory Definition Assumptions Trajectory Types Considered in Analysis

kert
Download Presentation

FIXM 3.0 Data Dictionary Core Trajectory Data Elements Identification

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. FIXM 3.0 Data DictionaryCore Trajectory Data Elements Identification August 21, 2013 Trajectory Modeling Group

  2. Participants

  3. 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

  4. 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

  5. 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

  6. 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

  7. 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 integrityof 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

  8. 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

  9. 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

  10. 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.

  11. 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

  12. 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

  13. 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

  14. 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

  15. Flight Script Trajectory Options Trajectory Options Trial Trajectory Negotiation Trajectory Historical Trajectory Pending Trajectory Trajectory Input Data Trajectory Input Data Dealing with Multiple Trajectories TBD Trajectory Input Data Trajectory Input Data Trajectory Input Data Trajectory Options Flight Script Flight Script Intended Trajectory 4DT Trajectory Input Data 4DT 4DT Trajectory Input Data Flight Script Flight Script Flight Script Flight Script TOP TOP • 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) 4DT 4DT 4DT 4DT TOP 4DT Flight Data Other Flight Data

  16. 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

  17. 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

  18. 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

  19. Summary of Verification Analysis FF-ICE/1 and ASBU-Block 1(Presented by MITRE)

More Related