P L A N N I N G

O-P3: Supporting the PlanningProcess using Open PlanningProcess PanelsJohn Levine, Austin Tate, and Jeff Dalton, University of Edinburgh

R EAL-WORLD PLANNING IS Acomplicated business. It is a multiuser, mul-tiagent collaboration in which teams of peo-ple must explore different options to syn-thesize a solution to given requirements.Specifically, the planning process is the exe-cution of a plan—agents act in parallel, shar-ing resources, communicating results, and soon. We can make this planning processexplicit and use it as a central device forworkflow coordination and visualization—we used this idea to create Open PlanningProcess Panels (O-P3).

O-P3 can coordinate the workflow betweenmultiple agents and visualize the developmentand evaluation of multiple courses of action(COAs). We have used O-P3 to implement tworeal applications—the Air Campaign PlanningProcess Panel (ACP3) and O-Plan, a two-user,mixed-initiative Web demonstration of plan-ning. In ACP3, O-P3 helps build a visualiza-tion panel for a complex multiagent planningand evaluation demonstration (TIE 97-1),which uses 11 different software componentsand involves several users. In O-Plan, O-P3

technology enables the development and eval-uation of multiple COAs by a commander, aplanning staff member, and an O-Plan auto-mated planning agent.

O-P3 technology could impact severalimportant research areas. We envision O-P3

being used for a planning system in which ateam of people and a collection of computer-

based planning agents act together to solvea difficult real-world planning problem. Boththe human and the system agents act in givenroles and are constrained by what they areauthorized to do, but they also have the abil-ity to work under their own initiative and vol-unteer results when this is appropriate. Whenthe planning process is under way, the agentstypically work on distinct parts of the plansynthesis in parallel. The agents can alsowork in parallel to explore different possiblecourses of action. For example, while oneCOA is being evaluated, another two mightbe in the process of being synthesized.

O-P3 technology

The generic O-P3 is based on an explicitmodel of the planning process, which is

encoded using an activity modeling language(such as IDEF3) that represents the planningprocess as a partially ordered network ofactions. Some actions have expansions downto a finer level of detail (such as to anotherpartially ordered network).

The purpose of O-P3 is threefold: to dis-play the planning process’s node status to theusers, to let users compare the planningprocess products (such as the COAs), and tocontrol the next steps on the “workflowfringe”—the next possible actions, given theplanning process’s current status. In the con-text of creating plans, we designed O-P3 toallow the development of multiple COAs andthe evaluation of those COAs using variousplan evaluations.

A generic O-P3 panel has any of a numberof subpanels, which we can tailor to supportspecific users or user roles. These include

THE AUTHORS INTRODUCE OPEN PLANNING PROCESS

PANELS, WHICH ARE BASED ON EXPLICIT MODELS OF THE

PLANNING PROCESS AND CAN COORDINATE THE DEVELOPMENT

AND EVALUATION OF MULTIPLE COURSES OF ACTION. THIS

WORK HAS AN IMPACT ON A NUMBER OF IMPORTANT

RESEARCH AREAS OUTSIDE OF PLANNING, INCLUDING

WORKFLOW SUPPORT.

56 1094-7167/00/$10.00 © 2000 IEEE IEEE INTELLIGENT SYSTEMS

• a COA comparison matrix that showsCOAs versus elements of evaluation; stepstatus in the planning process; and theoutstanding issues for a COA that is beingsynthesized, which an agent must addressbefore the COA is ready to execute;

• a graphical display showing the planningprocess’s status as a Program EvaluationReview Technique (PERT) chart; and

• other visualizations, such as bar charts,intermediate process product descrip-tions, and textual plan descriptions.

The generic O-P3 methodology for build-ing the Open Planning Process Panels con-sists of these steps, which the softwaredesigner carries out:

1. Consider the agents (human and sys-tem) involved in the overall planningprocess, then assign roles and authori-ties to those agents.

2. Construct a planning-process activitymodel that shows the partial orderingand decomposition of the actions andwhich agents can carry out whichactions.

3. Build a model of the planning process’scurrent state and an activity monitor,which will update this state model asactions in the planning process takeplace.

4. Construct appropriate O-P3 interfaces foreach human agent in the planningprocess, taking into account the role itplays in the interaction. This means thateach user role will have an O-P3 interfacethat is tailored to the task’s overall nature.

Generic O-P3 design rules inform O-P3

