Component Based Task Models for Agent Coordination

Brian DrabbleComputational Intelligence Research Laboratory,

1269, University of Oregon,Eugene, OR 97403

drabble @cirl. uoregon, edu

Abstract

This paper describes the initial development ofan intelligent tasking model which has been de-signed to enable complex systems, human agentsand software agents, to be tasked and con-trolled within a reactive workflow managementparadigm. The task models exploits recent ad-vances within the AI community in reactive con-trol, scheduling and continuous execution. TheDynamic Execution Order Scheduler (DEOS ex-tends the current workflow paradigm to allowtasking in dynamic and uncertain environmentsby viewing the planning and scheduling tasks asbeing integrated and evolving entities. DEOS isbeing applied to the domains of Air CampaignPlanning (ACP) and Intelligence, Surveillance andReconnaissance (ISR) management. These arehighly reactive domains in which new tasks andpriorities are identified continuously and plansand schedules are generated and updated withina temporal and resource constrained setting.

Introduction

DARPA has identified workflow as one of its key "musthave" technologies and is prepared to invest heavily indeveloping the next-generation workflow systems forthe military. However, in order to do this there needsto be a quantum leap in the current capabilities ofworkflow engines. To date workflow systems have beenapplied to fairly static environments in which the ex-ecution of activities follows a fairly predictable path,e.g. mortgage application processing. This is not thecase in the domains of interest to DARPA e.g. logis-tics, crisis management, mission planning, where newevents give rise to changes both in the task and thestatus of the domain. This requires technologies whichare capable of reacting quickly to changes e.g. enact-ing new processes, editing and deleting existing onesand rebalancing the current resource assignments, i.e.new agents are added and removed, new capabilitiesevolve.

Similar needs are now starting to arise in the busi-ness area with an increasingly competitive market-place, along with widespread automation and the avail-

ability of online information. This has sparked inter-est in the re-engineering and automation of businessprocesses. The field of workflow management (WFM)has emerged as an outgrowth of this interest in recentyears. The workflow community advocates the use ofexplicit models and representations of processes, alongwith automated tools to support the activation andongoing management of workflow processes. In a sim-ilar development, automated systems are themselvesbecoming more complex and are required to interactin more flexible and intelligent ways. Software sys-tems of the future may be viewed as intelligent work-flow enabled products supporting the highly respon-sive businesses of the future. Many domains of in-terest to the workflow community are characterisedby ever-changing requirements and dynamic environ-ments. However, traditional workflow systems provideonly limited reactivity and flexibility. Within the AIcommunity, work on reactive control has led to theexploration of techniques for intelligent process man-agement to meet the requirements of adaptivity fordynamic and unpredictable environments.

This paper describes a revolutionary approach toworkflow management using advanced AI planning,scheduling, and reactive control techniques. The sys-tem described is currently being developed for a num-ber of different DARPA needs, e.g. ISR management,air mission planning and crisis management. The pa-per is structured as follows, Firstly, it describes themotivation behind the need to develop reactive mod-els and gives a brief overview of the state of work-flow systems. Secondly, it describes how rich modelsof activities and tasks are essential in building reactiveworkflow systems. Thirdly, it provides an overview ofthe ACP domain and fourthly, describes the componenttask models developed for reactive workflow. Fifthly, itdescribes the information model which has been devel-oped to support the task models and sixthly, describesthe DEOS scheduling engine developed to manipulatethe task and information models. Finally, it providesa summary of current progress and describes a map-ping from the military domains used as examples to amanufacturing one.

1

From: AAAI Technical Report WS-99-02. Compilation copyright © 1999, AAAI (www.aaai.org). All rights reserved.

Motivation

Through a number of different programs DARPA isexploring the benefits and use of workflow support.There are two mains reasons why DARPA’S is lookingat workflow support:

shrinking defense budgets means that there fewerassets e.g. planes, men, tanks, etc available while thedemands for more efficient and more timely planningcontinue to increase.

¯ the nature of military planning is changing fromlarge scale global conflicts to more localised ones.These local conflicts require fast responses e.g. froman air campaign perspectives missions need to beflown within 24 hours of the situation arising andmust be planned with less than 90

Current DARPA research in workflow is being under-taken in two main areas: air campaign planning andISR management. Research to support air campaignplanners was funded through the ARPI with the devel-opment of the ACP planning tool (ACPT) [Hoffman etal. 1996]. The function of the ACPT Was to take a num-ber of high level objectives and break these down to aseries of sub-objectives, tasks and finally targets to beattacked. This requires the coordination of multipleassets, e.g. fighters, bombers, tankers, SAED, etc, tomeet these high level objectives, e.g. gain air superior-ity, isolate command and control centers, etc. Researchto support Isa planners is being funded by AdvancedISR Management (AIM) program, which is supportingintelligence planners with tools for more effective andefficient management of the assets and information inthe system. These tools address the complete ISR man-agement problem from the strategic development of ISRobjectives to the management of individual XSR assets.All of these tools and the humans in the ISa domainare viewed as agents that are capable of adding valueto the emerging ISR plan.

For these highly interconnected domains to work effi-ciently, they must be organised and managed; that is,a work flow plan that describes how the problem will besolved and identifies the agents necessary to support itmust be developed. This will involve the developmentof intelligent workflow techniques that identify when anagent should be called and which tasks are appropri-ate for the agent to solve. Without intelligent workflowmanagement, the integration of information discovery,acquisition, exploitation, and dissemination would beimpossible. This situation parallels many business andmanufacturing situations where the timely acquisitionand delivery of information, within time and resourceconstraints, is vital.

Current Workflow Systems

Workflow is a fast-evolving area that has evolved pri-marily from the desire to understand, organize, and(often) automate the processes upon which a busi-ness is based. These roots are reflected in the fol-lowing definition of workflow management from theWorkflow Management Coalition (WFMC), an inter-national organization focused on the advancement ofworkflow management technology and its use in indus-try, http : //www. aiim. org / Wf M C/:

The automation of a business process, in wholeor part, during which documents, information ortasks are passed from one participant to anotherfor action, according to a set of procedural rules.[Hollingsworth 1994]

The requirements and capabilities inherent to workflowapply to many process coordination and control prob-lems. In this paper, we use the term workflow to referto this more general notion of process management.

The role of a workflow management system is to pro-vide the services required for automating workflow pro-cesses. The WfMC presents a generic WFM system inits Reference Model [Hollingsworth 1994]. WFM sys-tems can be characterised by the following functionalcomponents:

¯ Modeling and representation of workflow processesand their constituent activities

¯ Selection and instantiation of processes for activa-tion in response to a user request or key events

¯ Scheduling of activities to agents and resulting task-ing of the agents

¯ Monitoring and adaptation of executing processes

At the heart of a WFM system lies a library of tem-plates that encode explicit process models for the prob-lem domain. Templates can be represented as explicitsets of tasks to be undertaken, or more abstractly ascollections of constraints on allowed activities. Activi-ties can encompass a broad array of operations, includ-ing transmission of data, tasking of software agents, orcommunication with human operators. Process mod-eling and representation are typically limited to buildtime within current WFM technology. However, processcreation and adaptation will inevitably migrate frombuild time to runtime as application domains demandflexible adaptation to environment dynamics.

Templates are selected for activation based on currenttasking and environmental conditions. Selected tem-plates can be tailored to a range of situations throughappropriate instantiation of template variables. Typ-ically, activation results in the addition of the con-stituent activities of the instantiated template to an

activity list, which contains information about all cur-rent and pending tasks. As part of activation, resourceallocation is performed for new activities based on cur-rent and projected resource availability.

The term enactment is used generally to refer to theexecution and ongoing management of activated pro-cesses. For many domains, process execution will occurwithin highly unpredictable and dynamic operating en-vironments. For this reason, enacted processes shouldevolve and adapt over time in response to changesin the environment, the addition of new tasks, par-tial execution results, and other factors. Monitoringplays a critical role during enactment, to detect keyevents that may necessitate adaptations to current pro-cesses, or enactment of new or different processes. Sim-ilarly, process templates should evolve over time, toreflect improved models of the domain obtained by an-alyzing information gathered from previous enactmentepisodes.

Why Rich Models Are Important

In the ACP domain, as in many complex domains, theunderlying process controlling the flow of informationfrom user requirement to satisfaction defaults to a ba-sic stovepipe. Requirements are pushed in one end,and after a fairly linear path, pushed out the otherend. This encourages batch processing and creates aninflexible and unresponsive system. For the workflowmanager to have a significant impact on the dynamicresponsiveness of the system it must be able to manipu-late and create context-dependent processes, thus, therequirement for rich models.

Effective workflow management requires represen-tations that makes the process logic explicit, thusallowing processes to be readily understood andadapted. [Myers &: Berry 1999]

AI provides techniques to enhance SWlM’S capabilityto both select processes based on context and adaptprocesses to the dynamics of the environment. Forexample, hierarchical models are desirable for model-ing sophisticated processes because of their capacity tosimplify complex tasks. Basic constructs that shouldbe recorded for a process include the purpose, expectedeffects, applicability conditions, resource requirements,scheduling constraints, participants, and subprocessesthat may be invoked. Process representations shouldsupport the definition of metrics relating to the time,cost, or quality of performing a process, thus allowingcomparisons and improvements to be made. Conceptssuch as authority and accountability are also useful andessential in the AIM domain.

Another characteristic of a good process representationis the ability to support a rich set of control metaphors,including iteration, sequencing, concurrency, monitor-

ing, testing, and suspension/resumption. Given theunpredictability of the operating environments, theability to represent uncertainty is critical. As dis-cussed in the workflow literature [Cichocki et al. 1998;Lawrance 1997], the models must also be rich inlow-level constructs allowing transactional capabilities,synchronization, and information exchange.

Overview of the ACP Process

The ACP process defines the mechanism for translatinghigh level objectives e.g. "gain and maintain air superi-ority by D+2", "destroy weapons of mass destructionby D-5", etc set by the commander into actual tar-gets and missions to be flown. This involves breakingdown the objectives into sub-objectives and further re-fining these sub-objectives to tasks and missions. Ateach step a large number of agents (human and/or soft-ware) are involved to gather, refine and communicateinformation regarding the needs of the process. Withinthe current ACP process the main focus is the develop-ment of the Air Tasking Order (ATO) which describeswhich targets will be attacked, when and how. TheUSAF themselves have identified a number of problemsand shortcomings in the ATO generation process andinclude:

¯ the need to move away from the "stove piped" wayin which military plans are generated. For example,the generation of an ATO takes many hours with anew ATO issued every 12 hours.

¯ inability to rapidly responding to changes and re-quirements. The fixed nature of the ATO does notallow units to be retasked on the fly because thereis little dependency and plan rationale recorded.

¯ lack of integration between different plans and forcesinto a fully integrated battlespace. Separate plansfor Isa, tankering, ammunition, etc, mean that op-portunities and problems can be missed leading toinefficient and potentially costly ATOS

¯ to make better use of the shrinking number of re-sources they have at their disposal. For example, bybetter allocating resources in means less tasks needto be redone and the quality of the final productincreases.

Although the ATO planning process involves activitiesand their coordination, they are described in terms ofthe activities that take place in the planning processitself (such as plan, change, review, publish) ratherthan containing activities that relate to military ef-fects (such as destroy, paralyse, delay, etc). Thus theACP is a planning process whose outcome is a plan,i.e. the ATO. The ATO provides the low level detailwhich the pilots and mission planners need to plan atthe domain level. At the domain levels the planninginvolves allocating a number of resources, i.e. aircraft

and weapons to specified targets at a time designatedin the ATO. The problem is complicated by the abilityof the aircraft to be reconfigured to suit the mission.For example, a flight of 4, A-10 thunderbolts carryingAIM-65 Maverick anti-tank missiles would be a per-fect match for missions against armoured formations.However, the same flight of A-10s could be re-armedwith MK-82 bombs and sent on a different mission.The problem is further complicated by the fact thatweapons have a probabilities of both hitting a targetand destroying it. The planning process aims is to findan optimal assignment of aircraft to targets so as toavoid having to restrike the target or causing unecces-sary risk of aircraft loss or collateral damage. Thereare a number of different ways in which the optimalitycan be measured, e.g. number of missions undertaken,number of targets destroyed, aircraft lost, etc.

In order to overcome many of the problems involved ingenerating large ATOs and then repairing them whenchanges occurred the USAF and DARPA are looking formore reactive models of coordination and workflow be-tween the process and domain levels. The areas beingexplored with this approach include air campaign plan-ning, logistics management and intelligence, surveil-lance and reconnaissance management. The aim is toturn both the process and the domain levels into work-flow processes in which targets are assigned to aircrafton an as needed basis and the results and outcomesof the mission are fed straight back into the processlevels. If the target has been successfully dealt withthen it is removed from the list. If not then processlevel activities are initiated to deal with the outcome,e.g. restrike immediately, integrate with a later mis-sion, rerouting air to air refuelling tankers and SEAD1

aircraft, retask an inflight mission, etc. DARPA refer tothis as "just in time targetting" and has alot of sim-ilarities with tasks found in manufacturing domains.This will be discussed in Section .

The original task models were developed for the do-main level (to improve coordination and feedback tothe process level) but is was soon discovered that thesemodels could be generalised to support planning andtask management at the process levels as well. Detailsof both of these models are now provided.

Task Models

Tasks models define a natural breakdown of a taskinto its constitiuent parts. Rather than have the taskas a single component it is held as a series of sub-components which reflects the generic sub-activitiesneccessary to support the task. This allows the task-ing agent to create a better model of the processingneeded and allows a scheduling algorithm to better un-derstand how to allocate resources, identify tradeoffs,

1SEAD aircraft protect other aircraft from SAM attack

asses changes and modify the workflow. To date twotask models have been identified and applied to boththe ACP domain and the ma domain.

Domain Domain Task Model

A generic domain task is broken down into 5 sub-tasksand is referred to as the PRFER task model.:

¯ Plan: Time taken for the pilot to plan the mission.Once a plan has been identified it is inserted in theslot for other workflow tasks to examine and check.

¯ Ready: Time taken to prepare the plane for the mis-sion

¯ Fly: Time taken to get to the mission objective 2

¯ Execute: Time taken to execute the mission, e.g.drop weapons, unload food pallets, etc.

¯ Reconstitute: Time taken to turn the aircraft roundonce it has returned to base.

Each task is associated with a task specification blocks(TSB) which is allowed to "breath" as changes in thedomain are reflected as changes in one or more of theTSB’s sub-blocks. For example, if the aircraft chosenfor the mission develops a failure during its ready timethen that sub-task will expand and accommodate theextra time. Alternatively the workflow engine may de-cide to substitute the aircraft for another if a spareaircraft exists or another can be re-weaponed in time.If no other aircraft is available then the workflow en-gine may try and reduce the time of the execute blockto recover the lost time. For example, if the aircraft istasked with a food drop and the current method is toland and off load the supplies then the execute blockwould be three hours. If it was changed to an air dropthen the execute block would drop to 30 minutes butthe ready time would increase due to the time take tochange the food pallets to an air drop configuration.By breaking the task into sub-components it allowsthe workflow engine to focus on ways to improve theschedule and recover from changes occuring in the do-main and task. New TSBS can be added to the scheduleas needed and removed just as easily should the deci-sion be reversed. For example, if the drop is beingcarried out using C-141 Starlifter aircraft then it mustbe loaded using a K-1 lifter but if C-5 Galaxy aircraftare used then a K-1 is not needed. Once an aircraftis chosen then the workflow engine can examine theready block and examine needs for the aircraft type,in this case a K-1 lifter. Other needs such as fuel canbe attached to other sub-tasks e.g. fly. Full details ofthe DEOS workflow engine which supports these tasksmodels is provided in Section.

2This can be replaced by a "drive" or "sail" block foroperations using land or sea transport

4

o ¯

Process Task Models

The generic process task is broken down into 4 sub-tasks and is referred to as the PAER model:

¯ Plan: Time to plan the task. Once a plan has beenidentified it is inserted in the slot for other DEO tasksto examine and check.

¯ Acquire: Time to acquire the information e.g. pro-cess products 3 necessary to carry out the task. Thisalso specifies the resources e.g. platforms, Softwarepackages, etc, needed to run the task.

¯ Execute: Time to carry out the alloted task.

¯ Report: Time to file or report the results of the task.

Again each task is associated with a TSB and can behandled with the same workflow engine as the PRFERmodel. During the planning sub-task a number of re-quirements are identified and posted to the acquireblock. The workflow engine can generate new TSBsfor these if there are none in the current system. Al-ternatively, if another TSB is expected to generate therequired document then its report block can be mod-ified by the workflow engine to provide an additioncopy. In this way the execution of the PAER block isa partial order with some information gathering beingcarried out before all planning is complete. In addition,by identifying the information passing between processlevel TSBS and domain level TSBs it becomes possibleto route the right information through the hierarchy.

Information passing through the system is used to co-ordinate and trigger different TSBS. For example, oncea target list moves from recommended to approved(through a vetting task) then other TSBs are triggered.However, the workflow engine could identify that a taskcan execute with the recommended target list to get a"jump start" and can finish its processing once a checkhas been made against the approved target list (in casechanges have been made). This allows the workflowengine to trade off accuracy for time i.e. the recom-mended target list may change but if not the processcan be considerably shortened. It is this type of adap-tive workfiow that DARPA is looking for.

Examples of Task Model Use

The PRFER and PAER models can be used to handle anumber of different situations occurring in the work-flow process.

¯ Change in a major process product e.g. com-manders guidance:This triggers an event in the workflow manager that

3process products are the orders, documents, reports,letter, etc which are used to coordinate the workitowprocess

a primary process product has changed status un-expectedly and that action should be taken. Thismeans identifying the TSBs in the process which havethe commander’s guidance in their "Acquire" block.This would result in some tasks being suspended andothers re-tasked to make use of the new information.If a secondary process product supporting the devel-opment of a new commanders guidance is delayedthen the "Acquire" block of any task using it wouldbe extended by the time required. This will havepotential "knock on" effects with other tasks in theprocess. Should the support document be delayedindefinitely an alternative or inferior (the previousdays) would be used instead.

Initial loss of a domain asset, e.g. U2 aircraft:As with the previous example the assumption is thatthe change requires one or more current/plannedtasks to be modified. This would be achieved byidentifying the tasks impacted by the lost asset. Theworkflow engine would identify the process productsassociated with the lost asset. These could then beupdated and changed as appropriate (see above). alternative view would be to change the type of pro-cessing the tool is carrying out. For example, if thetool was carrying out a full schedule then the optionmight be to reduce that to a feasibility estimate totry and determine the consequence of the lost asset.This means reducing the "execute" block to reflecta feasibility probe rather than the full schedule.

Loss of a process level asset, e.g. loss of assetscheduler:The loss of a process level asset allows a numberof interesting options to be explored. The optionsinclude adding news tasks and in some cases decom-posing tasks to lower levels should there be no equiv-alent asset available. This can be handled simply byadding the failed task to the agenda and modifyingits process product needs. For example, if some pro-cess products have been created or updated then thenew task can ignore this need. If however, the task isyet to start then a simple substitution may be calledfor, it depends on when the asset goes down in theprocess schedule.

Upgrade in the forces in the conflict and theneed for feasibility estimates of the ISR needs:The above examples show workflow engine repair-ing events occuring in an already assigned series oftasks. There will be situations in which new tasksand requirements are added to the system. Sucha situation would arise if a feasibility estimate isneeded for ISR requirements while trying to main-tain the overall picture of the ACP process. Thiswould mean identifying ways of scaling back cur-rent effort through changing "Plan" and "Execute"blocks of needed TSBs.

Information Model

Each of the tasks at either the process or domain levelis specified using "task verbs" indicating the task tobe performed. The tasks are described in the followingform:

* Verb: the task to be carried out (e.g., analyze, de-velop, refine)

¯ Noun Phrase(s): one or more noun phrases de-scribing the object(s) or products on which the ac-tivity is being performed (e.g., prioritised target list)

¯ Qualifier(s): zero, one or more qualifiers con-straining how the activity is performed (e.g.,time/resource limits)

The process products are modeled as resources that arecreated, modified, used, and authorised within the pro-cess. Examples of process products are the documents,reports, orders, letters, and communications (formalor informal). Authority relationships and other condi-tions are also modeled and can be used as an exten-sion of the basic mechanism. Current task models andprocess products are encoded in the ACT representa-tion [Myers 1993], which can be directly executed bythe Procedural Reasoning System (PRS) [Myers 1996;Georgeff ~ Ingrand 1989]. It is hierarchical and pro-vides a rich scheme for both the representation of nor-mative processes and the derivation of new processesbased on AI reasoning and planning.

Details of the development of the verb and processproduct models can be found in [Berry & Drabble1999]. This framework is general enough to be ap-plicable across various different military domains aswell as those found in manufacturing, logistics and sup-ply chain management. The verb/noun(s)/qualifier(s)(VNQ) model was originally developed for the ACP do-main [Drabble, Lydiard, & Tate 1998]. F~ll details ofthe verbs and process products are given in the follow-ing sections.

Verb Descriptions

A full list of the verbs and there definitions is given in[Drabble & Lydiard 1996] and a portion of the hierar-chy is shown here which describes the decompositionof the major verbs Analyse and Decide.

¯ Major Verb: Analyse

- Notes: analyse has notion of quantitative inves-tigation

- Sub-Verbs: predict, determine, monitor, diag-nose, establish, measure.

¯ Major Verb: Decide

- Notes: some of the meanings of decide implyfinality (finalise, terminate), others seem to implyselect by consideration (approve, calculate).

-Sub-Verb: complete, finalise, approve, termi-nate, choose.

The verb model can also be use to describe the ca-pabilities of the agents carrying out the tasks. Byhaving the capabilities and the tasks described in thesame language it makes the "match making" function agreat deal easier. For example a planner could be cate-gorised Using the verbs "refine", "produce" and "mod-ify". The capability descriptor would also define theprocess products and objects it required together withother resource information.

Process Objects and Products Model

A series of matrices is produced which defined for eachtask in the process, the process products which arecreated, read, updated and approved (referred to asthe CRUA matrices4. This allowed for the identifica-tion of the process products which could be associatedwith a given verb and/or qualifier. For example, theverb "review" can be applied to the JFACC GuidanceLetter but the verb "critique" could not. This analy-sis also identified potential classes of process productsand associated values which could provide additionalstructure to the task models For example, all processproducts which refer to list of targets, e.g. candidatetarget list, target nominations list, service target nom-inations, JIPTL and JIPTL cut-off, etc. The CRUA ma-trices were also used to identify the other constraintswhich are involved in each step in the ACP process.The constraints are either:

¯ resource: these are the planning cell personnel re-quired to carry out the activity.

¯ temporal: these are either qualitative, e.g. "thestart of activity A precedes the start of activity B"or quantitative, e.g. "activity A must end no laterthan 16 hours after the start of conflict".

¯ authorities: these describe specific authoritieswhich must be obtained before an activity can startor finish, e.g. presidential authority must be givenbefore the operation can begin.

An example of part of the task to process product as-sociation is given in Table 1. However, some tasksrefer to objects in the domain but without associatingit with a specific process product. For example stepssuch as "group targets" and "deconflict airspace" referto objects in the domain rather than process products.Features of the ACP domain such as airspace, targets,ground features, etc, exist in the real world and are notcreated by the ACP process. It was possible to alterthe steps description to explicitly identify the possibleprocess product(s) involved. For example, it was pos-sible to describe. "deconflict airspace" as "deconflict

4From a suggestion by David Hess of SAIC.

Verb Noun Phrase,s) Qualifier PhraseDeconfiict ACM RequestsFinalise Air Control Order

Special InstructionsAir Tasking Order Quality Control

Produce Air Tasking OrderTarget GroupingsCAS Sortie AllocationsPotential Target ListInitial Target Nomination ListWeaponeering Assessment BroadWeaponeering Force AssessmentMission Support Requirements

Release Air Tasking Order" ~onsider Target and Route Threats

Table 1: Part of the Verb/Noun(s)/Qualifier(s) Table

airspace management requests" and "group targets"as "group targets of the candidate target list". How-ever, in the case of "deconflict airspace managementrequests" it was not certain that this truly refectedthe way in which the step was carried out. For exam-ple, it is possible to deconflict the airspace by using a3D model and tracing the entry and egress routes of theaircraft on the model. Thus it is possible to deconflictthe airspace without making reference to the airspacemanagement requests. For this reason it was decidedto introduce a new class of objects to the model re-ferred to as process objects. The distinction betweenprocess objects and process products is that processobjects are not created by the ACP process but canbe used, modified and consumed in the same way asprocess products.

Using the process product features identified from theCRUA matrices it is possible to group features intoclasses and associate with each class a descriptor type.For example, the features "available" and "not avail-able" could be grouped together to form a single fea-ture "availability" which can take one of these values.These features were used to form an ontology of prim-itive process product features which could in turn beused as the building blocks for more complex reason-ing about the status of process products. For example,the status of the document could be (available, com-pound, published, draft). These are not be part of theprimitive ontology of process products but are insteadcomposed of elements of the process products primi-tive ontology. In addition to identifying the featuresand values it is also necessary to identify the relation-ship between the potential values. This results in aseries of relationships being defined for each featuresand the relationships identified are as follows:

¯ Boolean:The class can take one of two possible features. Forexample, a document can either be available or not

available.¯ Scalar:

The class can take one feature from a scalar set. Forexample, a document’s contents level can be eitherdraft, CONPLAN or OPLAN.

¯ Vector:The class can take a number of fixed features. Forexample, a document’s access information could becomposed of a triple of modification operation, agentand date, e.g. (create, O-Plan, 25-Apr-97/22:10:00).

¯ Set:The class is a O..N description composed of a num-ber of sub-descriptors or classes. A document couldhave a status described in terms of, availability,set_of_contents, review_status, issue_status.

While this model has been developed from the ACP do-main it is general enough to be applied to a wide rangeof workflow domains where system (human and/orsoftware) are required to work together. The modelinvolves a set of process object and product "features"which have a given type.

¯ Process_Product_Type: Scalar: Every pro-cess product has this description element. Pro-cess_Product_Type includes, ATO, ACO, JIPTL, etc.

¯ Contents: Scalar: Every process product has thisfeature.

¯ Contents_Type: Scalar: Every process producthas this feature. It could use the MIME types asvalues for the field.

¯ Description_of_Contents: Vector: This de-scribes the contents of the process product andwould vary for different classes of process products.

Availability: Boolean: This describes the avail-ability of the process product and simply defineswhether the process product exists or not. Examplesof this class are as follows: not_available or available.

7

¯ Type-Information:Scalar: The type-information describes the type ofinformation contained within the process product.The types defined for each class of process productmust be MIME compliant.

¯ Contents_leveh Scalar: The contents_level de-fines the different levels at which the contents of aprocess product can be "measured".

¯ Review-Status: Scalar: This describes the re-view status of the process product as it is reviewedand passed through the ACP process. Examples ofreview-status include: on-going, cut-off, final.

¯ Approval/Recommendation-Status: Scalar:This describes the status of a process product asit transitions from being recommended to approved.(A number of steps on the ACP process can startonce a recommended JIPTL or TNL is available butmust not complete until there "results" have beenchecked against an approved JIPTL or TNL.) Exam-ples of approval and recommendation status include:recommended, approved.

¯ Issue-Status: Scalar: This describes the availabil-ity of the process product to other agents and sys-tems. Examples of issue status include: Examplesof issue-status include: current, unreleased, released,published, issued, proposed.

The items described above form the elements of an on-tology of primitive process product feature descriptors.These features could be used in higher level reasoningto deduce new information about the process products.Details of some of the derived information is as follows:

¯ Status: Set: This describes the status of the pro-cess product as it "moves" through the planningprocess. The status values will be vary for differ-ent process products classes and examples of statusvalues include: availability (boolean) ,description contents (scalar), review status (scalar), issue tus (scalar). For example, the status of the JIPTL)could be described as (status: available compoundapproved released). The status values for differentclasses of process product would have to be agreedbetween the agents in the process in order to avoiddifferent values appearing in the slots of the statusdescriptor. All process products must have a status.

