210 likes | 344 Views
4D data-link applications COTRAC. SC214/ROSA , Brussels 2 nd October 2007 Dragos TONEA. European Organisation for the Safety of Air Navigation. Content. Context. ADAS. 4D Data-link Application COTRAC. Way forward. Context. 2007. 2013/14. 201X. 20XX. TARGET. ENABLER. ENABLER.
E N D
4D data-link applicationsCOTRAC SC214/ROSA,Brussels 2nd October 2007 Dragos TONEA European Organisation for the Safety of Air Navigation
Content Context ADAS 4D Data-link Application COTRAC Way forward
Context 2007 2013/14 201X 20XX TARGET ENABLER ENABLER Final SESAR Package(s) Transition SESAR Package(s) LINK 2000+ Initial CPDLC Initial 4D &TAXI Full 4D EXISTING Message Set & A/G Technology Euro-Segment 3 NEW Messages & Tech Euro-Segment 2 Euro-Segment 1 Definition = SESAR D4 End 2007
ADAS - Advanced Data-link &ASAS EFFICIENT ATM NETWORK Data-link • 4D applications (COTRAC)- • Full D-TAXI- • FIS- • Alerting- ASAS 4D Trajectory Management Concept (SESAR)
“Classic” approach Operational Need Technical Feasibility Economic Viability SESAR Context OSED development Trial & Validate Standardize Certify Commit Implement
Working arrangementsADAS Data-link User Group • Integrate • Operational needs • Air/Ground COM technology constraints and future capabilities • Ground/Ground systems capabilities and plans • Navigation capabilities and forecasts • Goal • Re-use existent capabilities to maximum extent possible • Consolidate requirements – develop OSED • Incorporate constraints/plans from all relevant domains (air/ground) • Provide input to standardization activities • Framework • SESAR Ops Concept
What does SESAR CONOPS require? • Air-Ground Integration- access/use FMS trajectory: COTRAC • CPDLC; ADS-C • Navigation capabilities : RTA function • Ground system support • Ground-ground Automatic trajectory data exchanges for coordination and transfer • Ground system support to evaluate impact on flow control measures • ATCO support tools (“what if” / MTCD) Today 201x TRANSITION 202x VISION
Data-link in support of 4D Trajectory Management Today Transition SESAR ICAO Flight Plan ICAO Future Flight Plan Business Trajectory Basic COTRAC (Level1) (CPDLC&ADS-C) CPDLC: L2K+ baseline Advanced COTRAC(Level2) OLDI standard No TTA (Departure slot) TTA for planning TTA for separation
COTRAC-Common Trajectory Coordination Implementable Scalable 4D Trajectory description ICAO Flight Plan Future Link VDL2/ATN (air-ground) Flight Object OLDI 3.0 (ground-ground)
Basic COTRAC • What? • Support real-time exchanges of 4D trajectories between air-ground • Support achievement of 1 TTA/RTA at destination For Planning Purposes Non Time Critical VDL 2/ATN
Basic COTRACEnvironment Assumptions • Navigation • RTA conformance capability at least as good as 30 seconds (Climb/Cruise/Descent) • Benefits may be impacted on improved NAV performance • Surveillance • Sufficient for the application of 3 and 5 NM separation • Communication • Voice is the primary medium between pilots and ATCO’s • Data link is a medium to be used for non time-critical operations • Ground system • MTCD, Route/level monitoring and STCA assumed • OLDI is assumed implemented however no assumptions yet regarding the messages that have been implemented (derived from the SPR process) • Generic environment • Controlled airspace (A to E) • Assumed that no new airspace design methodology is required • High density traffic • Airborne equipage • Does not assume 100% equipage of systems that support COTRAC in the airspace
Air/Ground Working Methods (1/2)The Pillars of COTRAC1 Initial RTA Establishment Pilot Initiated Changes ATCO Initiated Changes Negotiation Ground Unit Coordination GND: 4D Trajectory ‘sync’ Failure Modes
DUG/4 Discussion Initial RTA Establishment Pilot Initiated Changes ATCO Initiated Changes Negotiation Ground Unit Coordination GND: 4D Trajectory ‘sync’ Failure Modes
DUG4 discussion • Negotiation • Core element that sets COTRAC1 apart from ACL • Can this be done with the existing CPDLC message set? • Previous work relied on freetext. • What data does the airborne need to negotiate with the ground • Do we want the airborne to negotiate with the ground? • What data does the ground need to negotiate with the airborne? • How can we limit the negotiation process – do we limit it? ATCO Pilot
What does 4D require? Data-link: CPDLC • To support agreement/revision of RBT • Uplink of constraints (e.g. route including taxi route, altitude, time, and associated performance requirements) • Uplink of requests (e.g. time estimate at arrival to support AMAN operation, runway exit) • Uplink of clearances (e.g. for a segment of RBT) • Downlink of requests (for push back, taxi, take off clearances, etc) • Downlink of aircraft preferences (e.g. STAR, ETA or ETA min/max, runway exit)
Data-link: ADS-C • Support automatic downlink of airborne PT to improve ground prediction • uplink of requests for "on event based" downlink of PT (with required time interval and delta of current PT versus previously downlinked PT to trigger automatic downlink) • downlink of PT (initial PT constituting the RBT at the gate or in flight after a revision and updated PT in case of delta versus previously downlinked PT)
4D concept (2015)-considerations • Facts • Aircraft fleet: Mixed equipage • Avionics upgrade is expensive • Multiple upgrades in short time span- unlikely • Ground systems: mixed capabilities • Ground systems lifespan is minimum 10 yrs • Several major ANSP have already specified their requirements for the next systems • No route exchange for coordination and transfer (ATSU to ATSU) • IR does not ask for route exchange • Future ground system standards (WG59) – planned for 2009 • More advanced features are not mandatory • CFMU capabilities – probably evolve • Link2000+ CPDLC baseline (both air and ground) • Disregarding Pilot/ATCO’s requirements/objections –proved recipe for delays
What do we have? • CPDLC • Existing CPDLC supporting ATC applications via ATN for continental areas (Link 2000+ baseline) • ADS-C • Existing: only for oceanic fleet (via ACARS), not for continental fleet • Ground system support • MTCD en-route (limited “what if” functionalities) • Co-ordination and transfer (ATC to ATC): Limited OLDI implementation (does not include route exchange) • CFMU • IFPS (e.g. ACH, AFP message) • ETFMS (e.g. FUM message)
Way forward • Complete COTRAC L1 OSED • Validate • Simulations are useful but… • Operational trial is needed (PETAL model) • Support for standardization activities • Identify additional requirements (if any) for • Airborne • Ground systems • Implementation packaging: air & ground together!! ADAS DUG #6 – 20-21 February 2008, Brussels
Thank you dragos.tonea@eurocontrol.int