interface construction. Each user role in theplanning process is provided with a panelthat the software designer has tailored to thatrole’s activities and needs. The designer thenassigns each user role a color to distinguishbetween the roles. This color serves, forexample, as a background for the panel’sheader. Because a given user might act inmore than one distinct user role, this providesa useful visual cue as to which user role isbeing enacted at any one time.

The generic O-P3 panel consists of threeparts: a graph subpanel (PERT chart), a matrixsubpanel (COA comparison matrix), and othersubpanels (such as information on assumedenvironmental conditions). The graph sub-panel and the other subpanels are optionalitems, depending on how useful they are for a

given application. The graph subpanel con-tains a partially ordered graph that shows theplanning process’s activity model. Becausethe activity model might be large and mightapply for each COA being developed, show-ing the whole network might not be possible,so the users might need some sort of naviga-tion based on decompositions and switchingbetween COAs.

The actions shown in the graph subpanelare annotated with colors to show their cur-rent status in the state model. We haveadapted the colors from other ARPI(DARPA/Rome Planning Initiative) planvisualization work.1 The matrix subpanel is atable that contains two types of rows and twotypes of columns. The rows are process steps(verb phrases) and COA descriptors (nounphrases). The process step labels are coloredwith the user role background color, and theCOA descriptors are white. The columns arethe individual COAs being developed(labeled COA-N) and a column reflecting theoverall workflow (labeled Overall).

The matrix subpanel’s process steps are anappropriately flattened form of the planningprocess’s activity model. O-P3 can show theaction status, using the same colors as in thegraph subpanel. Clicking on a hyperlinkshows the currently active workflow fringe(what step we can do next). The rows havethree sections, running from top to bottom.

The first section deals with process stepsbefore plan synthesis, such as setting theCOA requirements. The middle section con-sists of the COA descriptors and is filled outwhen a COA has been synthesized. The finalsection consists of process steps that comeafter plan synthesis, such as addressing anyoutstanding issues and viewing the resultingCOA in various ways.

The COA descriptors relate to the COAproducts the planning process’s steps pro-duce, such as the plan’s minimum durationand its effectiveness. Separate plan evalua-tors, simulators, and so forth can provide thedescriptors. Users can select the COAdescriptors to show only the critical elementsof evaluation. Colors can show whether theresult is acceptable and raises no issues(green), is possibly acceptable but has someissues to note (orange), or is not acceptableunless the user relaxes the initial require-ments (red).

The other subpanels can contain additionaluseful information such as tables showingthe COA objectives and assumed environ-mental conditions for each COA.

As mentioned at the start of this article, theO-P3 agent interfaces let human agents playtheir parts in the overall planning process,alongside the system agents, which includeAI planners, schedulers, plan evaluators, andso on (see Figure 1).

SEPTEMBER/OCTOBER 2000 57

Task assigner

Web or directcollaboration

Agent interface

Cooperation andcommunication

Agent interface

Agent interface Agent interface

Plan evaluators Planning agents

Planner user

Figure 1. Using O-P3 interfaces.

Application 1: ACP3

The ARPI TIE 97-1 demonstrationbrings together 11 separately developedsoftware systems for planning and planevaluation. When the demonstration runs,these systems work together to create andevaluate multiple courses of action in thedomain of air campaign planning. The sys-tems communicate with each other byexchanging KQML messages. In theory, wecould discover what’s happening at anygiven time by watching these messages, butthis is obviously less than ideal becausethese messages use technological terms thatare far removed from the user community’sterminology.

Our aim was to use O-P3 technology tobuild a visualization component for thisdemonstration, which would let the targetend users view the planning process’s cur-rent state in terms with which they are famil-

iar. This has resulted in ACP3—the Air Cam-paign Planning Process Panel.

Modeling the planning process. We candescribe TIE 97-1’s software componentsas performing activities such as planning,scheduling, simulation, and plan evalua-tion. We could discuss hierarchical task net-work planning and Monte Carlo simulationmethods, but end users are more likely toconceive of the processes of air campaignplanning in more general, domain-relatedterms, such as “develop JFACC guidance”and “create support plan.” Building mod-els of the planning process, which are tra-ditionally rooted in established ACP termi-nology, can bridge the gaps in terminologyand in description levels. We therefore usedthe previously elicited and verified ACPprocess models2 as our source of terminol-ogy and as the basis of our IDEF3 modelsfor TIE 97-1’s planning process. The full

models we used for building ACP3 appearelsewhere.3