¯ Access-Information: Set: The access-information describes the types of access made tothe process product and the agent and time at whichit was carried out. Examples of access-informationinclude: modification type e.g. create, modify, user(scalar), agent involved (scalar), date (scalar).

DEO Scheduler

Dynamic Execution Orders (DEO)s were identified anddeveloped by Col. "Buster" McCrabb of the USAF’S

Force Development and Experimentation Group in re-sponse to the needs of military commanders to de-velop fully integrated and responsive Air Tasking Or-ders (ATOS) under tight resource and time constraints.

The basic concept behind a DEO is to generate sched-ules quickly and to update them on the fly as newrequirements and changes occur in the domain. ADEO schedule uses an expressive formalism that breaksdown the tasks into the constituent parts. These partsreflect a natural breakdown of the task from a userperspective.

Each task, or low-level process activity, is representedby a task specification block (TSB) composed of thePAER sub-tasks. The TSB can "breath" as changes inthe domain are reflected as changes in one of the TSB’Ssub-blocks. For example, if an agent chosen for a taskdevelops a failure during it’s Acquire phase then theAcquire sub task will expand and accommodate the ex-tra time. Alternatively, a second agent may be sched-uled with the task inheriting the results from the initialPlan phase.

The more common reason for a TSB to change is dueto a "knock on" effect from another TSB. For exam-ple, agents may be performing activities related by theworkflow process. A change in the Execute block of thefirst may push the Acquire block of the next ahead intime. By creating a dynamic link between sub-blocksit becomes possible to quickly identify the impact ofa change and to identify an appropriate set of repairs.Failures may also cause new TSBs to be added to sched-ule to deal with schedule repairs. The dependency linksusually reflect an interchange of information betweenthe tasks.

