To BDI, or Not to BDI: Design Choices in an Agent-BasedTraffic Flow Management Simulation

Shawn R. Wolfe Maarten SierhuisNASA Ames Research Center RIACS/NASA Ames Research CenterShawn.R.Wolfe@nasa.gov Maarten.Sierhuis-1@nasa.gov

Peter A. JarvisPerot Systems Government Services/NASA Ames Research Center

pjarvis@email.arc.nasa.gov

Abstract

Belief-Desire-Intention (BDI) is a powerful agentparadigm that allows for the development of so-calledintelligent agents – agents that can reason and actbased on their beliefs and intentions. However, thispower often comes at the cost of increasedcomputational overhead. We describe our experienceusing a BDI agent framework for developing asimulation of collaborative air traffic flowmanagement and the efficiency problems weencountered. By using BDI more judiciously in oursimulation, we were able to address these issues andgreatly reduce the execution time of our simulation.From our successes and failures, we derive severalguidelines that may enable other researchers to avoidsimilar efficiency issues in BDI-based simulations.

1. Introduction

The National Airspace System (NAS) of the UnitedStates today is under the control of the FederalAviation Administration (FAA). Aided by their morecomprehensive situational knowledge, the FAA’s airtraffic controllers work with pilots to ensure safety inthe airspace. Though pilots of small general aviation(GA) aircraft are often able to fly safely using visualflight rules (VFR) and minimal controller direction,pilots of larger commercial aircraft rely heavily on airtraffic controllers, as they have little visual warning atthe correspondingly higher flight speeds. Air trafficflow management, then, is primarily focused onmanaging these commercial flights safely throughtraffic congestion, poor weather and other potentialhazards.

To make this task manageable for the controllers,commercial aircraft generally follow structured airtraffic routes, essentially “highways in the sky”. These

air routes greatly increase the predictability andmanageability of traffic flows, but at the cost offreedom of movement. Though not readily observableto the naked eye, aircraft are often queued up in theseflight routes, much like cars on a busy freeway. Unlikethose cars, however, aircraft must operate within anarrow range of flights speeds to avoid stalling orstructural damage. These operating constraints makethe traffic flow management task more challenging,reducing the number aircraft the controllers canmanage. A forecast of air traffic demand in 2025 showsan increase of two to three times over present daylevels [1], resulting in even greater flight delays.

The Next Generation Air Transportation System(NGATS) project is a multi-faceted research effort toaddress issues with the NAS. One such facet is the areaof Collaborative Traffic Flow Management (CTFM),which intends to increase both the efficiency of theNAS and the satisfaction level of the airlines. Intoday’s system, the flow of traffic is primarily handledby three entities: the FAA’s Air Traffic ControlSystem Command Center (ATCSCC) and, TrafficManagement Units (TMUs), and the individualairlines' Airline Operation Centers (AOCs). Previousfield observations found that several aspects of thecurrent system hindered collaboration [2]. A newconcept of operations was suggested to address theseissues [3], and our goal is to evaluate this conceptthrough an agent-based simulation.

We begin (in Section 2) with related TFMsimulations, categorizing them within or outside of theagent-directed simulation taxonomy. In Section 3 westate the problem we are trying to model and simulate(i.e. a specific traffic flow problem in the NAS), and inSection 4 we motivate our use of the BDI agentparadigm and characterize the simulation platform(Brahms) used. The primary contribution follows inthe remainder of the paper, as we describe an idealized,

naïve model design that incorporates earlier flaws, andcontrast this naïve design with our later design. Fromthis experience, we derive general guidelines for theuse of BDI agents in large-scale simulations andconclude with future work.

2. Related TFM Simulations

TFM involves both complex physical processes(e.g., aerodynamics) and complex human systems(e.g., coordinated action and distributed decisionmaking). An earlier focus on physics-based modelinghas lead to several excellent simulators of the firsttype, and so increasingly the focus has been shifting tothe simulating the roles of people in the TFM system.The use of the agent paradigm is growing in TFMsimulations, but the use of BDI agents in TFM has yetto enjoy widespread adoption.