Building ACP3. Figure 2 shows the ACP3

viewer. As we stated earlier, ACP3 tracks theoverall planning process and displays this tothe viewers of the ARPI TIE 97-1 demonstra-tion in a meaningful way using appropriatemilitary process terminology. The planningprocess appears in two separate subpanels.The tabular COA comparison matrix showsCOAs being developed (columns) against atree-based view of the planning process. Thegraph viewer subpanel shows the planningprocess as a PERT network. Because the plan-ning process consists of many nodes withexpansions, the graph viewer can only displayone graph from the planning process for oneCOA. Users can reach other graphs by click-ing on nodes with expansions, and they canchoose which COA to view.

The two views are required because theplanning process in TIE 97-1 is complex. Youcan see the whole process for every COA inthe COA matrix, but information about thepartial ordering of the actions in a graph islost when ACP3 converts the graph to a treestructure. The graph viewer shows the fullpartial ordering, but space considerationsmean that the system can show only a singlegraph for a single COA at one time.

The ACP3 process monitor works by watch-ing for certain KQML messages, which it canrelate to the status of certain nodes in the ACPprocess models. As the demonstration pro-ceeds, the status of actions in the modelprogress from not yet ready to execute (white),to ready to execute (orange), to executing(green), and finally to complete (blue). Thefinal column in the COA matrix is labeled“Overall” and summarizes the overall statusof the COA creation and evaluation process.

The panel is written entirely in Java toform the basis for future Web-based processeditors and control panels.

Application 2: O-Plan

The O-Plan project4,5 is concerned with sup-porting multiagent mixed-initiative planning.The current O-Plan Web demonstration showsinteraction between two human agents and onesoftware planning agent (the O-Plan planserver). The overall concept for our demon-strations of O-Plan as it acts in a mixed-initia-tive multiagent environment is to have humansand systems work together to populate the

58 IEEE INTELLIGENT SYSTEMS

Figure 2 . The ACP3 viewer.

O-P3 interface’s COA matrix component.As Figure 3a shows, we envision two

human agents acting in the user roles of taskassigner and planner user, working togetherto explore possible solutions to a problemand using automated planning aids to do so.Figure 3b shows how the two human agentswork together to populate the matrix. TheTA sets the requirements for a particularCOA (such as what top-level tasks users willperform), selects appropriate evaluation cri-teria for the resulting plans, and decideswhich COAs to prepare for briefing. The PUworks with O-Plan to explore and refine thedifferent possible COAs for a given set oftop-level requirements. The two users canwork in parallel, as the example scenariodemonstrates.

The overall planning task is thus sharedamong three agents who act in distinct userand system roles. The TA is a commanderwho is given a crisis to deal with and whoneeds to explore some options. This personwill receive field reports on the developingcrisis and environmental conditions. The PUis a staff member who provides the TA withplans that meet the specified criteria. In doingso, the PU uses the O-Plan automated plan-ning agent, which generates plans for the PUto see. The PU will typically generate a num-ber of possible COAs using O-Plan and willonly return the best ones to the TA.

For our current demonstration, we use ageneral-purpose logistics and crisis opera-tions domain, which is an extension of ourearlier Non-Combative Evacuation Opera-tions and logistics-related domains.6 Thisdomain, together with the O-Plan Task For-malism implementation, is described in detailelsewhere.5

Each human user has an O-P3 panel,which is implemented using a CGI-initiatedHTTP server in Common Lisp and whichcan therefore run on any Web browser. TheCommon Lisp process returns standardHTML pages. This way of working hasmany advantages:

• each user can use a different type ofmachine (Unix, PC, Mac) and run a dif-ferent type of Web browser (Netscape,Internet Explorer, Hotjava, and so on);

• the only requirement for running O-Planis a Web connection and a Web browser(no additional software installation isneeded); and

• the two users can be geographically sep-arate—in this case, voice communication

through telephone or teleconferencing isall that is required besides the linked O-P3 interfaces.

Software designers make the planningprocess for the TA and the PU explicit throughthe hypertext options displayed in the processparts of the O-P3 panels. The options are notpresent (not ready to run yet), active (on theworkflow fringe), or inactive (completed). Fur-ther parts of the planning process are driven byissues that O-Plan or the plan evaluation agentscan raise about a plan under construction, andwhich either or both of the human agents canhandle. Because the planning process is madeexplicit to the two users through these twomechanisms, other visualizations of the plan-ning process are not required. However, theplanning process’s products (the COAs) arecomplex artifacts for which multiple views areneeded. In the current version, the user canview the COAs as a PERT network, a textualnarrative, or a plan-level expansion tree (all atvarious levels of detail).