A TSB can be generated in response to decision madeby other parts of the schedule. For example, if anISR task is scheduled to a U2 (aircraft) to take pic-tures then a film processor is needed to develop thenegatives. If an alternative asset is used (i.e., collectinformation using infra red imaging) then perhaps different film processor is required or none at all. Thescheduler dynamically launches a new TSB to deal withthe film processing task and provides feedback to theuser should the availability of a processor be a problem.This approach also has the advantage of allowing thescheduling problem to be broken down into a number ofdifferent perspectives. For example, the staff operatingthe photo development laboratory do not need to knowthe details of the aircraft which is flying the mission,just the time at which the cameras should be avail-able. By using the DEO model to break the schedulingproblem into smaller pieces it allows large schedulingproblems to become tractable and maintains the nec-essary dependencies between the subproblems.

Note that the PAER model is a generalization of theoriginal task breakdown designed for the air campaign

planning domain, the PRFER (Plan, Ready, Fly, Exe-cute, Reconstitute) model. However, the PAER modelis a great deal more generic. The PAER model is appli-cable to a wide variety of domains including those thatinvolve human agents. One difference from the PRFERmodel is that once planning is complete the "plan" isposted in the plan sub-block so that it is available forinspection by other TSBs. In addition, where informa-tion needs have been identified during planning whichneed to be acquired a new TSB will be created. Thus,information acquisition and planning can proceed inparallel.

