Icns Cheng

7/30/2019 Icns Cheng

1/13

1

Research Progress on an Automation Concept for

Surface Operation with Time-Based Trajectories

Victor H. L. Cheng, Optimal Synthesis Inc., Palo Alto, California

Abstract

To address anticipated growth in air trafficdemand, the Surface Operation AutomationResearch (SOAR) is a collection of researchactivities designed with the common goal to exploreand develop automation technologies for enhancingsurface movement efficiency at major airports. Theconcept features a tower automation system thatcounts on the availability of advancedsurveillancedata to plan the execution of timed surfaceoperations to enhance movement efficiency andsafety. Communication of the clearances willrequire the availability of digital data link for

sending the data for executing the time-basedtrajectoriesknown to some as 4-dimenaional (4D)trajectories. The concept also features a flight-deckautomation system that counts on the availability ofadvanced navigation data to enable the flights toexecute the 4D trajectories with high timingprecision. The arrangement results in acollaborative concept where the tower and flight-deck automation systems count on each othersabilities to jointly deliver the efficient and safesurface traffic. Several publications havedocumented the SOAR concept and initial

feasibility studies of the tower and flight-deckautomation systems based on early experimentalsoftware prototypes of the automation functions.This paper serves as a progress update of the SOARdevelopment effort. Specifically, it covers recenthuman-in-the-loop experiments to study proceduresand controller roles and responsibilities involvingthe tower automation system, as well asdevelopment of the flight-deck automation systemin terms of its guidance and control functions.

IntroductionThe predicted growth in air travel requires

capacity enhancement in the National AirspaceSystem (NAS), and congestion at key airports hasbeen recognized as one of the most prominentproblem areas1. With flights operating at limitsdictated by operational requirements associated

with current airport configurations, airport

expansion plans involving addition of new runwaysand taxiways are being realized to increase theairports capacities. However, the expansion plansnecessarily increase the complexity of the airportconfigurations, and the increase in complexity tendsto penalize the efficiency of the system, partiallyoffsetting the capacity-related benefits of theinvestments. The Surface Operation AutomationResearch (SOAR) concept has been proposed as acollaborative concept to provide tower and flight-deck automation systems to enhance the operationalefficiency in complex airport environments, thus

softening the penalties to fully realize the capacitybenefits sought by the airport expansion plans. Theconcept depends on advanced Communication,Navigation, and Surveillance (CNS) as enablingtechnologies to achieve a seamless integration ofthe tower and flight-deck automation systems.

Tower automation is based on the Ground-Operation Situation Awareness and Flow Efficiency(GoSAFE) concept previously developed under aNASA-sponsored research program to ease runwayaccess conflicts, especially in situations whereactive-runway crossings constitute a significant taxi

delay problem. To help achieve the potentialGoSAFE benefits, theFlight-Deck Automation forReliable Ground Operation (FARGO) concept hasbeen proposed to provide the necessary flight-deckautomation for enabling precision taxi control tocomply with GoSAFE clearances. Fundamentally,the GoSAFE/FARGO integration is based on 4Dtrajectories consistent with the airportconfiguration. Although the taxi operation isconstrained on the airport surface, the taxi routewith timing constraints at specified locations is stillreferred to as a 4D trajectory in the same spirit as

4D trajectories in flight, with the caveat that thealtitude dimension of the 4D space is constrained tothe surface.

Previous publications have documented theSOAR concept2,3,4, the automation systems5,6, andsome evaluation activities7 based on computersimulations of surface operations at a single hub

1-4244-1216-1/07/$25.00 2007 IEEE.


2/13

2

airport8 as well as the effect on the NAS-widetraffic9. This paper serves as a progress update ofthe development of these automation systems andthe assessment efforts.

In particular, the tower operations involvingthe GoSAFE automation system has been subjectedto a series of human-in-the-loop experimentsinvolving tower-controller subject experts in a full-scale tower simulator with realistic visual andsystem capabilities. Since the role of theautomation system is not to eliminate controllerpositions, but rather to assist the controllers inhandling a larger amount of traffic as predicted forthe future, the experiments focused on scenariosinvolving significantly higher demand levels.Different operational procedures involving voiceclearances and data-linked clearances were tested,as well as variations in the controllers roles andresponsibilities. The experiments have generallysupported the controllers receptiveness toautomation systems, and revealed the need forserious investments in technology development totransform the experimental prototype of theautomation system into a mission-ready system. Asummary of the experiments is provided below,with more detailed accounts of the experimentationefforts to be presented in other publications10,11.

Though the development of GoSAFE hasreached a level that high-fidelity human-in-the-loopevaluation can be performed, development of the

FARGO system is less mature. In the human-in-the-loop assessment of GoSAFE, it was assumed thatthe flight decks were equipped with FARGOautomation, which was emulated in the simulationof the surface traffic. In the mean time, actualdevelopment of the FARGO technologies hasprogressed in parallel in the last year12. Thedevelopment includes consideration of the flight-deck operational procedure, which is beingformulated to incorporate lessons learned from theGoSAFE experiments.

