1 / 30

Scenarios and FIXM v4.0

February 6, 2014. Scenarios and FIXM v4.0. Stéphane Mondoloni. Overview. Effort is underway to provide starting point for scenarios supporting FIXM v4.0 core and extensions Assumptions Scenarios under development International collaboration  focus on core

said
Download Presentation

Scenarios and FIXM v4.0

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. February 6, 2014 Scenarios and FIXM v4.0 Stéphane Mondoloni

  2. Overview • Effort is underway to provide starting point for scenarios supporting FIXM v4.0 core and extensions • Assumptions • Scenarios under development • International collaboration  focus on core • Investigation into scenarios for extensions  share findings

  3. Assumptions • FIXM v4.0 continues to support FF-ICE Step 1, and the ASBU B1 capabilities • FIXM is a standard for ground-ground exchange • Focus on information needs for 4DT update and exchange • Core items are: • Required for exchange across FIR boundaries or between ATM Service Provider and airline representative (e.g., AOC) • Required across 2 or more ICAO Regions • Extensions are: • Required internal to an ICAO Region in support of a B1 capability • Can be implementation-specific to an ASP or Region

  4. Assumptions (2) • Not a “big-bang” deployment for FF-ICE Step 1. A mixed-mode environment is required and FIXM must integrate into that environment. • ATM service providers may operate with present-day provisions • Airspace Users may operate with present-day flight plans • Airspace Users will have varying levels of CPLDC and ADS-C equipage • FIXM-enabled AUs provide a 4DT pre-departure • Trajectory prediction on the ground-side is required to support: • 4DT generation for AU providing present-day flight plans • 4DT updates due to clearances and uncertainty management • Integration of aircraft-provided data for equipped aircraft (e.g. EPP) • Submission and Management process is independent: • Assume FIXM-enabled participants have access to and can update FIXM information for a relevant flight subject to authorization • ATS Messages  FIXM and FIXMATS Messages required when interfacing with classical ASP • FIXM-enabled participants only communicate with each other using FIXM (i.e., not ATS messages)

  5. Mixed-Modes • Flight operated by AU crossing from one ASP-1 into a second ASP-2: Classic “Classical” ASP1 FIXM-enabled ASP1 All-FIXM “Classical” ASP2 FIXM-enabled ASP2 “Classical” AU FIXM-enabled AU Multiple mixed-mode conditions at one boundary

  6. Pre-Departure 4DT

  7. Pre-departure 4DT provision by AU • FIXM-enabled AU: • 4DT generated by AU • FIXM data & 4DT provided to all relevant FIXM-enabled ASPs • Syntax, logic and eligibility checking • Feedback to AU, AU-generated 4DT revisions • May be provided earlier • No 4DT provided to “classical” ASP. Traditional FPL message provided FIXM also contains all the FPL message information

  8. Pre-departure 4DT generation – “Classical” AU • All ASP receive FPL created by AU • FIXM-enabled ASPs create that portion of a 4DT within their airspace • FIXM-based automation coordination applied to obtain a consistent 4DT for the flight • Information used from FPL: • Item 9 – Aircraft Type for performance data • Item 10 – Equipment for eligibility • Item 11 – Departure aerodrome and time for initial condition • Item 15 – Route and initial cruise speed and level. Planned airspeeds and level for profile changes • Item 18 – Other information including EET/ and DLE/ • Additional information: • Aircraft Performance • Adaptation data – aerodromes, procedures, route expansion, constraints, coordination fixes • Time constraints from Flow Management

  9. 4DT generation – “simplest” • Classical AU provides an FPL • ASPs have boundary constraints at the coordination fix • May condition on flight conditions (e.g., destination airport or procedure) • Can sequentially (ASP-to-ASP) develop a 4DT • Minimizes coordination at expense of flight efficiency Boundary Constraint Boundary Constraint Planned step climb From Item 15 Local Constraint Local Constraint ASP-1 ASP-2 ASP-3 ASP-4 ASP-5 All ASPs are FIXM-enabled

  10. 4DT generation – Boundary coordination • Classical AU provides an FPL • ASPs coordinate on crossing conditions • Requires coordination, not strictly sequential development of 4DT • Improves flight efficiency by reducing boundary constraints • Participants should agree on timeliness requirements • Single time constraint, pre-departure shift in departure time C D B A E Planned step climb Local Constraint Local Constraint ASP-1 ASP-2 ASP-3 ASP-4 ASP-5

  11. 4DT Generation – Mixed ASPs • Flight operates through classical ASP, 4DT not used for boundary information downstream, options: • Field 14 data from CPL, EST or ABI (boundary estimate) • Supplement with GUFI for improved correlation with FIXM data • Use of LOAs for flights in transition at boundary • Use of Field 18 EET from AU • Use of FIXM data from upstream ASPs: • Combine with historical • Generate 4DT in ASP-4 (if information known) • Correlate with prior FIXM-enabled ASP times

  12. Pre-departure 4DT Update – AU generated ASP-1 • FIXM-enabled AU receives wind update, wants new route & cruise altitude • Generates update to 4DT with new route and cruise altitude. FIXM-enabled ASPs are provided the update. ASP follow verification (syntax, logic and eligibility) process. • CHG message is generated for classical ASPs with update to Fields 15 and 18 ORG ASP-2 New Route ASP-3 ASP-4 FIXM update FIXM-Enabled ASP ASP-NFX ASP-5 DES CHG FIXM update

  13. Pre-Departure 4DT Update – Classical AU • AU provides CHG message • FIXM-enabled ASPs create new 4DT in similar manner as for mixed ASP situation using updated data • Wish to synchronize 4DT with receipt of input data: • 4DT update is provided with data from CHG message in FIXM format • FIXM-enabled ASPs forward CHG messages after 4DT update in FIXM (ensures downstream FIXM-enabled ASPs can access consistent upstream data) • For all 4DT generation: • May use the negotiating trajectory to exchange and construct end-to-end 4DT • Or may introduce a new 4DT type – a coordinating trajectory

  14. Pre-departure Options • Provision of ranked options supported under present operations (route, level, and maximum delay) at certain times: • Track advisory (ZOA) used in Westbound Pacific Organized Tracks (PACOTS) • Track Advisory (ZAN) Russia Far East (RFE) Tracks • Slot request submissions for BOBCAT system (e.g., Singapore, Bangkok ATFMU) for flights bound for Kabul FIR • Expansion of use with CTOP (available in B1 timeframe) • Core for global AU-ASP harmonization • AU can submit only 1 option – may be required by Departing ASP • In accordance with internal ASP procedures (or agreed between neighboring ASPs), one option emerges to be proposed for the Agreed-to 4DT with downstream ASPs.

  15. Error Conditions • High level, or feedback? Core or extension? • Potential example codes for logic: • Unrecognized route element: ABCXY • Route cannot be connected: airway_name_1 to airway_name_2 • Route, 4DT path mismatch at Point4D or significant point • Example codes for eligibility: • Destination airport ineligible for procedure XYZ1 • Aircraft class ineligible for procedure XYZ1 • VFR flight not eligible through airspace beginning at point4D. • Flight not authorized for special activity airspace SAA_name • Altitude restriction AT OR BELOW FL330 not met at significant point ABCDE • Speed restriction AT OR BELOW 230 KIAS not met at significant point DEFGH • Addition of restrictions not included (but fortuitously met) • Propose: • Agree on a construct included in Core • Allowable values and specific meanings in Extensions

  16. 4DT Updates – In Flight

  17. 4DT Updates • As flight operates, 4DT is updated initially by controlling ASP, to reflect operational circumstances: • The original prediction is subject to uncertainty in inputs such as aircraft performance, a cruise speed that is not precisely followed and wind uncertainty or variation affecting its along-track progress • A flight is not conforming to the clearance corresponding to the Agreed-to 4DT • The flight has been provided a clearance modifying the 4DT. There can be a large range of clearance types including: • Lateral clearances – closed route changes, vectors, open lateral offsets • Altitude and speed clearances including future actions (e.g, “CLIMB TO altitude AT location”) • Provision of a hold • The flight has been provided a clearance to deviate up to a specified number of nautical miles for weather

  18. Surveillance Update Altitude Threshold Surveillance position Predicted position • Thresholds on difference between previously predicted and surveillance trigger update • Thresholds set by controlling ASP – may be a function of various parameters • Downstream ASP may filter the updates – expect adapted for B1 • Effectively a more continual notification process with downstream ASP • Information exchange required for convergence to modified 4DT • Controlling ASP modifies 4DT to the coordinating fix • Discontinuity (with threshold) results in downstream ASP update or triggers coordination Along-track Threshold Downstream ASP

  19. Surveillance Update (2) • Exceeding lateral threshold require ASP-specific lateral re-conformance logic • Coordination required when clearances operate across boundary crossing • Non-conformance to clearance requires controller notification and corrective action Route Next Course Predicted Position Estimated course Present Position Lateral Threshold Downstream ASP

  20. Update due to Clearances • Characteristics to consider: • Closed clearance † • Open clearance • Instantaneous action • Delayed action • Unambiguous delayed action † • Ambiguous delayed action offering flight crew choice • Constraints† • Additional: • Holding • Cleared deviations • Block altitudes and speed ranges • Process to incorporate effect of sequential clearances • Updates affect downstream 4DT and ETA estimates for flow in B1 • Example follows † These clearances result in update to 4DT and associated input

  21. Example – Open Clearance Initiated Now • Process for update not prescribed, example only • Flight receives “FLY HEADING 045” • Even though clearance is not closed, for 4DT construction automation must make some closure assumptions (e.g., VI to CF leg shown) • Note, original route is preserved Path modified by clearance DEF GHI PPOS FBW VI CF TF Route Transition from PPOS to Heading 045 Heading to Course Transition Note: Clearances may be issued as a VM to DF, but precise closure by automation should assume an unambiguous initial leg. This may be implemented in a variety of manners. • 4DT surveillance updates deal with latencies and uncertainty

  22. Example – Update to Assumed Closure of Open Clearances • Automation assumed closure of an open clearance • Automation may have provided a recommended solution • Assumption may not be exact, 4DT update due to: • Non-conformance to assumed path • Closure clearance provided PPOS • Clearance: • PROCEED DIRECT TO DEF DEF • Update 4DT: • New transition from PPOS to unspecified track Previously defined path DF Point to DF Transition

  23. Example - Active versus Pending Lateral Clearances for Updates • Assume only feasible combinations are cleared to a flight • Clearances have a state of “active” or “pending” • Aircraft is executing to any latest active clearance • Pending clearances have yet to occur • A pending clearance becomes active when a specified time, position or altitude event occurs (e.g., AT [time] PROCEED DIRECT TO [positionR]) • An active clearance can be removed when the conditions for the next pending clearance are met • A pending clearance may be used to close: • An active clearance • A pending clearance with a preceding event • Otherwise, a closed path may be obtained through an “assumed” lateral clearance by automation • A flight may only have one active lateral clearance and multiple pending lateral clearances • Receipt of an immediate tactical lateral clearance (i.e., execute now) replaces the active and removes all pending lateral clearances

  24. Example – Cleared to deviate ABC DEF • Flight cleared with allowable path deviation to left of route ABC to DEF • There is an expected delay and additional uncertainty at DEF • 4DT incorporates point range • Impact propagated downstream to 4DT

  25. Clearances across ASP boundaries • Clearances provided across an ASP boundary must be coordinated and will impact the 4DT • Process similar to coordination today with CPL resulting in ACP or a CDN message amending the proposal • Future use of 4DT together with the input data (e.g., route and clearances) • Coordinate through exchange of negotiating (or coordinating) trajectories • Acceptance yields modification to Agreed-to 4DT • In APAC interface, tactical clearances (e.g., HDG, CFL, SPD, DCT, OTD) in TRU message today are not subject to negotiation

  26. 4DT Updates – Use of ADS-C Reports

  27. Incorporating ADS-C Intent Information • Confirm that received ADS-C intent matches clearances provided (e.g., initial 4DTRAD Service description) • If so, aircraft-provided intent may improve 4DT accuracy, methods are not prescribed. Consider: • In the B1 time frame, wind forecast known to flight may not be the most up-to-date information • Variations in altitude and speed profiles are flight-specific and may be better estimated by flight-deck automation • Future clearances may not all be known to flight automation • Tactical, open clearances • Delayed action clearances supplemented with improved aircraft intent • When available, aircraft-provided 4DT may provide initial proposal for downstream 4DT

  28. Example – ADS-C Intent for Downstream 4DT EPP Event triggered ΔETA Uses ground wind model EPP provided Downstream ASP Agreed-to 4DT Incorporates EPP for downstream Incorporates EPP Information ASP-2 ASP-1

  29. Summary

  30. Summary • Initial scenarios being developed for FIXM v4.0 focused on: • Dealing with mixed-mode ASPs • 4DT generation for AU that is not FIXM-enabled • Feedback for 4DT logic and eligibility failure • 4DT Updates: • Surveillance-based update • Incorporation of clearances • Use of ADS-C provided aircraft intent • Sharing of clearances across boundaries • Incorporation of uncertainty estimation • Validate the use of 3.0 Core • Identify v4.0 Core & Extensions, such as: • Expression of clearances & process for sequential clearances • Additional trajectory type (e.g. coordinating) • Framework for feedback

More Related