An example of the PAER model has been studied in thearea of mortgage application processing with a largeScottish Bank. The existing problem was associatinginformation arriving in support of an application to theoriginal case (e.g., a credit report to the letter fromthe applicants employer). By explicitly adding infor-mation from the Plan, Acquire, and Report phasesto subsequent sub-tasks it becomes possible to createthe necessary dependency chains. Further investiga-tions in this domain are now being planned to exam-ine resource utilisation, information throughput and itsimplications on the Bank’s development of call centeroperations.

Squeaky Wheel Optimization (swo)

swo is a scheduling technology developed for appli-cation to real-world scheduling applications [Joslin &Clements 1998]. The insight behind swo is that in anyreal-world problem it is impossible to capture all asso-ciated constraints and that in most cases the contextin which the constraints apply cannot be easily deter-mined, swo uses a priority queue to determine theorder in which tasks should be released to a greedyscheduling algorithm. The priority queue is deter-mined by how difficult the task is to deal with thatis, the higher the task is in the queue the harder it isto handle it correctly and not by some external pri-ority identified by the user. On each iteration of thealgorithm, swo quickly creates a schedule and thenexamines it to identify the parts that were handledbadly, ibr example, task was completed too late or byan unsatisfactory agent. Any task that "squeaks" ispromoted up the priority queue, with the distance itis promoted determined by the the extent of the prob-lem. The new priority queue is then used to generateanother schedule that is analysed for problems. Thisprocess continues until no significant improvement inthe schedule is noted over several iterations, swo is ex-tremely fast with each cycle of generate, analyze, andreprioritize taking less than a second, even for largeproblems.