The next section provides an overview of the

SOAR collaborative surface-operation automationconcept, followed by a description of the human-in-the-loop experiments of the GoSAFE system, andrecent development effort of the FARGO system.

Overview of Collaborative

Automation Concept

Airport capacity, or the lack thereof, isreflected in the amount of delay incurred by thetraffic13. Figure 1 illustrates some of the factorscontributing to taxi delays on the airport surface.

The most prominent delays felt by the travelingpublic in the movement area are associated with thequeuing for departure and the queuing for activerunway crossing. Waiting for gate access at thepassenger terminal and the need for deicing are alsonotable causes. The first two factors are related torunway access, and they become worse as airportexpansion plans introduce more runways, whichlead to increased amount of active runwaycrossings. Moreover, having more traffic at theairport further exacerbates the runway accessproblem. It will be beneficial if the traffic can be

precisely controlled so that the flights can performactive runway crossings in between takeoffs andlandings, without introducing takeoff or landingdelays. This level of precise traffic control isdifficult in the presence of control-timinguncertainties associated with current operationalpractices of voice clearances, voice-based handoffs,and manual control of the aircraft that do not lendthemselves to operating according to strict timingconstraints.

ControlTower

FireStation#1

13L

17R

17L

AB

E

C

17C

EastATCT

Queuing forTakeoff Speed UncertaintySpeed Uncertainty

Queuing forActive-RunwayCrossing

Queuing forActive-RunwayCrossing

Stop-and-Go TimingStop-and-Go Timing

HandoffbetweenControllers

HandoffbetweenControllers

Figure 1. Operational Factors of Taxi Delays

The SOAR concept tries to achieve the precisecontrol in taxi operations through collaborativeautomation between the tower and the flight deck,as illustrated by Figure 2.


3/13

3

Flight-Deck

Automation

ControlTower

DatalinkedClearances

Surface TrafficManagement/Strategic Automation

Surface TrafficControl/Tactical Automation

Figure 2. Collaborative Automation between Tower and Flight Deck Operations

In the control tower, the Strategic Automationdepicted in Figure 2 is responsible forSurfaceTraffic Management (STM) functions including

decisions on airport configurations and coordinationof the runway assignment, sequencing andscheduling of arrival and departure flights withTerminal Control. The Tactical Automation isresponsible forSurface Traffic Control (STC)functions that involve taxi operation planning,clearance management, and surface conflictmanagement including the prevention of runwayincursions. The GoSAFE technologies explored to-date have focused on these STC functions.

With GoSAFE issuing the clearances, theFARGO system provides theFlight-Deck

Automation functions suggested in Figure 2 toexecute the clearances. The SOAR concept is builtupon the following coupled assumptions:

1. The FARGO automation system can achievehigh-precision taxi to allow the flight tomeet any reasonable crossing times at

selected points along a pre-specified taxiroute on the airport surface.

2. The GoSAFE automation system counts on

the availability of FARGOs precision-taxicapability to plan efficient and safeoperations for the surface traffic.The precision-taxi capability reduces

operational uncertainty that impacts the separationmargins the controllers have to introduce to assuresafe operations. Reducing the separation marginswill result in improved efficiency. Furthermore, thereduced uncertainty allows the more efficientoperations to be delivered with at least the samelevel of safety as in existing operations, even in thepresence of reduced temporal or spatial separation

between aircraft operations. Safety in this case isdefined based on the probability of conflicts, notmerely the nominal separation between vehicles.Reduced uncertainty can produce lower probabilityof conflict even when the nominal separation isreduced.


4/13

4

The block diagram in Figure 3 illustrates theinteraction between the GoSAFE and FARGOautomation systems, and the interactions of theoperatorsair traffic control and flight crewwiththese systems. It also depicts the feedback nature ofthe whole traffic control operation with CNSfunctional blocks, where advanced CNS are

considered enabling technologies for theautomation concept.

Tower Automation

GoSAFE

Flight-Deck

Automation

FARGO

Navigation

Surveillance

Communications

Aircraft

Dynamics

Cockpit CrewAir Traffic Controller

Figure 3. Block Diagram of SOAR Concept

Tower Automation

The STM functions of the tower automationhave been extensively studied by NASA under theresearch activities involving the SurfaceManagement System (SMS)14, whereas research ofthe GoSAFE system has focused on the STCfunctions. This separation of the functions is notintentional, and has emerged as a result of twoindependent efforts with their scopes limited byresearch resources. It is conceivable that practicaltower automation will encompass both STM andSTC functions in an integrated system.

The STM functions include automationassistance to help the Air Navigation ServiceProvider (ANSP)15 in the control tower to plan andschedule airport runway configurations, and toschedule runway usage for the arrival and departureflights, of which the flight plans should have beenfiled by the Flight Operations Center (FOC) of eachindividual carrier. The functions should be