Agent-directed simulation separates the use ofagents in simulation into the category of simulationfor agents and agents for simulation [4]. In simulationfor agents, simulation techniques are used forsimulating real-world entity behavior, e.g. simulationof cognitive behavior. Agents for simulation itself isdivided into two categories: agent-supportedsimulation, the implementation of a simulationenvironment with the help of agent technology; andagent-based modeling and simulation (ABMS), usinginteracting software agents modeled to generateemergent system behavior.

Simulation for Agents of TFM: The AirspaceConcept Evaluation System (ACES) [5] is adistributed agent simulation of the NAS. ACES isbased on the Department of Defense’s High LevelArchitecture (HLA), which has enabled the integrationof several simulations into the overall system. AsACES is focused on the entire NAS, the simulationincludes traffic flow management [6], but is notspecifically focused on TFM.

The Man-Machine Integrated Design and AnalysisSystem (MIDAS) [7] is another example of an agentsimulation. MIDAS is a human performance simulatorfor pilots or flight controllers, focusing on thelimitations of cognitive ability more than the results ofcomplex decision making.

Agents for Simulation of TFM : IMPACT(Intelligent agent-based Model for Policy Analysis andof Collaborative Traffic flow management) uses anABMS approach to simulate the interaction betweensimple agents in an economically based environment[8]. In the simulation, policy-based FAA agentsevaluate and impose ground delay programs (GDP),based on the capacity of the airspace and the weather.Their decisions are based on simple rules aboutcapacity of airports and equality between airlines. Theairline agents are economically based agents and maketheir decisions based on calculated cost. By imposing

specific random events at the start, the output of thesimulation are statistics based on the emergent agentbehavior in the system. The purpose of the IMPACTsimulation is very similar as the purpose of oursimulation. However, our agent approach differs in thatIMPACT models airlines and FAA as swarm-basedagents that use a simplistic decision-makingalgorithm. In contrast, we use a more complex agentmodel of the organization of both airlines and FAA,using BDI agents that can reason and communicatewith other agents in the model.

Tumer and Agogino [9] use FACET (see below) totest a multi-agent algorithm for traffic flowmanagement. They use a Monte-Carlo simulation toestimate the congestion within a certain trafficmanagement unit (TMU) within the NAS, based onsimple agents’ actions to speed up or slow downtraffic. The agents use reinforcement learning to set theseparation between airplanes to manage congestion.

Whereas our simulation focuses on the collaborativedecision-making process between the airlines and FAAbefore flights take off, Tumer and Agogino focus onadaptive agents taking independent actions thatmaximize a system evaluation function for enrouteflights. They use an ABMS approach to evaluate theirAI-algorithm. Again, agents are very simplecomputational objects representing fixes in a 2D space,and do not have any similarities with entities in thereal world (e.g. particular people in a FAA controlcenter).

Non-Agent Simulations of TFM: Hogan andWojcik [10] simulate a “day in the life” of Newarkairport. Their simulation model is not agent-based:although their paper does not provide a description ofthe model representation, it is clear that airport,runways, routes, etc, are at most represented asstructured records or objects. Decision-makers are notmodeled in any detail.

FACET [11] [12] is a NASA-developed tool forsimulating air traffic flow. FACET contains modulesthat concentrate on trajectory modeling, weathermodeling, and also contains a model of the airspacestructure, including the ARTCC regions, sectors, andair routes. FACET can act either as a simulator or as aplayback mechanism, using either from historical dataor from a live data feed from the FAA. FACET hasbeen integrated into a commercial product, FlightExplorer [13] which is used by the majority of majorU.S. airlines. FACET is not an agent-basedsimulation, concentrating primarily on the physicalaspects of air traffic flow, but does include non-physical aspects such as controller workload and airtraffic management initiatives.