swo has the advantage of moving through the searchspace in a coherent manner, looking for better solu-tions. It also has the advantage of allowing changes in

the environment and task to be easily integrated intoan ongoing solution. For example, a new task can beadded to the priority queue and dealt with on the nextcycle.

Summary and Further Work

We have presented an overview of a system for dy-namic task management. The task models are work inprogress but already provide the foundation for work-flow enabled reactive control. This includes an agent-based architecture, rich modeling and representationschemes for processes and their constituent actions,flexible integration of process instantiation, task allo-cation and execution, and highly reactive schedulingtechniques. To date the task model has been appliedto large scale ACP problems i.e. 2500 targets and 200aircraft over a 10 day period and to process level taskin the ISR domain. Further work with the Smart Work-flow for ISR Manager (SWIM) will further validate theapproach and techniques.

The PRFER and PAER models were originally developedfor military applications. However, being generic mod-els they are applicable across a wide number of domainsincluding manufacturing, logistics and assembly. Workwith Intel is intended to verify the models on a numberof semi-conductor assembly problems and the Table 2shows a mapping between the ACP domain and thesemi-conductor manufacturing domain.

The reward for striking a target in the ACP is a numberof points. This can be replaced by the retail price ofthe order. As with the ACP problem the price shouldbe down graded depending on the lateness of the or-der. The evaluation function for the ACP problem isthe number of targets attacked, the suitability of theweapon for the target and the time at which the targetwas attacked. In the semi-conductor domain the evalu-ation function would be to minimize the number of lateorders. Other evaluation functions include minmisingthe inventory and/or maximising the work in progress.This simple comparison shows there is a great deal ofscope for using the PRFER and PAER models for largescale manufacturing problems.