performed in coordination with the ANSP in chargeof the terminal airspace.

With the airport runway configurationdetermined and flight details made available by theSTM functions, the STC automation would plan outthe surface operation details for execution by theflights. The GoSAFE system in its current state

contains the following key functions2,4, though atdifferent levels of maturity:

Planningfunctions for generating efficient taxiclearances: The current implementation ofGoSAFE uses a dynamic programmingapproach to optimize individual taxi routes, andthen adjusts the timing at intersections and therunways to avoid conflicts and incursions. Thekey objective is to plan the 4D trajectories sothat runway occupancy can be kept to aminimum, including the occupancy by therunway crossing traffic. This means that therunway crossing flights are expected tocontinue taxiing without holding and to crossthe runways at the assigned times. Calculationsof taxi routes and timing take into accountaircraft performance according to aircraft type,and weather conditions including surface windsand surface conditions. The resulting 4Dtrajectories can be edited by the controllermanually. Future research will considerintegrating the route planning and de-confliction functions into a unified solution forenhanced performance.

Traffic controlfunctions to facilitate issuanceof clearances to flight deck: The 4D trajectoriesfor the taxi operations are converted intoclearances that resemble current-day versionsrepresented by a list of taxiways, runways,exits, ramp spots, etc.so that they can be

easily understood by the controllers and pilots.The 4D nature of the trajectories is realized byembedding in the clearances timing constraintsfor crossing selected locations along the taxiroutes.

Traffic monitorfunctions to ensure safety oftraffic while executing demanding operations:Since the clearances are supposed to containconflict-free trajectories, any conflict orincursion by any flight under tower controlwould involve at least one flight deviating fromthe cleared trajectory.The GoSAFE systemcontains a Conformance Monitorfunction todetect flights that deviate from their clearancesby cross-checking the clearances withsurveillance data. A Conflict Predictionfunction is also planned for identifyingpotential conflicts and incursions. This functionshould provide improved performance over the


5/13

5

Airport Movement Area Safety System(AMASS) because it has access to (a) moreaccurate surveillance data complete withaircraft identification, and (b) intent of theflights deduced from the clearances.

Graphic user interface (GUI) to support theaforementioned functions: Each controllerstation can be tailored to the specificcontrollers needs and preferences, even thoughall the stations are accessing data from a centralGoSAFE system. The stations GUI allows thecontroller to monitor the traffic, view and edittaxi routes, issue clearances and check theirstatus. It also provides the interface to alert thecontrollers of impending problems, includingflights deviating from their clearances andpotential conflicts or runway incursions.

Flight-Deck AutomationTechnical feasibility of a flight-deck

automation system has been investigated inprevious studies6,4. Development of the automationtechnologies is currently being undertaken by aFARGO project12. The following functions areenvisioned as part of the FARGO automation.

Planningfunctions for planning the surfaceoperations: This function involves handling theclearances issued by tower, and inputting theminto the flight control computer for pre-

visualizing the surface operations andeventually for performing the taxi operations.

Auto-taxi functions to generate aircraft taxicontrol commands: Advanced guidancefunctions convert the clearance information into4D trajectory information for achievingprecision taxi requirements demanded byGoSAFE-generated clearances. Advancedcontroller designs provide the means to trackthe 4D trajectory. The automation functionstake into account aircraft performance andweather conditions.

Pilot interface to enable pilots to executeprecision taxi operations: Displays are includedin the FARGO concept to process theclearances and present the 4D trajectoryinformation to the flight crew. Other controldisplays provide control information to thepilots either for monitoring performance in a

fully automatic mode or for conveying controlcues in an automation-assisted mode.

Traffic monitorfunctions provided throughpilot interface to alert pilots of impendingdanger: FARGO can monitor the aircraftsnavigation state to alert the pilot of anysignificant deviation from its cleared taxiroutes. It can also track the surveillance datafrom other flights on the surface to alert theflight crew of any impending conflict orincursion by other vehicles.

Discussion of the FARGO development effortis provided later in the paper.

Operational Procedure

Since the SOAR concept promotes trafficefficiency through the use of time-based route

clearances that can be accomplished only withautomation such as FARGO, the use of voiceclearances to send the timing details is consideredimpractical and the use of digital data link isconsidered necessary. With so much informationembedded in the clearances, the procedures use pre-clearances to initially send the complete routeinformation, to allow the flight crew ample time tocomprehend the intended operation and identify anypotential cause for concern.

Furthermore, as the taxi route nominally wouldcontain locations where safety may become a

serious concern if the aircraft is unable to achievethe precise timing (e.g., active-runway crossings),contingency holds are inserted along the route atthese locations to give the controller the option ofallowing the aircraft to come to a stop if thecontroller chooses not to clear it to go beyond thatpoint. This means that the pre-clearance in factconsists of a number of segments, each of whichneed to be cleared as a separate clearance, and eachsegment contains a contingency hold at the endexcept for the final segment. The contingency holdis automatically removed when a subsequent