3. Simulating CTFM

The CTFM concept of operations is quite complex,requiring a multi-year effort to develop a completesimulation. Our initial efforts focused only on a subsetof the CTFM concept of operations: the route selectionproblem [14]. We also made several simplifications tospeed up the initial modeling task. In reality, eachcontroller controls a three-dimensional space known asa sector, but in our model we assigned one controllerper route and did not include sectors. The controllersthemselves were modeled only as a constraint, i.e., thenumber of flights that could follow a particular airroute, which we considered as a route capacity. Thedesigns presented in this paper do not include personsor roles within an organization, as our BDI agentscorrespond to the organizational level. Therefore, anAOC or TMU is modeled as a single agent rather thana more complex set of cooperating “people” agents. Amore complex model that captures individual roles iscurrently under development but falls outside of thescope of this paper.

We created several simple traffic scenarios withvarying levels of traffic. All scenarios used trafficbetween seven airports, three airlines, and controlledby only one TMU. This meant that we had only oneTMU agent and three AOC agents, and that we did notneed to model TMU to TMU interactions. Three airroutes were created between each airport pair: a primaryroute, preferred by all airlines, and two less desirablesecondary routes. Though the capacity on the primaryroute was not always enough for all scheduled traffic,there was enough capacity amongst the three routes toaccommodate all scheduled traffic. Our goal was tomeasure how effectively routes were assigned to flightsby either the TMU or the AOC.

We created several variants of the simulation toprovide points for comparison. In the first variant, theTMU chose all routes for all flights without inputfrom the AOC or concern for the relative value of eachflight: this simulation roughly corresponds to currentoperations. In the second variant, the TMU again choseroutes for all flights, but would use the value of theflight and a greedy algorithm to reach a globallyoptimal solution: this simulation captured the bestperformance possible, according to our metric. In thethird variant, the AOCs would choose routesthemselves in an iterative process, with the TMUevaluating the global solution and notifying the AOCsof any constraint violations. This variant most closelycorresponded to the CTFM concept of operations. Inall cases, we ignored the possibility of weather andother such disruptions; the only constraint was thelimited (but static) capacity of the routes.

4. The Case for BDI

Our notion of modeling collaboration betweenhuman organizations is based on our work practicesimulation approach [15]. Although modeling workpractice based on a concept of future collaborationbetween people is not possible (as the work practicehas not been established), the agent-based modelingapproach we developed for modeling work practice inorganizations allows us to instantiate the conceptprocess flow in a realistic agent-based model. Such anABM enables the investigation of how people willactually collaborate in the future process.

The main representational paradigm for BDI agentsis declarative antecedent-consequence rules, similar tothe old rule-based expert systems [16] [17]. Each BDIagent can be seen as a knowledge-based system thatrepresents the reasoning capability of a particular agent.Therefore, a multi-agent BDI simulation includes anumber of parallel-executed knowledge-based agentsthat represent people performing particular roles inorganizations. We use BDI agents to model thecollaborative decision making in each phase of theprocess flow. This allows us to model thecollaborative decision making at a realistic level ofpeople working together in an organization. This is incontrast to the simple algorithmic agents used in [8],[9] and [10].

The power of the BDI approach is that we canrepresent how collaborative decision making canhappen in tomorrow’s organizations of airlines andFAA. We represent the work activities of the differentroles needed to implement the CTFM concept process.

We use the Brahms multi-agent simulationlanguage [18] to model the concept collaborativeprocess flow described by Garcia-Chico et al [19].Brahms is a tool for modeling and simulating the waypeople work and collaborate, and use systems toaccomplish their tasks. Brahms agents are both BDIagents, as well as subsumption-based reactive agents(see Figure 1) [20]. Brahms can be used to describecurrent and future work processes and practices inhuman and other types of organizations. Anotherapplication of Brahms is to design the collaborativeactivities between multiple intelligent agents— bothhuman and software agents [21].