Acknowledegments

This ideas in this paper have been refined through con-tinual discussions with the staff and students of CIRL.The works has also benefited from the insight and en-thusiasm of Col Buster McCrabb (USAF) (Ret).

This research is supported by DARPA Contract:DABT63-98-C-0069 "Intelligent Workflow for Collec-tion Management" and Contract: F30602-97-1-0294"Understanding and Exploiting Hierarchy". The u.s.Government is authorised to reproduce and distributereprints for Governmental purposes notwithstanding

9

DEO Semi-conductor Manufacturing

Strike Missions Orders (size of lot and product (e.g. 500 chip 4567)).Popup Targets New orders and changes to existing orders (e.g. I need 600 chip instead of 500).Attack Window Time from product insertion to delivery.Aircraft Machines on which the chips/PCBs are manufactured.Weapons Auxiliary resources, e.g. wafers, connectors, etc. There would need to be an inven-

tory kept of components and their specifications.Prob (hit) & (kill) The expected profile of the chips made on a particular machine, e.g. the number of

failures, wrong speed, etc. This will vary from machine to machine.Re-weaponeering set up times for the machines.Air to Air Refuel Delivery of raw materials to the factory.

Table 2: Military and Manufacturing Domain Comparison

any copyright annotation hereon. The views and con-clusions contained herein are those of the author andshould not be interpreted as necessarily representingofficial policies or endorsements, either express or im-plied, of DARPA, Rome Laboratory or the u.s. Gov-ernment.