segment is cleared.

The SOAR operational procedure for handlingpre-clearances contains the following events:

Minutes before the clearance is needed,GoSAFE sends FARGO a data-linked pre-clearance containing taxi route information


6/13

6

similar to conventional clearances, with theaddition of time constraints where necessary toresolve conflicts with other vehicles andrunway usage.

FARGO would automatically access airportlayout database to convert the pre-clearanceinto route-segment information ready for accessby the cockpit crew.

When selected by the pilot, FARGO woulddisplay the clearance in both textual andgraphical forms, with the crossing constraintsappropriately emphasized. If the pre-clearanceinvolves more than one segment, the locationsof the contingency holds for the segments arealso displayed to the flight crew.

The FARGO interface provides the pilot withoptions to accept or reject the pre-clearance.Acceptance of the pre-clearance automaticallysaves the information for later use.

Acknowledgment of the pre-clearance is data-linked back to GoSAFE to help the controllerskeep track of the status.

With the taxi route information already sent tothe flight deck in the form of a pre-clearance, thereis no need to repeat all the information when thesubsequent clearances are issued. The individualclearance segments can be abbreviated withidentifiers to reference the pre-clearance. Thisabbreviated form allows the controller the option toissue the clearances by voice or by data link. Sincetiming is important in executing the timedclearances, a clearance should be issued sufficientlyearly ahead of time (e.g., tens of seconds) so thatFARGO can initiate the operation at the momentthe segment is supposed to commence. The SOARprocedure for handling clearances contains thefollowing events:

A tower controller issues a clearance for asegment by voice or by data link, as desired.

The flight crew either accepts or rejects thesegment clearance, using the same mode ofcommunication (i.e., voice or data link).Acceptance of the clearance by data link willautomatically activate FARGO for the segment;otherwise, the pilot has to manually activate thesegment.

Acceptance of a segment clearance willautomatically remove the contingency hold atthe end of the last cleared segment, and appendthe new segment to it.

Data-linked acceptance of a clearance alsoautomatically notifies GoSAFE; otherwise, the

controller will need to manually updateGoSAFE with the clearance status. Speechrecognition is being considered for futureresearch to convert voice acknowledgment intosignal to update GoSAFE.

Rejected clearances will lead to GoSAFEreplanning taxi operations, including theoperations of other affected flights. Thereplanning normally involves adjusting thetiming constraints, but in serious situations mayrequire completely new pre-clearances.

Handoff between controllers can be done byvoice or data link, or independently by theflight crew based on published procedures.

Procedures dealing with emergency situationssuch as reacting to conflicts or incursions typicallywill involve some flights performing an emergencymaneuver (e.g., stop) that will cause theconformance monitor functions of the automationsystems to detect the problem. The controllers willlikely given voice clearances to resolve the problempromptly, and proceed to use GoSAFE to replan theoperations. This subject is an important item for

future research on off-nominal situations.

Human-in-the-Loop Experiments of

Tower Automation

The SOAR concept was given the opportunityin the last two years to benefit from human-in-the-loop experiments to study the plausibility of theconcept. Furthermore, since the goal of theautomation concept is to enable the tower ANSP tohandle heavier traffic in a complex environment,the experiments also serve to explore what roles and

responsibilities are most appropriate for the humanoperators to achieve this goal. The subject matterexperts (SME) participating in the experiments allhad working experience as tower controllers.


7/13

7

Simulation Facilities

As a future concept that involves sophisticatedautomation, the SOAR concept will require a lot oftesting to verify its efficacy and reliability of itssystems before it can be considered for field tests.Such tests can benefit tremendously from a realisticsimulation environment, and the project was

fortunate to have a world-class tower simulatorthe FutureFlight Central16 at NASA Ames ResearchCenteravailable for this advanced research topic.Figure 4 contains a wide-angle view of the towersimulator, which is a full-scale representation of acontrol tower with a full 360 airport view.

Figure 4. View of the Tower Simulator

FutureFlight Central Tower Simulator

Pseudo-Aircraft Station

DoD High-Level Architecture (HLA)

GoSAFE

ATG

Figure 5. Real-Time Simulation Architecture

An experimental prototype of the GoSAFEsystem was installed at the tower simulator, withthe GoSAFE GUI installed at four controllerstations to support two Local and two GroundController positions. The traffic was provided by apseudo-aircraft system called Airspace TrafficGenerator (ATG), with pseudo-pilots controlling

the simulated flights and communicating with thecontroller subject experts. Figure 5 illustrates howthe simulation facilities and experimental systemsare networked together based on DoDs High-LevelArchitecture (HLA).

Experiment Scenarios

The experiments have been designed aroundthe east side of Dallas/Fort Worth InternationalAirport (DFW), with the controllers operating fromthe vantage point of the East ATC Tower as