The user roles are arranged such that theTA has authority over the PU, who in turnhas authority over O-Plan. This means thatthe TA defines the limits of the PU’s activ-ity, and the PU then acts within those boundsto define what O-Plan can do. Other aspectsof what the two users are authorized to do aremade explicit by the facilities included intheir respective panels.

The COA comparison matrix. Figure 4shows the two panels for the TA and PU. Eachuser controls the plan evaluation elements(which are shown) to enable the user to choosecritical elements of evaluation. In the examplescenario given later, the TA is only interestedin the minimum duration and the effectiveness,so the TA only selects these. However, the PUwants a variety of data to pick the best COA,so the PU shows all evaluations.

The TA sets up the top-level requirementsfor a COA. Once this is done, the TA passesthe COA across to the PU, whose matrix isinitially blank. The PU then explores a range

SEPTEMBER/OCTOBER 2000 59

Task directionand plan analysis

Plan developmentand refinement

Task assigner

Option: COA-2Authority: ...Order issued: ...

Phase: DeploymentOption: COA-2Planning workflow

...

Criterion 1

Criterion 3Criterion 2

COA-2 COA-3COA-1

Plan view

WorldView

..

Planneruser

Task assigner

Set requirements

Set requirements

Element of evaluation 1Element of evaluation 2

COA1

Set requirementsPlanner user

Refine plans

(b)

(a)

COA2 COA3

Figure 3. (a) Communication between and (b) the roles of the task assigner and the planner user.

of possible COAs for the specified require-ments and returns the best ones to the TA.When the PU returns a COA to the TA, thecolumn for that COA appears in the TA’smatrix. The PU and the TA can work in par-allel, as we show in the next section.

Demonstration scenario. The O-Plan Webdemonstration illustrates mixed-initiativeinteraction between two human agents andone system-planning agent engaged in devel-oping multiple qualitatively different COAs.O-P3 interfaces are provided for the twohuman users that are tailored to their roles.The following scenario illustrates how weenvision the system being used.

Initial situation and preparations. The actiontakes place on the fictional island of Pacifica,with emergencies planned for the cities ofAbyss, Barnacle, and Calypso. The TA is toldto deal with injured civilians at the threecities within the next 18 hours. Plans are onlyacceptable if their effectiveness is 75% orgreater. The weather forecast gives a 50%chance of a storm within the next 24 hours(see Figure 5a).

The TA sets up the default situation, set-ting the time limit to 18 hours. The weatherand road situations keep their default values,pending more accurate reports.

COA-1. The TA first explores the option ofevacuating the injured from all three cities inclear weather. The TA passes the COArequirements directly to the PU. The PU gen-erates a plan is that executes in 12 hours andis 77% effective, which is acceptable. Theplan has three issues outstanding. The PUaddresses these and returns the plan to the TA.

COA-2. The TA then sets up a second COAwith the same evacuation tasks but this timeassumes stormy weather to check for all even-tualities. The TA passes this new set of COArequirements to the PU. The first plan gener-ated takes 21 hours and is 61% effective, bothof which are unacceptable. The PU asks theO-Plan planner for an alternative plan. Thenew plan (COA-2.2) executes in 16 hours andis 75% effective, both of which are acceptable.The PU returns COA-2.2 to the TA and deletesCOA-2.1. At this point, the TA has an accept-able plan for both clear and stormy conditions.

Developing situation. The Barnacle field sta-tion now contacts the TA. Reports are com-ing in of an explosion at the power station,causing a gas leak. This is believed to be dueto a terrorist bomb, so it seems wise to fix thegas leak and send in a bomb squad to defuseany remaining bombs. Meanwhile, the latestweather report indicates that a storm is brew-ing and has a 95% chance of hitting the island(see Figure 5b).

COA-2.2.2. To deal with this turn of events, theTA splits COA-2.2 (the realistic weatherassumption) into two suboptions and adds twonew tasks to COA-2.2.2—to repair the gas leakat Barnacle and send a bomb squad to Barna-cle. COA-2.2.2 is now passed to the PU.Because the original COA-2.2 took 16 hours,the PU turns the schema choice on, to have finecontrol of the two new tasks added to the exist-ing plan. The PU has the option of using fast orslow vehicles for the two tasks and chooses fastvehicles. However, this plan takes 22 hours andis 63% effective. The PU replans and choosesa mixture of fast and slow vehicles for the“repair gas leak” task and a fast vehicle for the“defuse terrorist bomb” task. Although better,