Figure 1. Brahms Agent Architecture

Figure 1 shows the architecture of a Brahms agent.Each Brahms agent runs as a separate Java threadwithin the discrete-event Brahms Virtual Machine. ABrahms agent has a belief-driven inference engine thatcontinuously monitors the changes and/or creation ofbeliefs that occur in the agent’s declarative memory.Every belief change triggers an evaluation of possibleframe activations in the agent’s procedural memory.The procedural memory consists of two types offrames (i.e. rules): workframes and thoughtframes.Thoughtframes are forward-chaining production rulesthat take no simulated time to fire. Workframes, on theother hand, are forward-chaining rules that callactivities that take simulated time. Consequently,workframes take simulated time to execute.

With every discrete-event change in the agent’sdeclarative memory, a number of workframes and/orthoughtframes have the potential of firing. Thesebecome part of the workframe- and thoughtframestacks. The thoughtframe stack uses a simple thoughtframe priority schema to select the currentthoughtframes to fire in the current clock tick. Incontrast, the workframe stack has a complex conflictresolution schema that selects the agent’s currentactivity, using a workframe and activity state-transitionmodel.

Finally, Brahms allows for modeling theenvironment and its state as facts in the World FactsModel (WFM). Through a reactive method, agents can

detect facts in the world state, modeling an agent’sperception. Detected facts become beliefs added to theagent’s declarative memory. However, fact detection isactivity-context specific so that not every fact detectedby the agent. Agents, through the execution of actionsin the world can also change the state of the world bycreating or changing facts in the WFM. A morecomplete explanation of how Brahms works can be infound in [15].

5. Naïve Design

ValueAssessment

TMUAgent

TMUAgent

TMUAgent

TMUAgent

TMUAgent

PilotAgent

TMUAgent

TMUAgent

TMUAgent

TMUAgent

TMUAgent

FlightAgent

IssueIdentification

AirspaceModel

GlobalOptimization

RouteSelection

RouteCreation

TMUAgent TMU

Agent

TMUAgent

AOCAgent

Brahms

Figure 2. Naïve Simulation D e s i g n . Allsimulation components are implemented in the Brahmslanguage. Blue ovals represent agents, with stacksabstractly representing the relative number ofinstantiations. Blue 3-D boxes represent significantreasoning modules. Green dashed ovals representcomplex state representation.

In our naïve simulation design, we implemented allthe simulation components directly in the Brahmslanguage (see Figure 2). Along with several minoragents, the simulation had four main agent types:

1. Pilot Agents. As the simulation began, each pilotagent would report for duty with theircorresponding AOC and transmit flight scheduleinformation (e.g., scheduled takeoff time,destination and arrival times) to the AOC. Theywould receive flight route assignments from theAOC when such were available, and fly the aircraftalong this route at the scheduled time.

2. Flight Agents. Though not deliberative agents,flight agents were created and given severalbookkeeping tasks, like reporting position andcalculating flight value information to the AOC.

3 . TMU Agent. The TMU agent served as themonitor of the airspace, detecting demand-capacityimbalances and broadcasting such information tothe AOCs. In the primary variation of thesimulation, the TMU would accept or reject flightroute requests from the AOC; in the othersimulation variations, the TMU agent would

assign routes instead of the AOCs, using either anoptimal or suboptimal strategy.

4. AOC Agents. The AOC agents are the airlines’interface to the FAA and communicateinformation such as flights, schedules, and flightvalue information, as well as receive anytransmitted information from the TMU. In theprimary simulation variant, the AOCs wouldselect routes for their flights, re-planning wheneverthose route selections were rejected by the TMU;in the other variants the AOCs had no direct rolein route selection. In an earlier version of thesimulation, the AOCs also created the flightroutes themselves, using a heuristic search tocombine path segments into a reasonable route tothe desired destination.