depicted in the layout of Figure 1. A South Flowairport configuration was used for all theexperiments, where typically runways 17R and 13Lare for departure, and runways 17C and 17L are forarrivals. Some experiment runs tested the use ofrunway 17R for mixed arrival/departure traffic,when the scenario included a heavy arrival demand.

The traffic demand used in the simulations wasset at about 150% of current-day levels, partly toaccount for the anticipated increase in air traffic,and partly to account for the absence of groundvehicles in the scenarios. Simulation of arrival

flights started at about 12 nmi out, and departureflights would end at about 5 nmi after takeoff.Simulation on the surface was limited to themovement area up to the ramp spots. Operationswithin the ramp area were not included.

Three scenario data sets of flight scheduleswere generated for the experiments to representthree different arrival/departure mixes andtransition characteristics. In order to verify thatGoSAFE could actually handle this level ofdemands, verification simulations were run withGoSAFE automatically issuing the clearances to thepseudo-aircraft system, which would in turnautomatically accept the clearances and cause thesimulated flights to execute the clearances as ifthere is a FARGO system doing the auto-taxi.These runs were successful in verifying the routeplanning functionality of GoSAFE, but they werenot considered part of the experiments because fully


8/13

8

automatic surface traffic control was not anoperational concept being studied.

Options on Operational Procedures, Roles,

and Responsibilities

With the operational procedure described

above, several options were explored for varyingthe procedure:

Voice vs. Data-Link ClearancesThe main variation of the procedure was to

compare the issuance of clearances by voice versusby data link. A special keypad was provided ateach controller station with a key for sending adata-linked clearance. If it is issued by voice, thecontroller will have the task of informing theGoSAFE system whether the clearance is acceptedor rejected; for this the controller has two keys toenter these two respective responses.

HandoffsHandoffs of flights between controllers involve

frequency changes, and the controllers were giventhe option to perform the handoff by voice or bydata link. A key stroke would be required if thehandoff was to be done by data link.

Replanning for New ClearancesThe controllers had the option of adjusting a

taxi route manually using the GoSAFE GUI5spatially or temporally. In this case, a new pre-clearance would be automatically generated andcommunicated to the flight deck.

In addition, a function was introduced as theexperiments progressed to allow the controller torequest GoSAFE to replan only the timingconstraints. The need for this function wasidentified when controllers began to deviate fromissuing the recommended clearances and caused theflights to miss the timing constraints. This functionwould also be useful for restarting flights held atcontingency hold points.

Controller Roles and ResponsibilitiesThe original experiments were set up for the

controllers to maintain the usual tower controllerpositions similar to todays operations: specifically,the SOAR experiments focused on Local andGround Controllers. Typically, the SMEs wouldplay the role of two Local and two Ground

Controllers for the DFW East ATC Toweroperations.

With the extra heavy traffic defined in thedemand scenarios, it was evident that the LocalController responsible for runway 17R had theheaviest workload, since this position had to dealwith every flight operating to/from all fourrunwaysthe flights either take off or land on 17R,or they have to cross 17R when taxiing betweentheir arrival/departure runway and the ramp area.To help relieve this controller positions workload,some experiment runs were performed with theGround Controller responsible for the south-sidetraffic to take over the runway 17R crossing trafficnear the south end. This means that the twocontrollers had to share the responsibility ofcontrolling the traffic over runway 17Raprocedure that should require serious coordinationbetween the two positions to prevent runwayincursions.

Another key change of controllerresponsibilities is associated with the introductionof an automation system. How this change affectsthe controllers performance of controlling thetraffic and keeping a mental picture to detectoperational hazard will remain an importantresearch issue through the course of this research.

Brief Discussion of Experimental Findings

Voice vs. Data-Link ClearancesAlthough the controllers have the flexibility tochoose between voice or data link for issuing eachclearance, the experiments were set up to ask themto nominally use one or the other in a single run. Itwas observed that after having used the keypad oneway for one run, if the controllers were asked to usethe second approach for the next run, there seemedto be an increase in likelihood of them pushing thewrong button on the keypad. This suggests thatkeypad design may be important in distinguishingthe actions for voice and data-link clearances.

In general, the controllers could handle theclearances better with data link than with voice. Apossible reason is that, with data link, the controllerdid not need to wait for the acknowledgment beforeworking on another flight as he/she would by voice.The amount of time that the controller had to waitcould have been inflated as a result of the


9/13

9

experimental set up: specifically, a pseudo-pilotcontrolling multiple aircraft might take longer torespond than in the actual situation when the flightcrew is concerned with controlling only onevehicle, as the pseudo-pilot often had to take sometime to locate the appropriate flight on the ATGstation.

HandoffsInitially some of the simulation runs were

designed to do handoffs either by voice or by datalink. As the experiments progressed, the SMEspointed out that handoff events were often doneautomatically by the flight crew according topublished procedures for the airports. Since then,the ATG software was modified to simulate thistype of handoff procedure and the controllers wouldno longer need to initiate handoffs.

Replanning for New Clearances