References

Berry, P. M., and Drabble, B. 1999. The AIM ProcessModeling Methodology. Technical report, AI Center,SRI International, Menlo Park, CA.

Cichocki, A.; Helal, A. S.; Rusinkiewicz, M.; andWoelk, D. 1998. Workflow and Process Automation:Concepts and Technology. Kluwer.

Drabble, B., and Lydiard, T. J. 1996. Model of theACP Process Verbs and ACP Tool Capabilities. ISATTechnical Report ISAT-AIAI/TR/1, AIAI, Divisionof Informatics, University of Edinburgh.

Drabble, B.; Lydiard, T. J.; and Tate, A. 1998.Workfiow Support in the the Air Campaign PlanningProcess. In Myers, K., and Ferguson, G., eds., Pro-ceedings of the Workshop on Interactive and Collabo-7utive Planningheld as part of Fourth InternationalConference on Artificial Intelligence Planning Sys-tems (AIPS-98).

Georgeff, M. P., and Ingrand, F. F. 1989. Decision-Making in an Embedded Reasoning System. InEleventh International Joint Conference on AI.

Hoffman, M.; Griffith, A.; Shoop, J.; and Rumanes,L. 1996. Developing a Transition Path for ARPI Tech-nology into the Air Campaign Planning Domain. InTate, A., ed., Advanced Planning Technology, Tech-nology Achievements of the ARPA/Rome LaboratoryPlanning Initiative.

Hollingsworth, D. 1994. The Workflow ReferenceModel. Technical Report TC00-1003, Workflow Man-agement Coalition.

Joslin, D. E., and Clements, D. P. 1998. Squeaky-wheel Optimization. In Fifteenth National Conference

on ArtificiaU Intelligence. Menlo Park, CA: AAAIPress.

Lawrance, P. 1997. WfMC Workflow Handbook 1997.Wiley.

Myers, K. L., and Berry, P. M. 1999. Workflow Man-agement Systems: An AI Perspective. Technical re-port, AI Center, SRI International, Menlo Park, CA.Myers, K. L. 1993. The ACT Editor User’s Guide.AI Center, SRI International, Menlo Park, CA.Myers, K. L. 1996. A Procedural Knowledge Ap-proach to Task-Level Control. In Third InternationalConference on AI Planning Systems. AAAI Press.

l0