, Specification Document Specification Document Document Ref: SPEC/TRSA26-2002/WP8/EMAN_PROTO/001/RTC-owe Issue date: 29th January 2004 Document Change Log Release Author Date of the release Description of the release 1.0 EUROCONT ROL 1.1 RTC (Steve Owen) 1.2 RTC (Steve Owen) 2.0 RTC (Steve Owen) 2.1 RTC (Steve Owen) 3.0 RTC (Steve Owen) 3.1 RTC (Steve Owen) 20/08/2003 Initial Version 29/8/2003 Revised with comments from IAA/Christie Costello and EEC/Peter Martin 5/09/2003 Revised with comments from IAA/Christie Costello and EEC/Peter Martin 17/10/2003 New version after feedback from interested parties. 27/10/203 Clarification of explanations for the diagrams 7/1/2004 Re-orientation for presentation rather than experiment and changes for alternate routes 12/1/2004 Added changes from IAA/Christies Costello All All All 6.2 All 2,3,5 Modifications (sections affected and relevant information) Document distribution to/cc Name Role to EHQ/Seppo Kauppinen ASA Programme Manager to EEC/Peter Martin EVP EMAN Project Lead to IAA/Christie Costello Operational Advisor, author of OCU to EEC/Darren Smith ERIS edep Platform Project Lead cc EEC/Colin MECKIFF Head of SSP Business Area cc EEC/Andy Barff Operational Deputy Head of SSP 1
Table of contents 1. INTRODUCTION... 3 1.1 PURPOSE... 3 1.2 EMAN DOCUMENTATION... 3 1.3 CHANGES FROM VERSION 2 OF THIS DOCUMENT... 3 1.4 INTENDED AUDIENCE... 3 1.5 GLOSSARY... 4 2. SCOPE... 5 2.1 OBJECTIVES... 5 3. PROPOSED PRESENTATION... 6 3.1 OPERATIONAL ENVIRONMENT... 6 3.2 FOCUS OF THE PRESENTATION... 7 3.3 LIMITATIONS AND ASSUMPTIONS... 7 4. SOFTWARE DEVELOPMENT... 9 4.1 EXISTING SOFTWARE...9 4.2 SOFTWARE TO DEVELOP... 9 4.3 PHASES OF DEVELOPMENT... 9 4.4 EDEP LIMITATIONS... 10 5. PRESENTATION SCENARIO... 11 5.1 AMAN SEQUENCE... 11 5.2 EMAN DEFAULT DELAY SHARING... 11 5.3 EMAN DELAY ANALYSIS... 11 5.4 EMAN DELAY ABSORPTION... 12 5.5 THE ROLES OF THE PC AND TC... 12 6. APPENDIX A... 13 6.1 SOME ILLUSTRATIVE EXAMPLES OF THE TRAFFIC PIS ON AN AIRCRAFT FLIGHT LEG... 13 6.2 SCREEN SHOTS OF PROPOSED CONTROLLER INTERFACE... 15 2
1. INTRODUCTION 1.1 Purpose This document describes the specification of a software prototype to be used for exploring the concept of an EMAN (En-Route Manager) tool that helps an ACC Planning Controller manage the en-route portion of a flight. The work is part of a wider EVP (European ATM Validation Platform) study into several such groundbased sequencing tools (including DMAN and AMAN) and EMAN is required to provide assistance such that constraints related to departure time, arrival time, Sector traffic, and collision avoidance may co-exist without causing excessive workload for the controller. 1.2 EMAN Documentation The EMAN prototype takes account of several documents: 1. An Operational Vision Document: Automated Support to the ATS Program (EEC/Barry Kirwan, EHQ/Seppo Kauppinen) 2. Initial EMAN Operational Concept of Use (NATS, UK) 3. Thoughts on Multi-Sector Concept and EMAN (EHQ/Seppo Kauppinen) 4. EMAN Use Case and Scenario Development - Final Report (Qinetiq, Malvern) 5. EN-Route Manager - Proposal for EMAN Prototyping Exercise (EEC/Peter Martin) 6. EN-Route Manager - Concept of Operations Proposal (IAA/Christie Costello) In particular the prototype should directly address documents 5 and 6, which may be considered as the Requirements documents. These requirements are largely formulated to address the EMAN concept Level 2 of document 4. 1.3 Changes from Version 2 of this Document It was decided that it was too early to have an experiment with testable hypotheses showing and measuring the improvement that could be obtained with the EMAN tool. Instead, the same airspace environment has been maintained, but the objective has been modified to be a presentation of the EMAN ideas which help a Planning Controller to plan further down-stream, taking into consideration the AMAN constraints and downstream traffic. (See the section on objectives lower down) Also, a means by which a Planning Controller can choose an alternate route for an aircraft has been added. 1.4 Intended audience ASA Programme Manager EVP EMAN project manager EMAN OCU author Anyone participating in the development of the EMAN concept. 3
1.5 Glossary AMAN ATC ATM ASA ATS COP CORA DMAN EATMP EDEP EEC EHQ EMAN ETFMS EVP HMI IAA IAF MTCD OCU PC PI RTC RTO SSP TAW TBD TTL(G) XFL Arrival Manager Air Traffic Control Air Traffic Management Automated Support to ATC Air Traffic Services Co-ordination Point Conflict Resolution Assistant Departure Manager European Air Traffic Management Programme Early Demonstration & Evaluation Platform Eurocontrol Experimental Centre Eurocontrol Headquarters En-Route Manager Enhanced Tactical Flow Management System EATMP Validation Project Human-Machine Interface Irish Aviation Administration Initial Approach Fix Medium Term Conflict Detection Operational Concept of Use (Concept of Operations Proposal) Planning Controller Point of Interest Real Time Consultants Required Time Over Sector, Safety & Productivity Traffic Analysis Window To Be Defined Time to Lose (Gain) Exit Flight Level 4
2. SCOPE The EMAN is potentially quite complex, communicating with many other tools in order to arrive at the best en-route planning for the aircraft (AMAN, DMAN, ETFMS, CORA, MTCD, etc.). The first version of the prototype will concentrate on a simple subset of the problem domain: The TTL/TTG calculated by AMAN which relates to the time constraint (RTO) at the Initial Approach Fix. The sharing out of delay along the route to achieve the above RTO (resulting in Sector exit-point EMAN RTO constraints along the route) The visualisation of down-stream traffic congestion problems associated with altering the current Sector's exit point time and flight-level (and possibly alternative route segments) in order to achieve the EMAN RTO constraints. The (look-ahead) visualisation of improvements to traffic at critical points along the trajectory achieved by using standard ATC manoeuvres. 2.1 Objectives The objective of this presentation is to show whether the EMAN concept has a place in bridging the gap between strategic planning, in which an aircraft has long term commitments (RTO constraints, sector load/complexity, etc.), and tactical planning, in which a controller has to manage the aircraft's long term commitments with predicted difficulties in the subject and adjacent Sectors. This prototype, in particular, will concentrate on how ACC controllers can control/re-route aircraft to respect the AMAN arrival constraint at the IAF while minimising workload for down-stream Sectors. This will be facilitated by tools that show traffic density/complexity at important down-stream crossing points, and 'What- If' tools that help the controller to determine the optimum Sector exit conditions that balance the down-stream traffic problems against the AMAN's requirements. The benefit of the proposed EMAN should be that the PC will plan over a longer horizon, taking into account traffic congestion and thereby reducing workload for own Sector and down-stream PCs and TCs. 5
3. PROPOSED PRESENTATION 3.1 Operational Environment 3.1.1 There will be several En-Route Sectors based on the 6-States airspace, with overflights, arrivals and departures at specific airports in the area of interest that result in traffic crossing points that need to be monitored by the Planning Controllers. In this document the term Traffic PIs (Traffic Points of Interest) will be used for these crossing points. 3.1.2 For each destination airport there will be an APP CWP position with an AMAN Landing List window to examine arrival traffic and modify runway landing spacing. 3.1.3 Each aircraft destined for an AMAN-controlled runway will be attributed a landing time and subsequently Sector-exit advisory times along its route (using delay sharing where necessary). 3.1.4 The Traffic PIs will be shown on the Flight Leg and be colour-coded to indicate the traffic load/complexity at those points. Initially this will be based simply on the number of aircraft passing through the PIs at the same altitude and time window as the selected aircraft. This could evolve to use ETFMS data to determine complexity as a function of: number of aircraft; Sector; time of day; etc. See Appendix A for diagrams of this concept. 3.1.5 A planning controller may also open up the Exit Flight Level menu. Each flight-level button will incorporate a colour-coded traffic button (as on the Flight Leg) showing the worst-case load/complexity at the down-stream Traffic PIs. Right-pressing the mouse over a flight-level's traffic button in the menu will modify the down-stream Traffic PIs on the Flight Leg to show the situation that would occur if the XFL was modified to the corresponding flight-level. See Appendix A for diagrams of this concept. 3.1.6 Left-pressing the mouse over one of the traffic buttons in the Exit Flight Level menu will also show the traffic situation at the corresponding flight-level (as above), but in addition will bring up a Traffic Analysis Window (TAW) on the Flight Leg Traffic PIs showing a time-sorted list of the other aircraft that pass through those crossing points. Each entry in the TAW will show the callsign and ETO of the associated aircraft. See Appendix A for diagrams of this concept. Note: The use of the left mouse button for the purpose of obtaining information contravenes the current philosophy on CWP HMI interaction. This has been ignored for the purposes of the presentation since only concepts are being presented, not implementations. 3.1.7 At the bottom of the Exit Flight Level menu will be the proposed time at exit from the current Sector. Arrows will appear on either side of this time to increase or decrease the value. This will allow the controller to look at what will happen if he/she decides to absorb time for a down-stream AMAN constraint. By changing (probing) this time (which does not modify the trajectory) the menu's flight-level traffic buttons and Flight Leg Traffic PIs are all updated to show the new load/complexity situation corresponding to the proposed Sector exit time. The controller may visualise the modified time separation at a Traffic PI for the aircraft by looking in the TAW, which should aid a controller to sequence an aircraft through a Traffic PI while at the same time contributing to the requirements of the AMAN tool. See Appendix A for diagrams of this concept. 3.1.8 Also at the bottom of the Exit Flight Level menu, the PC may probe a set of pre-defined alternate routes. The alternate route's flight leg will contain new Traffic PIs that enable the traffic through the new critical points to be monitored. The menu's flight-level traffic buttons are also updated to reflect the worstcase traffic load/complexity at all the flight-levels along the alternate route. See Appendix A for diagrams of this concept. 6
3.1.9 The PC will plan the exit conditions at the exit COP, taking into consideration the traffic at the downstream PIs. At a later planning stage the PC will use MTCD to plan the desired Sector exit conditions. The TC will then use the system support to tactically and safely achieve the planned exit conditions while ensuring AMAN constraint conformance. 3.1.10 The initial delay to be absorbed by each Sector will be based on Agreements in the airspace resources file. 3.2 Focus of the Presentation For a typical traffic sample in the 6-states upper airspace environment, the EMAN hypotheses to be discussed are: 3.2.1 Using down-stream traffic data at strategic crossing points allows a PC to make long-horizon trajectory changes that reduce down-stream and up-stream tactical intervention. 3.2.2 Absorbing the AMAN-required flight delay by sequencing an aircraft through the en-route Sector COPs, while taking into account down-stream traffic congestion, reduces the overall tactical intervention relating to that flight. 3.2.3 It is possible to absorb a delay of 10 minutes in an acceptable manner using delay-sharing along the en-route portion of a flight, rather than using holding at the IAF 1. 3.3 Limitations and Assumptions 3.3.1 The Traffic Analysis Window will initially be a simple window that shows a column of time-sorted aircraft passing through the associated Traffic PI at the same level as the subject aircraft. The subject aircraft is highlighted to show its position in the sequence. This could evolve to take into account ETFMS data for traffic limit values at those points at various times of the day. It could also become more abstract so that its presentation becomes less callsign-oriented but more density/complexity/workload oriented. This differs from the TLS (Traffic Load Smoother) approach in that the data is shown for specific points in specific Sectors; this allows the density data to be put into the context of its environment using external tools such as ETFMS (or its workload extensions). 3.3.2 Initially, up-stream co-ordination is not considered. One of the hypotheses is to see if such coordination is necessary. If the up-stream PC can reduce significantly the number of traffic problems for following Sectors then aircraft should always be delivered to Sector entry COPs in such a way that the new PC has only to address the required delay absorption specified by EMAN. If up-stream co-ordination is deemed necessary then it may be introduced in a later prototype. 3.3.3 CORA is not included in the presentation. It could, however, be envisaged that a CORA-style tool be used to propose alternative sections of trajectory that help resolve well-known traffic problems in particular regions of airspace (groups of Sectors or Meta-Sectors). These trajectory sections could have the effect of 1 This figure of 10 minutes is thought to be representative of the maximum delay that this type of control should need to absorb if all other strategic methods of control are functioning normally. 7
moving the flight path from one Traffic PI to another. A PC could then cycle through the proposed alternative routes and examine the traffic at the PIs to decide which solution works best. 3.3.4 DMAN is not present, so aircraft take-off time may not be modified. The system will, however, make the aircraft trajectories available in advance of the aircraft departure time to facilitate EMAN planning. It could be expected that if AMAN issues constraints which result in excessive en-route delays then the DMAN would be told to hold aircraft on the ground. Since this is not possible in this prototype then it is necessary to try to ensure that the traffic does not incur these excessive delays in order that the EMAN presentations are performed in reasonable conditions. 3.3.5 Suggestions have been made that EMAN should take multiple sequencing constraints (e.g. from DMAN and AMAN) and use aircraft performance and cost functions (based on the manoeuvres necessary to absorb the implied delays required) to prioritise the aircraft at crossing points. This has not been taken into account in the current prototype because: Aircraft performance is only useful when the delay is absorbed using speed changes; the delay that can be absorbed using speed changes at the current flight-level is small compared to other solutions, such as orbits or re-routing, and flight-level changes (with a subsequent speed change) The point at which delay-absorption manoeuvres are applied to an aircraft, and the kind of manoeuvres used, will probably vary greatly as a function of the current complexity of the airspace. In particular, for two different situations a PC may absorb the delay before or after an important crossing point. For these reasons it is proposed that the prototype should: make a maximum effort to highlight the current down-stream traffic problems provide tools to easily view down-stream traffic improvements gained from standard ATC procedures while respecting, where possible, the imposed AMAN advisories. 8
4. SOFTWARE DEVELOPMENT 4.1 Existing Software 4.1.1 The edep platform. This platform will be configured to show 3-4 en-route CWP positions and a TMA APP position for each airport at which aircraft are landing. 4.1.2 The AMAN already developed under the EVP project, although the delay-sharing functionality will be moved to EMAN. 4.2 Software to develop 4.2.1 The EMAN server which manages the delay-sharing and the Traffic PIs. 4.2.2 The Traffic Analysis Window (TAW) which shows traffic at pre-defined Traffic PIs. 4.2.3 What-if capability for testing new Sector exit conditions. This would allow a PC to view down-stream traffic problems (not exact conflict situations) for different exit flight-levels and times. 4.2.4 What-if capability for testing route changes. This would allow a PC to view down-stream traffic problems (not exact conflict situations) for pre-configured alternative re-routings. 4.2.5 The 6-states traffic samples. 4.2.6 The Configuration data for Flow Traffic PIs and delay absorption capacity. 4.3 Phases of Development 4.3.1 Phase 1. In order to have the quickest available prototype then the following functionality will be needed: EMAN server Traffic Analysis Window with Traffic Points of Interest on the Flight Leg What-If capability for Sector exit time and flight-level This phase has been completed on schedule. 4.3.2 Phase 2 In order to test the hypotheses using a completed prototype then the following items are needed in addition to Phase 1. 9
The 6-states traffic sample. The Configuration data for Flow Traffic PIs and delay absorption capacity. 4.3.3 Phase 1+ If alternative routes are to be considered for alleviating traffic problems by passing through other Traffic PIs then the following items are needed: What-If capability for testing route changes. Using pre-configured alternative route sections, the Traffic Analysis Window would be used to examine the best of a set of solutions for passing through a region of airspace that is known to present management problems. 4.4 edep Limitations The prototype is being created in a fairly short timescale. For this reason it is preferable to carefully consider any new functionality required in the underlying platform. Current limitations of the platform are: 4.4.1 Dynamic take-off times. It is not currently possible to negotiate the take-off time. If basic DMAN functionality were required then it would be necessary to add this functionality. This would be a small change. 4.4.2 Simple Performance Model. The performance model is not very accurate over the whole performance envelope with varying aircraft mass. Also speed changes are considered to occur instantaneously, and accelerations/decelerations do not result in energy-sharing effects in the height-rate of the aircraft. If experiments were required that examined special cases whereby aircraft performance was an important factor then the aircraft model might prove insufficient. This would be a big change. 4.4.3 Holding patterns. edep does not implement holding patterns. If experiments were performed in which the time spent by aircraft in holding patterns was important then it would be necessary to add this functionality. This is a change for which the implications have not been evaluated. 4.4.4 Datalink. edep does not have Datalink. This is currently being developed in edep. 10
5. PRESENTATION SCENARIO In order to discuss the EMAN hypotheses a typical scenario will be: 5.1 AMAN Sequence 5.1.1 The AMAN will calculate the runway occupancy list for all the aircraft landing at that airport. This will result in a runway schedule, and each aircraft will be given an RTO at the IAF. 5.2 EMAN Default Delay Sharing 5.2.1 EMAN will use the TTL/TTG and the delay-sharing Agreements for each route through each Sector in order to provide a Sector exit RTO for each aircraft being scheduled by AMAN. 5.3 EMAN Delay Analysis 5.3.1 Before an aircraft enters the Sector, a PC will be able to visualise traffic density/congestion at the down-stream Traffic PIs (colour-coded for load/complexity) shown on the aircraft Flight Leg. By opening the Exit Flight Level menu for an aircraft, the controller may: See the worst-case down-stream traffic load at each flight-level in the menu, represented by traffic load buttons next to the flight-level buttons (colour-coded as on the Flight Leg). Right-press the mouse over a flight-level's traffic load button in order to refresh the Flight Leg Traffic PIs to show the down-stream traffic at the associated flight-level. Left-press the mouse over a flight-level's traffic load button to show the down-stream traffic at each Traffic PI at the associated flight-level (as above) and open up the Traffic Analysis Windows at the down-stream PIs to see the exact sequence of crossing traffic at that level. The subject aircraft is shown highlighted in that sequence. Modify the Sector exit time to see the result of following an AMAN advisory. When the time is modified all the menu's traffic load buttons and the Flight Leg Traffic PIs are updated to show the load at the new exit conditions, and the traffic sequence in the Traffic Analysis Windows are updated to show the new sequence. Scroll through pre-defined alternate routes. For each route the menu's traffic load buttons are updated to show the worst-case down-stream load/complexity for each flight-level, and Traffic PIs appear on the alternate route to show down-stream traffic load/complexity for the current CFL. 11
5.3.2 Any failure to absorb the required delay will mean that the surplus delay will be pushed down-stream. If that continued to happen for the whole trajectory length then the aircraft would be obliged to hold at the IAF. This would represent the controllers' best effort to absorb the total delay. 5.4 EMAN Delay Absorption 5.4.1 Once a controller has determined the best possible course of action and the associated Sector exit conditions, aircraft orders may be given using the level-change menu, the speed-change menu, or the Elastic Vector in order to honour those conditions. 5.5 The Roles of the PC and TC In this experiment the PC has responsibility for: Planning and co-ordinating sector entry/exit conditions for AMAN constraint conformance. Planning sector exit conditions to minimise impact on workload/complexity for downstream sector(s) Planning in-sector AMAN constraint conformance management. Planning and co-ordinating sector exit conditions to support TC workload management Monitoring traffic evolution and complexity management The TC has responsibility for: Implementing ATC clearances derived from (PC) modified trajectories Resolving delegated problems and conflicts Managing in-sector traffic Assume and Transfer of traffic Task delegation to the PC where deemed necessary and prudent Tactical co-ordination with adjacent sectors where necessary 12
6. APPENDIX A 6.1 Some illustrative examples of the Traffic PIs on an Aircraft Flight Leg 6.1.1 The PC in Sector B is planning an aircraft coming from Sector 'A' with Entry COP condition FL330 at ETO=10:08. The aircraft must lose 2 minutes (TTL=2) across the sector. Sector A Sector B Sector C PI 1 Medium Traffic WPT PI 2 Low Traffic WPT PI 3 High Traffic FL330 ETO 10:08 FL330 ETO 10:28 RTO 10:30 TTL 2 FL330 ETO 11:08 RTO 11:11 TTL 3 6.1.2 PC in Sector 'B' tests exit time of 10:30 (Time-To-Lose now = 0 minutes) Sector A Sector B Sector C PI 1 Medium Traffic WPT PI 2 Medium Traffic WPT PI 3 High Traffic FL330 ETO 10:08 FL330 ETO 10:30 RTO 10:30 TTL 0 FL330 ETO 11:08 RTO 11:11 TTL 3 13
6.1.3 PC in Sector 'B' tests alternate XFL of FL310 Sector A Sector B Sector C PI 1 Medium Traffic WPT PI 2 Low Traffic WPT PI 3 Medium Traffic FL310 ETO 10:08 FL310 ETO 10:30 RTO 10:30 TTL 0 FL310 ETO 11:08 RTO 11:11 TTL 3 14
6.2 Screen Shots of Proposed Controller Interface 6.2.1 The controller's view of traffic load/complexity using the Flight Leg tool. In the diagram below, JKK1135 is selected and the Flight Leg shows two Traffic PIs which represent downstream traffic load for two crossing points at FL370. The first has medium traffic load (yellow) and the second has low traffic load (green). The yellow values in the aircraft label are AMAN advisories and indicate that the controller has 2.9 minutes to lose in the current Sector, with a Sector exit RTO of 13:19. 15
6.2.2 Viewing down-stream traffic using the Exit Flight Level menu. In the diagram below, the controller has opened up the Exit Flight Level menu and each flight-level has a corresponding traffic button showing the worst-case down-stream traffic load for the current XFL. Initially, the Traffic PIs show the load assuming that JKK1135 leaves the current Sector at its ETO of 13:19, as shown at the bottom of the menu. Right-pressing the mouse over a flight-level load button causes each of the Traffic PI indicators on the Flight Leg (only one is visible in this diagram) to show the traffic at that altitude for the same ETO at sector exit. Here the Traffic PI shows that the down-stream traffic at FL330 for a Sector exit time of 13:19 is light (coloured in green). Note the layout and presentation of the information in the XFL menu is not a suggested interface; it's simply a means to present concepts of tools that help the Planning Controller plan further down-stream. 16
6.2.3 Examining the traffic sequence at a Traffic PI. In the diagram below, the controller has clicked on the traffic button at FL350 in the Exit Flight Level menu. The Traffic Analysis window shows the down-stream Traffic PI. It can be seen that medium traffic load (yellow) has been signalled because of the proximity of JKK1135 to the preceding flight CROSS_5. Note that we are only interested in traffic load at this stage of planning, and although this situation represents a potential conflict, it is in general too far down route to act upon it and the problem may disappear as time advances. The load represents a level of traffic planned to go through a point during a time period, and is only 'high' (in red) if there is a high probability that the situation will be difficult to resolve for the down-stream controller. In this case the load is shown as 'medium' because two aircraft are planned through the Traffic PI at the same time, and the situation should probably be easily resolved since there are no further aircraft planned through the point after 13:17. This level of load could (should) be linked to known load levels for a particular Traffic PI in a particular Sector at a particular time of day the kind of information which may become available through ETFMS, and its anticipated load complexity extensions. 17
6.2.4 Modification of the Sector exit conditions In the diagram below the controller has retarded the Sector exit time by one minute. This has brought the traffic at the next Traffic PI back to green (low traffic). The controller may now implement the new exit conditions knowing that the load for the following Sector's controller has been improved. This is done simply by clicking on FL350 menu button to accept it. The tactical controller must then get the aircraft to the exit COP at 13:20. In the future such a process would probably need a tactical probe in addition to the load probe. Note: These are only typical screen shots, and the diagram actually shows a Traffic PI in the same sector as the aircraft (the Sector exit time is after the Traffic PI time) normally the controller would be planning further down-stream into the next Sector. 18
6.2.5 Selecting an Alternate Route In the diagram below, an extra field has been added to the bottom of the XFL menu to allow the Planning Controller to see pre-defined alternate routes. The alternate route selected passes through the exit COP named BD01 and will reduce the EMAN time-to-lose value to 1.8 minutes (show in alternate COP field header) from the original 2.8 minutes specified in the original EMAN advisory (marked in yellow in the aircraft label). In addition, by absorbing the 1.8 minutes the flight will pass behind the crossing traffic as shown in the Traffic Analysis Window where JKK1135 has a current ETO of 13:17, the same as the last crossing flight SAS592. Note that the mouse may be left/right pressed on a flight-level's traffic button to show down-stream traffic for a modified XFL in the alternate route. 19