In addition to these agents, we also representedaspects of the environment (i.e. the airspace) as facts inBrahms, necessarily, so that the agents can detect factsin the environment and reason about them. Therefore,physical quantities such as waypoint position androute lengths were directly represented in the Brahmssimulation, along with incorporeal properties likecontroller workload and impacted areas.

Unfortunately, it was quickly apparent that thenaïve design would not yield a usable implementation.Though there was no explicit run time performancerequirement, an excessively slow simulation wouldlead to difficulties with debugging and furtherdevelopment. Even with only a partialimplementation, simulation runs were taking tens ofminutes, which was a real concern given the relativelylow level of complexity achieved.

6. Revised Design

We re-evaluated our design choices in order to addressthe efficiency problems we encountered. In thisredesign, we considered two issues: what we hadchosen to simulate, and how those components couldbe simulated.

6.1. Simulation Simplifications

Our focus in the initial simulation was to study theroute selection problem in collaborative andauthoritarian settings. Upon further reflection, it wasclear that the essential component was really theadvanced planning, and not the execution of the planitself. Correspondingly, we sought to simplify themodel by excluding portions that had real worldcounterparts, but were not pertinent to our currentfocus.

RouteCreationRouteCreation

RouteSelection

TMUAgent

TMUAgent

TMUAgent

TMUAgent

TMUAgent

AircraftObjects

IssueIdentification

AirspaceModel

GlobalOptimization

ValueAssessment

TMUAgent

TMUAgent

TMUAgent

AOCAgent

Brahms

FACET

Figure 3. Simulation Redesign. By simplifying,removing or redistributing simulation components, wewere able to reduce the run time of the simulation toacceptable levels.

We removed the Brahms pilot agents, as they didnot play an integral role in the planning phase, andchanged the flight agents to passive flight objects. Thebookkeeping and flight value computations weremoved from the flight to the TMU, partially forefficiency concerns, but also to avoid the situationwhere an AOC might artificially inflate flight values toget better treatment. Had we decided to preserve theexecution phase, we still could have eliminated ourpilot agents, as they robotically followed thecommands of the AOC and were not enriched by theBDI representation of Brahms.

Similarly, the route creation fell outside of theplanning phase, as a prior process that creates routes asinputs to planning. Instead of creating routes on thefly, we structured fixed routes before the simulationstarted. This meant that we only had to create theroutes once, rather than every time we ran thesimulation.

6.2. Implementation Choices

The remaining components were vital to thesimulation and could not be eliminated. However, notall components were justified in their use of a BDImodel. We had implemented a greedy algorithm tocreate a globally optimal selection of routes for flightsacross all airlines. The algorithm had not beendesigned to model the actual process a human wouldfollow to reach this globally optimal solution; it wasmerely created to serve as a point of comparison. Assuch, it was not necessary or even logical toimplement this function in a BDI framework; only theresulting solution was needed. Therefore, we used

Brahms capability to interface with Java1 to implementthe algorithm.

The other major implementation change was to relyon the simulation capabilities of FACET (see Section2) for many of the simulated components. Through theuse of Brahms Java agents and the FACET Java API,we were able to utilize the optimized simulationcapabilities of FACET for the airspace environmentmodel instead of our own implementation. However,the agents in our simulation do reason over aspects ofthe airspace; this required a representation of the salientfeatures in the BDI framework. Great care was taken toonly represent the airspace components that were trulyneeded for agent decision making, and suchcomponents were represented in the most abstract (i.e.,compact) form possible. In some cases, such as theidentification of the demand-capacity imbalance, theprocessing was done in FACET (and supporting Javacode) and only the outcomes were represented in thecorresponding agent’s belief model.

Our implementation of the resulting redesign wasseveral times faster than our partial implementation ofthe naïve design. Not only did our revisedimplementation include components that our initialimplementation lacked, but also did so at a higherlevel of fidelity, due to our use of FACET.