Early in the experiments, it was soon obviousthat the existing route editing functions in GoSAFEwere too time-consuming when the controllersalready had to deal with the extremely heavy trafficload. The function introduced later for replanningtiming constraints was in comparison relativelyeasy to use, and it was desired by the SMEs.Regarding the need to replan taxi routes, the SMEshave suggested the ability to generate multipleroutes from which the controllers could easilychoose. The development of this function remainsa research topic.

Controller Roles and ResponsibilitiesAll the SMEs who participated in the

experiments were receptive to the idea of theautomation concept and their new roles in workingwith the automation system, with the understandingthat the system used in the experiment was only anexperimental prototype with incompletefunctionality.

Digital videos were captured for some of thecontroller positions to provide data for studying thelevel of interactions the controllers had with the

automation system. Ref. 11 includes some analysesof the data to reveal how the controllers activitieswere affected by the automation, though the level ofthese activities may change as the automationtechnologies mature. One observation is that theautomation system would likely lead to more head-down activities and reduce the amount of head-up

time to monitor traffic by looking out the window.This might have been due to both good or badreasons: there might be more useful surveillanceand situational data available on the GUI, butoperating the experimental automation systemmight have required too much attention.

In any case, additional experiments have beenrun to use only the automation system in awindowless room, and the SMEs were able tocontrol the traffic without the benefit of out-the-window view. This suggests that it may be possibleto provide virtual tower operations by usingautomation.

Regarding the sharing of responsibilities bytwo controllers over the jurisdiction of one runway,the SMEs felt that the change did reduce theworkload of the Local Controller, but they believedthat it would be possible only with the help of the

automation system, which allowed them tocoordinate tightly timed but safe operations.

SME feedback exposed some undesirableeffects. They felt that the automation haddiminished their decision-making role. Futureresearch will need to focus on redefining thecontrollers role by raising them to a higher level ofresponsibilities of assuring safe and efficientoperations under very heavy traffic conditions.This will require good judgment in rebalancing thefunctions allocated to the controllers and theautomation.

Impact on Controller WorkloadDuring each 45-min simulated scenario, the

controllers had to periodically report their perceivedworkload using a workload assessment keypad, andthen again after the end of the run through theNASA Task Load Index (TLX)17. The collecteddata indicates that perceived workload wassignificantly reduced under advanced automationconditions, more so as the automation assumedmore functions. Detailed analysis results arediscussed in Ref. 11.

Information Requirements and PresentationWhereas the experiment results indicate that

the SMEs were generally receptive to theautomation concept, and that workload generallydecreased when the controllers were assisted by thetower automation system, they also revealeddeficiencies in the current implementation of the


10/13

10

GoSAFE prototype. Many of these issues relate towhat type of information would benefit thecontrollers understanding of the intent of theautomation system, and how to present theinformation to the controllers so that the controllerscan act on the GoSAFE events in a timely manner.These issues have implications on whether the

GoSAFE clearances can be issued to the flightsconsistently, which in turn affects whether theGoSAFE plans are effectively carried out by theflights. Failure to achieve a high level ofcompliance with GoSAFE plans will lead to adomino effect causing the collaborative automationconcept to break down.

Development of Flight-Deck

Automation

FARGOs automation functions include the

use of digital communication via data link to acceptclearances with embedded 4D trajectoryinformation in the taxi route. Advanced navigationis assumed for the aircraft to interpret the clearancesand execute the 4D trajectory with high-precisionperformance. The following summarizes theFARGO design, with details provided in Ref. 12.

Guidance Function for Trajectory Generation

A guidance function is designed to accept thetaxi route specified by the clearance with embedded

timing constraints to generate a detailed 4Dtrajectory that the aircraft is expected to track.This trajectory is more than a route with requiredtimes of arrival (RTA) at selected points: it is acomplete trajectory where every point along theway is mapped to a point in time.

This guidance function takes into considerationairport layout standards18 with respect to turningrequirements. There are a number of factors that gointo the computation of the trajectory, includingturn radii, hold distances, aircraft performance, andpassenger comfort. The turn radii and hold

distances are based partly on the largest aircraft thatan airport is expected to handle, and the numbersare therefore defined for approach categories anddesign groups. The FARGO design imposes asmooth acceleration profile in defining thetrajectory.

Nonlinear Controller for Aircraft Taxi

Control

A nonlinear controller is designed to generatethe control signals to effect the 4D-trajectorytracking, based on the Nonlinear Synthesis Tools19(NST) product. Of the many nonlinear controldesign techniques included in NST, thefeedbacklinearization methodology is being considered forthe current FARGO design. NST provides thenecessary tools in synthesizing a superior nonlinearcontroller with a software model of the aircraftdynamics embedded in its own code. The currentFARGO design is being produced for a B-737-typeaircraft, for which a software model has beenextracted from NASAs Transport System ResearchVehicle6 (TSRV) simulation. Performance of thenonlinear controller has been verified based oncomputer simulations.