60 IEEE INTELLIGENT SYSTEMS

Figure 4. The (a) task assigner’s panel and (b) planner user’s panel.

(a) (b)

the new plan now takes 19 hours and is 68%effective. The TA is getting impatient and tellsthe PU, “This is taking too long. Just give methe best one so far.” The PU returns COA-2.2.2.2, keeping COA-2.2.2.1 for further back-office work.

COA-3. The TA decides to send medicalteams to the three cities to deal with theinjured civilians rather than evacuating them.After updating the default situation to reflectthe weather report, the TA starts to set upCOA-3 with these tasks, and so begins todefine the requirements on the screen.

COA-2.2.2.3. Meanwhile, the PU has contin-ued to explore the possibilities for COA-2.2.2.The plan improved when the PU used someslow vehicles in the plan, most likely becausethe limited number of fast vehicles are repeat-edly in use, resulting in a longer (more lin-ear) plan. The PU presses “Replan” andchooses to use a slow vehicle in the “defuseterrorist bomb” task. Sending the bomb squadis only a precaution—using the limited num-ber of fast vehicles for evacuating the injuredand fixing the known gas leak seems like agood idea. The PU is right—the resulting planexecutes in 16 hours and is 80% effective.Viewing the plan shows that this plan hasgood parallelism. The PU now addresses theissues raised by COA-2.2.2.3 and returns thisplan to the TA, saying, “I think I’ve fixed theproblem with COA-2.2.2.”

Back to COA-3. The TA sees the new plan:“This looks good; now see what you can do

with COA-3 as an alternative.” The PU (stillin the “ask user” schema selection mode)selects the fast vehicle option for four of thetasks but selects a slow vehicle for the “defuseterrorist bomb” task. The resulting plan exe-cutes in 12 hours and is 79% effective.

Choice of COA. The TA now has a choicebetween COA-2.2.2.3 and COA-3. AlthoughCOA-3 takes four hours less, it is slightly lesseffective; more important, it only sends med-ical teams to the three cities rather than evac-uating the injured people. The TA could nowexamine other details of the two plans, usingthe plan views and the other elements of eval-uation, to make an informed choice betweenthe two or plan further.

THE ACP3 AND THE O-PLAN WEBdemonstration of crisis response planninghave an explicit planning-process notion:multiagent interaction. The agents in bothsystems have roles that relate to the actionsusers can carry out in the planning process.Both systems use a COA matrix, whichshows possible steps in the planning processfor each course of action being developed. InACP3, we use this as a visualization device.In the O-Plan demonstration, the populationof this matrix is central to the mixed-initiativeinteraction between the TA, PU, and O-Plan.

An O-P3 process panel is being built as

part of the Coalition Agents Experiment(CoAX) under DARPA’s Control of AgentBased Systems program. This panel willinclude the matrix subpanel and the graphsubpanel from ACP3. However, the CoAXpanel will likely include new subpanels toprovide a “process product” perspective(showing the status of various informationproducts under development) and new sub-panels that give more role-specific workflowstatus for a number of user types. The maininnovation in the CoAX panel will featurehooks to allow AI planning technology fordynamically generating and adapting theplanning process to accommodate changingrequirements and situations. We have alreadydemonstrated such an intelligent workflowplanning aid using O-Plan for the air cam-paign planning process.7

AcknowledgmentsDARPA and the US Air Force Research Labo-

ratory at Rome (AFRL) supported this work undergrant number F30602-95-1-0022. The US Gov-ernment and the University of Edinburgh areauthorized to reproduce and distribute reprints fortheir purposes, notwithstanding any copyrightannotation hereon. The views and conclusions con-tained herein are those of the authors and shouldnot be interpreted as necessarily representing offi-cial policies or endorsements, either express orimplied, of DARPA, AFRL, the US Government,or the University of Edinburgh.

SEPTEMBER/OCTOBER 2000 61

Figure 5. The (a) initial and (b) developing situations.

(a) (b)

Injured atBarnacle

50%chance

95%chance

Injured atBarnacle

Explosion

Injured atCalypso

Injured atCalypso

Injured atAbyss

Injured atAbyss

References1. J. Stillman and P. Bonissone, “Technology