7. Discussion

The inefficiencies of our initial design whereprimarily caused by our overuse of the BDI paradigmin the simulation. The choice to model both pilots andflights as agents meant that there would be hundreds ofsuch agents, far more than all other agents in thesimulation combined. In Brahms, like many otherBDI-based agent languages, each agent corresponds toa separate processing thread [22]. Each agent mustcontinuously monitor and process events that trigger areaction (e.g., detection of a relevant facts in the worldstate or communication of beliefs by other agents),slowing the process considerably (also notedincidentally in [23])

Pilots and flight agents were not essential to oursimulation goals and were somewhat easily eliminated,but other elements were vital (such as a model of theairspace and optimization routines). However, werealized that we had resorted to using the BDIparadigm as if it were an imperative programminglanguage. Outside of programming convenience, wecould not justify the use of the BDI paradigm todevelop models for “non-thinking” entities such as the

1 There are two ways to interface with Java in Brahms. Both

make use of the extensive Java API: 1) Java activities are agentactions implemented in Java, 2) Java agents are “agentified” Javaobjects implemented completely in Java that other Brahms agentscan communicate beliefs with. Brahms Java agents do not have aninference engine as shown in Figure 1.

airspace and airplanes [24]. Also, it made little senseto model complex decision making with the BDIframework when we were neither interested norinformed of the actual steps of the process.

In our experience, the most effective approach formost simulation is thus to combine BDI agents andnon-BDI components to satisfy simulationrequirements. We suggest the following guidelines toaddress efficiency issues, in our order of decreasingpreference:

1. Use BDI for explicit cognitive processes. TheBDI paradigm is an excellent choice whenmodeling well-understood decision making. Onthe other hand, other simulation techniques arebetter suited for modeling physical and likewiseprocesses that are not analogous to the reasoningsupported by BDI. Also, decision-makingprocesses whose details are not understood are notwell served by a full BDI implementation, as weobserved in our optimized route selection process.In such cases an algorithmic approach, as opposedto a model-based symbolic approach is often moreefficient.

2 . Scope the simulation carefully. Includingelements in the simulation that do not supportsimulation goals can adversely affect thesimulation. When building a simulation, there isa natural tendency to include whatever entities areinvolved in the real world, so care must be takenwhen choosing what to model. In addition, thelevel of granularity for modeling processes isimportant; there is no need to model the details ofa decision-making process when you are onlyconcerned with the outcome, rather than theprocess itself. Careful scoping is a generalprinciple independent of efficiency. However, it isespecially important to reconsider functionalitythat is causing serious performance problems.

3 . Consider the execution properties of thelanguage. Every BDI implementation eventuallyturns into code executing on a computer, andunderstanding the algorithmic properties issometimes necessary. In Brahms, we found that astraightforward expression of multiplepreconditions can lead to a combinatorialexplosion in execution time; by considering howthe underlying simulation engine executed it, wewere able to create a logically equivalent formwith vastly superior performance. Similarly, asperformance degrades with the number of agentsintroduced, it is sometimes beneficial to combineprocesses from multiple agents into a single agent(see Figure 4). However, since these techniquesgenerally decrease readability and correspondencewith the real world, we recommend using themonly as a last resort.

0

2000

4000

6000

8000

10000

12000

14000

1

10

100

200

500

700

800

900

1000

1100

1200

1300

1400

1500

Number of Flights

Ru

nti

me(S

eco

nd

s)CentralDistributed

Figure 4. F l ight Value Computat ionEfficiency. Using distributed agents to calculateflight value resulted in an exponential increase incomputational time as the number of flights increased.The same operation, calculated centrally, had superiorperformance characteristics.

8. Future Work