Interface for Piloting

Figure 6 illustrates various proposed displaysas part of the pilot interface. Textual clearance datacan be shown on the Engine Indication and CrewAlert System (EICAS) displays. The flight crewhas the option of viewing the route informationextracted from the pre-clearance on an electronicmoving map (EMM). The head-up display (HUD)is preferred as a control display to enable the pilotsto monitor FARGOs performance during auto-taxioperations, and to enable the pilots to perform

manual taxi control by display control advisoriesfor the pilots to follow. Figure 7 contains anillustration of the HUD graphical design proposedto display the FARGO guidance and control data.

Upper EICAS Clearance

Alert

Lower EICAS TextualClearance

Electronic Moving Map Taxi Route Preview Navigation

Traffic Monitoring

Head-Up Display Taxi Control Conflict

Avoidance

Figure 6. FARGO Pilot-Interface Displays


11/13

11

MANUALCurrent 8 .0 kts

Required 8.0 kts

16:48:20 ETA

16:48:20 RTA

Alpha 3 | Bravo 2 | Alpha 3

SLOWRight Turn

Max. 8 kts

SLOWRight Turn

Max. 8 kts

Figure 7. Sample HUD Display Format

Traffic Monitor Function

Advanced surveillance services are assumed

that will allow the FARGO automation to detectand react to potential conflicts with other surfacetraffic. The EMM display as shown in Figure 8 isappropriate for providing traffic information andalert in anticipation of conflicts with other vehicles,by superimposing aircraft icons on the displayshowing locations of the nearby traffic. It is alsobeneficial to post conflict alerts on the HUD eventhough the HUDs field of view is limited, since theHUD is likely the primary display used by the pilotperforming taxi operations.

Figure 8. Sample EMM Display

Suggestions for Future Research

Concerning the technologies for the SOARconcept, we believe that the feasibility has beenproven through early prototypes and experiments.The concept is ready for transition into the nextphase of development, where full-feature functionsshould be developed along with experiments to helpshape the operational procedures and the roles andresponsibilities between operators and automation.The following is a brief discussion of recommendedresearch activities.

Technical research should be dedicated tooptimal route planning to design 4D trajectorieswhich are coordinated for the complete surfacetraffic. While route optimality is a desirableperformance metric, it is also desirable to tradesome of the optimality for inter-flight separationmargins to alleviate the potential impact of non-

conformance events.

The human-in-the-loop experiments forGoSAFE have revealed the need for extensiveresearch to define the roles and responsibilitiesbetween human operators and automaton. Theresearch needs to be tied to the design of proceduresand user interfaces that promotes synergy fromoperator/automation interaction. Procedureresearch also needs to address off-nominalsituations.

It is expected that the tactical automation

functions for trajectory and separation managementbeing studied with the GoSAFE prototype will needto be integrated with strategic automation functionsresponsible for airport/airspace configurations andsurface traffic flow management.

Research and development of flight-deckautomation should continue with the FARGOdevelopment. Human-in-the-loop experimentationof the technologies should be included in the nextphase of research to ensure that human-operatorconsiderations are addressed early in the process.

As both tower and flight-deck automationsmature, integrated testing of these technologiesshould follow. Field testing of the SOARtechnologies should be considered in far-termplanning. The issue of traffic with mixedequipagei.e., not all aircraft are equipped withflight-deck automationalso needs to be addressed


12/13

12

to study the transition into a highly automatedfuture environment.

Concluding Remarks

This paper has provided a progress update ofthe Surface Operation Automation Research

(SOAR) at Optimal Synthesis Inc. SOAR is not asingle research program, but instead a collection ofresearch activities with the common goal ofapplying automation technologies to enhanceairport surface operations. Specifically, the SOARapproach advocates a concept that involvescollaboration between automation systems in theAir Traffic Control Tower and the flight deck,making use of advanced Communication,Navigation, and Surveillance technologies. Thetower automation makes use of advancedsurveillance data to plan complete surface traffic

operations in the form of 4D trajectories for allflights, taking into consideration aircraftperformance data and environmental conditions.Advanced communication technologies are assumedto support the issuance of clearances containing the4D trajectories to the flights via digital data link.The flight-deck automation makes use of accuratenavigation data to perform the taxi operations inaccordance with the 4D trajectories embedded inthe clearances.

Feasibility of the concept has been verifiedthrough simulations and experiments with early

prototypes of the automation systems. Human-in-the-loop experiments involving tower-controllersubject experts have been performed in the lastcouple of years to study operational procedures inthe control tower, using an experimental prototypeof the tower automation system. The subject matterexperts have been generally receptive to theautomation concept, and they have contributeddirectly in the investigation of new roles andresponsibilities of tower controllers working withthe automation. Development of the flight-deckautomation is not as mature, but an experimental

prototype suitable for human-in-the-loop testing isexpected to be available in another year.