Development in the ARPA/RL Planning Ini-tiative,” Advanced Planning Technology, A.Tate, ed., AAAI Press, Menlo Park, Calif.,1996, pp. 10–23.

2. B. Drabble, T. Lydiard, and A. Tate, ProcessSteps, Process Product and System Capabil-ities, Initiative Support and ACPT TestbedTech. Report ISAT-AIAI/TR/4, AI Applica-tion Inst., Univ. of Edinburgh, 1997.

3. S. Aitken and A. Tate, Process Modelling ofthe TIE 97-1 Demonstration: Modelling Com-plex Techniques Using ACP Terminology,ISAT Tech. Report ISAT-AIAI/TR/6, AIApplication Inst., Univ. of Edinburgh, 1997.

4. B. Drabble, A. Tate, and J. Dalton, ACPProcess Management: O-Plan IFD-5 Quali-fier, O-Plan Tech. Report ARPA-RL/O-Plan/TR/30, AI Application Inst., Univ. ofEdinburgh, 1996.

5. A. Tate, J. Dalton, and J. Levine, “Generationof Multiple Qualitatively Different PlanOptions,” Proc. Fourth Int’l Conf. AI Plan-ning Systems (AIPS ’98), AAAI Press, MenloPark, Calif., 1998, pp. 27–34.

6. G.A. Reece et al., “The PRECIS Environ-ment,” paper presented at the ARPA-RL Plan-ning Initiative Workshop at AAAI ’93, Wash-ington D.C., July 1993; www.aiai.ed.ac.uk/~oplan/documents/1993/93-arpi-precis.ps(current Oct. 2000).

7. A. Tate, B. Drabble, and J. Dalton, “O-Plan:A Knowledge-Based Planner and Its Appli-cation to Logistics,” Advanced Planning Tech-nology,A. Tate, ed.,AAAI Press, Menlo Park,Calif., 1996, pp. 259–266.

John Levine is a senior research fellow at the Uni-versity of Edinburgh’s Artificial Intelligence Appli-cations Institute, working on AI planning systemsand natural language generation. His currentresearch program consists of interfaces to plan-ning systems, issue-based and mixed-initiativeplanning systems, and the application of geneticalgorithms and genetic programming techniquesto planning problems. He has an MA in computerscience, an MPhil in computer speech and lan-guage processing, and a PhD in natural languageprocessing, all from the University of Cambridge.Contact him at AIAI, Div. of Informatics, Univ. of

Edinburgh, 80 South Bridge, Edinburgh EH1 1HN,UK; j.levine@ed.ac.uk.

Austin Tate is technical director of AIAI and holdsthe Personal Chair of Knowledge-Based Systemsat the University of Edinburgh. As well as engag-ing in the research, development, and applicationof knowledge-based methods, he also has a back-ground in databases and software engineering. Hegraduated from the University of Lancaster with adegree in computer science and has a PhD inmachine intelligence from the University of Edin-burgh. He is a Fellow of the Royal Society of Edin-burgh, a Chartered Engineer, and an elected Fellowof the AAAI. Contact him at AIAI, Div. of Infor-matics, Univ. of Edinburgh, 80 South Bridge, Edin-burgh EH1 1HN, UK; a.tate@ed.ac.uk.

Jeff Dalton is a senior computer scientist at AIAI.His research interests include AI planning algo-rithms, programming languages, and Web-basedsystems. He received an AB in mathematics fromDartmouth College and was a member of X3J13,the technical committee that developed the ANSICommon Lisp standard. Contact him at AIAI, Div.of Informatics, Univ. of Edinburgh, 80 SouthBridge, Edinburgh EH1 1HN, UK; j.dalton@ed.ac.uk.

62 IEEE INTELLIGENT SYSTEMS

IEEE Intelligent Systems seeks papers on allaspects of artificial intelligence, focusing on the

development of the latest research into practical,fielded applications. Papers should range from3,000 to 7,500 words, including figures, which

each count as 250 words.

Submit one double-spaced copy and a cover letter or e-mail to

Angela WilliamsManuscript Assistant

IEEE Intelligent Systems10662 Los Vaqueros Circle

PO Box 3014Los Alamitos, CA 90720-1314

phone +1 714 821 8380; fax +1 714 821 4010awilliams@computer.org.

For author guidelines, seehttp://computer.org/intelligent/author.htm

& the i r app l i cat ions

IEEE

2001

Call for PapersCall for Papers