Efficiency is likely to remain a concern as weexpand the simulation to more accurately reflect theproposed CTFM concept. Consider the fact that tosimulate the entire NAS the simulation needs to dealwith more than 50,000 flights per day, 26 TMUsorganizations and tens of AOCs. We believe that theguidelines presented in this paper will help us avoidmany of the potential efficiency problems we mightotherwise encounter. Specifically, we plan to expandour simulation in several ways:1 . Expand simulation scope. Our initial

simulation efforts focused entirely on the TFMplanning phase, but the complete CTFM conceptcovers several phases that influence each other. Aswe shift to this multiphase model, the dynamismin the airspace environment will play a vital role.Fortunately, by integrating FACET into oursimulation, we will be able to make use of ahighly optimized airspace simulator. Our designchallenge changes from creating an airspacesimulator to deciding how to efficiently transmitinformation between the two simulations. Mostlikely, careful scoping will be necessary.

2. Increase decision making fidelity. Initially, wehave only modeled simple decision-makingprocesses in our simulation. In reality, thedecision-making processes followed by thecorresponding real life entities are neither simple,well understood nor publicly available. Accuratemodeling of decision making is necessary foroverall simulation fidelity and remains a

challenge. One possibility is to use historical dataand learning techniques to induce a model. In anycase, since we are neither likely to learn thedetailed steps of such decision making, nor are weinterested in validating that process, we willmodel such processes at a large-grained levelwithout using BDI internally to arrive at theresulting decision.

3. Increase simulation size. TFM issues range fromthose local to a sector or airport to ones that aretruly national in scope. Even at the local level amajor airport will have hundreds of flights fromtens of different carriers. To date, our simulationshave included only a handful of agents (asmeasured in our redesign), but we must scale upto a much larger number to simulate other typesof TFM issues. There is a “breaking point” inevery simulation were it is no longer feasible toincrease the size of the simulation. This pointmay come earlier in BDI systems that use asophisticated level of processing for each agent.One possibility, supported by Brahms, is todistribute the simulation amongst severalcomputers, though this introduces new issues ofcomplexity and limited hardware. In the end,though, it may not be feasible to create a full-sized simulation of CTFM involving thousandsof BDI agents using existing simulation packagessuch as Brahms.

4. Modeling of Organizations. We will increase thefidelity of the simulation of the human decisionmaking by modeling the roles and role interactionin the different organizations, both for TMUs andAOCs.

5 . Systematic Performance Investigation. Athorough empirical study of the performancecharacteristics of the different design choiceswould yield quantitative results that may informfuture design decisions. Specifically, we intend torun a series of experiments that compare the runtime properties of different options. One possibleexperiment is to contrast the efficiency of acomplex algorithm implemented in a BDIframework and the same algorithm implementedin a procedural language (such as Java).

9. Acknowledgements

The authors would like the NGATS ATM-Airspaceproject for their support of this work, as well asFrancis Enomoto, Dr. Karl Bilimoria and Bart-Jan vanPutten for their contributions to the work andcomments.

10. References

1. Federal Aviation Administration, FAA Long-Range Aerospace Forecasts Fiscal Years 2015,2020 And 2025. 2000.

2. Idris, H., et al. Field Observations o fInteractions Between Traffic Flow Managementand Airline Operations. in AIAA 6th Aviation,Technology, Integration, and OperationsConference (ATIO). 2006. Wichita, Kansas.

3. Idris, H., et al. Operational Concept forCollaborative Traffic Flow Management basedon Field Observations. in AIAA 5th Aviation,Technology, Integration, and OperationsConference (ATIO). 2005. Arlington, Virginia.

4. Yilmaz, L., T. Ören, and A. Nasser-Ghasem,Agents, Simulation, and Gaming. Simulationand Gaming Journal, 2006. 37(3): p. 339-349.

5. Sweet, D.N., et al. Fast-Time Simulation Systemfor Analysis of Advanced Air TransportationConcepts. in AIAA Modeling and SimulationTechnologies Conference and Exhibit. 2002.Monterey, California.