The progress thus far supports the assertionthat the SOAR concept can be part of the solution toincrease capacity of the National Airspace System(NAS). In particular, it can help alleviate thecongestion problem associated with airports being

the bottleneck of NAS traffic. To pursue thiscollaborative automation concept further, seriousinvestments will be required for technologydevelopment for the automation systems. Thispaper has included suggestions for future researchto identify key areas essential for the success of theapproach.

References1National Airspace System Operational EvolutionPlan, Version 8.0, Federal Aviation Administration,December 2002.

2 Cheng, V. H. L., 2002, Collaborative AutomationSystems for Enhancing Airport Surface TrafficEfficiency and Safety,Proceedings of the 21stIEEE/AIAA Digital Avionics Systems Conference,

Irvine, CA, Paper 1D4.3 Cheng, V. H. L., 2003, Airport Surface OperationCollaborative Automation Concept,Proc. AIAAGuidance, Navigation, and Control Conf., Austin,TX, AIAA Paper 2003-5773.

4 Cheng, V. H. L., 2004, Surface OperationAutomation Research for Airport Tower and FlightDeck Automation,Proceedings of the 2004 IEEEIntelligent Transportation Systems (2004 ITSC),Washington, DC, Paper TuC2.4.

5 Cheng, V. H. L., and D. C. Foyle, 2002,

Automation Tools for Enhancing Ground-Operation Situation Awareness and FlowEfficiency,Proc. AIAA Guidance, Navigation, andControl Conference, Monterey, CA, AIAA Paper2002-4856.

6 Cheng, V. H. L., V. Sharma, and D. C. Foyle,2001, Study of Aircraft Taxi Performance forEnhancing Airport Surface Traffic Control,IEEETrans. Intelligent Transportation Systems, Vol. 2,No. 2.

7 Cheng, V. H. L., A. Yeh, and D. C. Foyle, 2003,

Evaluation plan for an airport surface-operationautomation concept,Proc. 2003 AIAA AircraftTechnology, Integration, and Operations (ATIO)

Technical Forum, Denver, CO, AIAA Paper 2003-6796.

8 Cheng, V. H. L., A. Yeh, G. M. Diaz, andD. C. Foyle, 2004, Surface-Operation Benefits of a


13/13

13

Collaborative Automation Concept,Proceedingsof the AIAA Guidance, Navigation, and ControlConference, Providence, RI, AIAA Paper 2004-5409.

9 Cheng, V. H. L., 2004, Evaluation Plan for

System-Wide Benefits of an Airport Surface-Operation Automation Concept,Proceedings ofthe 23rd Digital Aviation Systems Conference

(DASC), Salt Lake City, UT, Paper 3A4.

10 Cheng, S. Y., Y. G. Seo, V. H. L. Cheng,L. H. Martin, S. A. Verma, and D. S. Ballinger,2007, Ground Operation Concept TestingRequirements and Challenges, to be presented,AIAA Modeling and Simulation Technologies

Conference, Hilton Head, SC, Paper No. AIAA-2007-6701.

11

Martin, L., S. Verma, D. Ballinger, andV. Cheng, 2007, Developing a Decision SupportInterface for Surface Domain Air TrafficControllers, to be published in theProceedings ofthe Human Factors and Ergonomics Societys 51st

Annual Meeting, Baltimore, MD.

12 Sweriduk, G. D., V. H. L. Cheng, A. D. Andre,and D. C. Foyle, 2007, Automation Tools forHigh-Precision Taxiing, submitted for presentationat the 26th Digital Avionics Systems Conference,Dallas, TX.

13

FAA Airport Benefit-Cost Analysis Guidance,Office of Aviation Policy and Plans, FederalAviation Administration, December 15, 1999.

14 Atkins, S., C. Brinton, and D. Walton, 2002,Functionalities, Displays, and Concept of Use forthe Surface Management System,Proceedings ofthe 21st Digital Avionics Systems Conference,Irvine, CA, Paper 1.D.6.

15 Concept of Operations for the Next GenerationAir Transportation System, Version 1.2 (Draft 5),Joint Planning and Development Office, February

28, 2007.16 Dorighi, N. S., and B. T. Sullivan, 2003,FutureFlight Central: A Revolutionary Air TrafficControl Tower Simulation Facility,Proceedings ofthe AIAA Modeling and Simulation Technologies

Conference, Austin, TX, Paper AIAA-2003-5598.

17 Hart, S. G., and L. E. Staveland, 1988,Development of NASA-TLX (Task Load Index):Results of Empirical and Theoretical Research, inP. A. Hancock and N. Meshkati (Eds.),HumanMental Workload, pp. 239250, Amsterdam: NorthHolland Press.

18 Airport Design, Federal AviationAdministration Advisory Circular 150/5300-13, U.S. Dept. of Transportation, Sept. 29, 1989.

19 Nonlinear Synthesis Tools Users Manual,Optimal Synthesis Inc., 2000.

2007 ICNS Conference

1-3 May 2007

Documents

Icns Cheng