6. Couluris, G.J., et al. National Airspace SystemSimulation Capturing the Interactions of AirTraffic Management and Flight Trajectories. inAIAA Guidance, Navigation, and Control (GNC)Conference. 2003. Austin, Texas.

7. Corker, K.M., Human Performance Simulation inthe Analysis of Advanced Air TrafficM a n a g e m e n t , in I999 Winter SimulationConference, P.A. Farrington, et al., Editors. 1999.

8. Keith C, C., et al., Modeling Distributed HumanDecision-Making in Traffic Flow ManagementOperat ions , in 3rd USA/Europe Air TrafficManagement R&D Seminar. 2000: Napoli, Italy.

9. Tumer, K. and A. Agogino, Distributed Agent-Based Air Traffic Flow Management, in AAMAS2007. 2007: Honolulu, Hawaii. p. 330-337.

10. Hogan, B. and L.A. Wojcik, Traffic FlowManagement Modeling and OperationalC o m p l e x i t y , in 2004 Winter SimulationConference, R.G. Ingalls, et al., Editors. 2004.

11. Bilimoria, K., et al. FACET: Future ATMConcepts Evaluation Tool. in 3rd USA/EuropeATM 2001 R&D Seminar. 2000. Napoli, Italy.

12. Smith, P., et al., The design of FACET to supportuse by airline operations centers. 2004, IEEE.

13. Flight Explorer , Flight Explorer Inc.:http://www.flightexplorer.com/ .

14. Wolfe, S.R., et al. Comparing Route SelectionStrategies in Collaborative Traffic FlowManagement. in Intelligent Agent Technology(IAT 2007). 2007. Fremont, CA, USA: IEEE press.

15. Sierhuis, M., W.J. Clancey, and R.v. Hoof,Brahms: A multiagent modeling environment forsimulating work processes and practices.International Journal of Simulation and Process

Modelling, Inderscience Publishers, 2007. 3(3):p. 134-152.

16. Clancey, W.J. The advantages of abstractcontrol knowledge in expert system design. inAAAI-83. 1983.

17. Clancey, W.J., Heuristic Classif ication.Artificial Intelligence, 1985(27): p. 289-350.

18. Clancey, W.J., et al., Brahms: Simulatingpractice for work systems design. InternationalJournal on Human-Computer Studies, 1998. 49:p. 831-865.

19. Garcia-Chico, J.-L., et al., Collaboration forMitigating Local Traffic Flow Management(TFM) Constraints due to Weather, Special UseAirspace (SUA), Complexity, and ArrivalMeter ing: Prototype Algori thms forCollaborative TFM. 2007, L-3 Communicationsand Metron Aviation: Billerica, MA

20. Sierhuis, M., “It’s not just goals all the waydown” – “It’s activities all the way down” inLNAI 4457: Engineering Societies in the AgentsWorld, Seventh International Workshop(ESAW'06) . 2007, Springer-Verlag: Dublin,Ireland. p. 1-24.

21. Sierhuis, M., Modeling and Simulating WorkPractice; Brahms: A multiagent modeling andsimulation language for work system analysisand design, in Social Science Informatics (SWI).2001, University of Amsterdam, SIKSDissertation Series No. 2001-10: Amsterdam,The Netherlands. p. 350.

22. Bordini, R.H., et al., eds. Multi-AgentProgramming: Languages, Platforms andApplications . Multiagent Systems, ArtificialSocieties, and Simulated Organizations, ed. G.Weiss. 2005, Springer Science+Business Media,Inc.: New York, NY.

23. Thangarajah, J., L. Padgham, and J. Harland,Representation and reasoning for goals in BDIa g e n t s , in Australasian conference onComputer science. 2002, Australian ComputerSociety, Inc: Melbourne, Australia.

24. Wooldridge, M.J. and N.R. Jennings, SOFTWAREENGINEERING WITH AGENTS: Pitfalls andPratfalls. IEEE Internet Computing, 1999. 3(3):p. 20-27.