AbstractIn this paper, we present a system for Distributed IntelligentPlanning and Scheduling (DIPS) that helps a spacecraftfunction as an autonomous agent. A DIPS-based spacecraftreceives only high-level goals from ground stationoperators, and performs its own planning and schedulingonboard, achieving these goals with onboard subsystemsand in cooperation with other spacecraft. The taskdecentralization in DIPS employs a domain distributionalgorithm that typically creates a feasible schedule afler thefirst coordination effort, thereby decreasing inter-agentnegotiation during the scheduling process. The reasoningperformed by DIPS agents to optimize time and resourceusage while maintaining flight rules and constraints is basedon a constraint propagation paradigm. Priority-basedscheduling is implemented, and a hierarchical inter-agenteonflrmation/anthorization system is used for global goalcoordination. An enhanced prototype is developed anddemonstrated using space-based scenarios involvingonboard instruments and a satellite constellation. Thevertically layered architecture of the DIPS prototypeintegrates: 1) Java-based agent infarenee engine; 2) Prologplatform SICStus for eonstruint-based reasoning; and 3)KQML for inter-agent communication. We are specificallytargeting our effort to enhance the planning and schedulingcapability of NASA’s planned nanosatellite constellations.
Introduction
Spacecraft autonomy has the potential for effeetingsignificant cost savings in mission operations by reducingthe need for dedicated ground staff. In an autonomousoperating mode, operators will communicate only high-level goals and deadlines directly to the spacecraft. Thespacecraft will then perform its own planning andscheduling by decomposing a goal into a set of sub-goals tobe achieved in cooperation with other spacecraft in theenvironment. In this paper, we present the DistributedIntelligent Planning and Scheduling (DIPS) system thathelps a spacecraft function as an autonomous agent byincorporating this distributed approaeh to onboard planningand scheduling.
The term planning refers to the generation of activitiesthat satisfy a current set of goals. For example, a planningprocess to satisfy the request for an image generatesactivities such as rolling the camera to the correct positionand activating the camera shutter. The term schedule
describes an association of these specific activities withparticular start and end times by satisfying temporalconstraints (e.g., rolling should be performed before theshutter action). The onboard spacecraft subsystems mustexecute these time-sensitive activities autonomously toachieve the goals, and if none of the subsystems of thespacecraft is capable of executing an activity thencooperation from another spacecraft in the environment isrequired.
In our envisioned distributed (or equivalently, multi-agenO environment (Conry 1988; Georgeff 1983), a set problem-solving autonomous agents (spacecraft andonboard subsystems of a spacecraft) based on DIPScommunicate, cooperate, and negotiate to achieve high-level goals through planning and scheduling. Distributedplanning and scheduling emphasizes a decentralizedorganization in which schedules are generated andexecuted cooperatively and concurrently by agents. Thiscan be contrasted with a centralized planning environmentin which goals, rules, and constraints from individualagents are accumulated at a central place, and a centralizedplanner is used to generate a global schedule. Thecentralized approach is particularly unsuitable when theproblem is inherently distributed such as in a spacecraftenvironment where each subsystem or spacecraft functionsautonomously.
The domain knowledge of tasks and their components inDIPS are manifested through a hierarchical language takinginto account spacecraft operational aspects and resourceconstraints. The task decentralization in DIPS is performedby employing a domain distribution algorithm that typicallyallows a feasible schedule to be found after an initialcoordination effort, therefore greatly decreasing the needfor inter-agent communication during the schedulingprocess. The reasoning performed by DIPS agents forscheduling tasks by optimizing time and resources is basedon a constraint propagation paradigm. An enhancedprototype has been developed and demonstrated usingspace-based scenarios involving onboard sensors and asatellite constellation. The vertically layered architecture ofthe DIPS prototype integrates: 1) Java-based agentinference engine; 2) Prolog platform SICStus forconstraint-based reasoning; and 3) KQML for inter-agenteommunieation.
Past Work in AI PlanningTwo major trends for task representation in the history of
AI planning have been observed (Georgeff 1987): goalachievement (GA) and hierarchical task network (HTN).The origin of GA-based planning is in STRIPS (Tikes1971). In this model of representation, an initial situation, set of possible actions, and a goal that is to be achieved aregiven. Planning consists of finding a sequence of actionsthat would lead from the initial situation to the final one.Several planners were subsequently built on the GA modelincluding TWEAK (Chapman 1987), and SNLP(McAllester 1994). In a planner based on the HTNrepresentation, which originated with NOAH (Sacerdoti1974), planning proceeds by selecting a non-primitive task,decomposing it into subtasks using a library of availabledecomposition methods, and then detecting and resolvingconflicts with other tasks. This process is repeated until nonon-p "runitive tasks remain and all the conflicts have beenresolved. Typical examples of HTN planners are FORBIN(Dean 1988), and NONLIN (Tate 1977). There are planners combining features from these two such as O-Plan(Currie 1991) and SIPE (Wilkins 1988).
Given a representation in either GA or HTN, solving aplanning problem can be viewed as a straightforwardsearch problem, but in general the HTN paradigm can leadto more efficient planners because it allows the user to limitthe search space by guiding the planner towards acceptablesolutions. A typical implementation of the search engine ofa planner operates on a temporal database such as theHSTS system (Muscettola 1994) and Time Map Manager(Boddy 1994). The search engine posts constraints to thedatabase. The temporal database then constructs aconstraint network and provides a constraint propagationservice (LePape 1990) to verify the global consistency the posted constraints with the goals, rules and constraintsof the spacecraft. Both the consistency checking and thesearch for an optimal solution in cooperation with otheragents in the environment are computationally intractable,that is, NP-hard. A distributed approach to planning andscheduling allows cooperation among agents in theenvironment and increases efficiency in the search for anoptimal solution by partitioning the whole search space.
In recent years, there has been a growing interest inagent-oriented problem solving (CACM 1994), whichprovides the basis of our proposed distributed solution(Chaib-dma 1992) to planning and scheduling. The agent-oriented problem-solving environment increases efficiencyand capability (Rosenschein 1982) by employing a set agents that communicate and cooperate with each other toachieve their goals. We use the term agent to refer to anentity that operates autonomously or semi-autonomouslywhile interacting with other agents in the environment bymeans of communication. Although types of agents rangefrom software agents (Genesereth and Ketchpel 1994)
implementing the behavior of human~, machines orhardware, to mechanical or electronic robots (Simmons1991) with the capability of perceiving or sensing theenvironment and executing appropriate actions, ourassumption is that every agent will have, an interface thatunderstands a common communication language.
Satellite Constellation Scenario
We present a scenario that will illustrate our envisioneddistributed planning and scheduling by incorporatingseveral key problem areas prevalent in a dislributedscheduling environment. The simulation of thisenvironment consists of a constellation of satellites, eachwith a number of local resources and the knowledge ofhierarchical task decompositions. The hypotheticalconstellation is loosely based on the Three Comer SatelliteConstellation, a joint effort of Arizona State University(ASU), University of Colorado at Boulder (CU), and NewMexico State University (NMSU) that is expected launch in late 2001.
The primary goal of the envisioned distributed system isto successfully distribute high-level task requests tomultiple independent resources and to maintain theconsistency of constraints placed on those requests. Intrying to fulfill this goal, however, there are severalproblems that can arise. These include replanning due toover-scheduling of a resource, forced scheduling of highpriority requests, increased priority based on a request’sTime To Live (TTL), resource/property management, andaccommodation of lapses in agent communication oravailability.
Scheduling Environment
The scenario consists of a constellation of low-Earthorbiting spacecraft that have cross-link communicationcapability, each carrying nearly the same suite ofinstnmaents. Controlling the constellation is done via afuturistic network of ground stations, in which each groundstation can communicate to only one satellite at a time.Each onboard insmament is locally controlled; requests canbe sent to the network from any ground station. A requestis defined as a goal that requires use of an instrument andassociated data memory storage, containing start/stop timesand operational parameters. Agents can communicate witheach other in order to coordinate high-level goals and tomaintain global constraints.
Scenario Hierarchy Specification
The Satellite Constellation Scenario has the followinghierarchy:
38
Figure 1: Scenario Hierarchy
¯ ASU1, CU1, NMSUI: These agents represent groundcontrol stations on Earth. Each is the sole parent for asatellite (3CSAT1-3CSAT3), and they all are sharedparents for the remaining satellites (3CSAT4--3CSAT6).
¯ 3CSAT1-3CSAT6: Each of these DIPS-based agentsrepresents a satellite in the constellation. Everysatellite has essentially the same collection ofinstruments onboard with slight variations incapability/efficiency.
¯ Onboard Resources: Locator (0-1), Transmitter (2),Recorder (1), and Camera System (1).
Each resource onboard a DIPS Satellite Agent has itsown local DIPS Resource Agent. The Camera agent is anintermediate DIPS System Agent introduced on eachsatellite in order to manage its own group of resources.
Basic Distributed SchedulingIn order to demonstrate basic distributed schedulingcapabilities, the scenario begins with a number of high-level goal requests introduced to the constellation by thethree ground control agents. Every capable DIPS SATAgent decomposes the task, and corresponding subtaskrequests are sent to onboard resource and system agents.The scenario includes multiple compound task requestswith overlapping time domains. The DipS-based Agentsperform a reasonable effort of coordinating these taskdistributions so that most are successfully scheduled on thefirst pass without the need for rescheduling or inter-agentnegotiation. The multi-parental satellite hierarchy permitssome satellites to receive requests from multiple sources.
Special SituationsIn order to force over-scheduling on some local onboardresources, the scenario includes several conflictingrequests. Every DIPS SAT Agent will prefer to schedule itssubtasks on the least expensive resources available---
sometimes at the expense of over-scheduling a preferredlocal resource with tentative subtask requests. Top priorityrequests are introduced to the constellation as forcedrequests, which will always succeed and be locked into thenecessary local schedules, even if other non-forced taskshave been scheduled on those resources at conflictingtimes.
As a task nears its execution time, its Time To Live(TTL) decreases. A DIPS-based agent will process a taskrequest with a very short TTL before another task requestwith a long TTL, even if the latter is of higher priority.
The scenario also includes temporary lapses incommunication between specific satellites and other DIPSagents in the community. A satellite will move out of therange of a ground station for a specified time period,during which a message relay system using other agents inthe community may still allow messages to reach theirdestination. For example, every DIPS agent that receives atask request addressed to "ALL" immediately forwards therequest to all of its siblings in the community to ensure thatthe requests reach all potential executors.
An important real-life issue in a satellite constellation isthe management of resources and physical properties. Forexample, an image of a certain region of Earth can only betaken within a certain time flame while a satellite is overthat location. There may also be certain constraints onpower consumption that affect resource availability. Thescenario includes several task requests that require a DIPSSatellite Agent to reason about its resources and physicalproperties. Satellites also are required to perform cert,_inmandatory m_aintenance tasks throughout the scenario.
The scenario allows some idle time for each satelliteduring which it may explore other feasible solutions to theproblem in order to optimize its schedule andaccommodate as many task requests as possible. If allrequests have been successfully decomposed, a satellite canuse its idle time to search for more optimal usage of timeand resources.
DIPS Agent ArchitectureThe architecture of a DIPS agent is deliberative: there is anexplicit symbolic representation of the model of thedynamic environment, and DIPS agents make decisions vialogical reasoning based on pattern matching and symbolicmanipulation. Several different deliberative agentarchitectures have been proposed in the literature, and twoof them are most prominent: horizontally layeredarchitecture (Ferguson 1992) and vertically layeredarchitecture (Muller 1994). Either layered approachmodels an agent as consisting of several hierarchicalfunctional modules representing different requirements ofan agent, possibly incorporating communication, reaction,inference for planning or scheduling, perception,knowledge maintenance, etc. Each layer in a horizontally
, 39
layered architecture has access to both the perception andthe action components whereas in a vertical.approach, only .one layer has direct interface to the perception and action.
The architecture we have adopted is displayed in Figure2 and it fits into the vertically layered category. The threelayers are the world interface layer, the inference layer, andthe network management layer. A DIPS agent’s knowledgebase is also split into three modules corresponding to thethree layers.
The world interface layer contains a DIPS agent’s facilitiesfor perception, action, and communication, which allrequire a detailed knowledge about the environment. ADIPS agent’s world model contains information about theenvironment such as the locations and capabilities of otheragents. The world interface layer enables a DIPS agent tocommunicate with other agents in the environment andperform activities related to planning and scheduling suchas sending and receiving requests, responding to a request,etc.
Action and Perception. The action and perceptionfacilities can be handled through an advanced real-timescripting language. A DIPS agent’s actions will beperformed via calls to scripts that interact with localhardware. One scripting language candidate is theSpacecraft Command Language (SCL) developed Interface & Control Systems (ICS 1999). SCL, with itsinnovative Real-Time Engine (RTE), is especially wellsuited for our real-time scheduling application. The RTEsupports both time- and event-based script scheduling aswell as real-time resource monitoring and exceptionhandling.
Through such an interaction, schedules generated by theinference layer could be actuated on local resources. Theworld knowledge, or information about the states of theseresources, may be gathered through sensor data. Theinference layer can access this through the scriptinglanguage, which provides the perception component of theworld interface.
Communication. All inter-agent communication andknowledge manipulation is done via message passing. ADIPS agent uses messages in Knowledge Query and
Manipulation Language (KQML) compliant format communicate goal requests, goal confirmations/denials,capability insertions, and other standard KQMLperformatives. Messages are automatically forwarded toappropriate agents to allow two agents not in direct contactto communicate indirectly. The world interface layer sendsand receives messages from other agents in the communityand passes them to the inference layer to be handledappropriately.
Inference Layer
Written entirely in Java, the inference layer of the DIPSprototype agent applies its domain knowledge to goal-related messages in order to decompose compound taskrequests or to schedule primitive tasks on local resources.
The domain knowledge consists of the knowledge of theapplication such as definitions of different task abstractionsand the effects of a task when it is carried out. Althoughmost of the domain knowledge is static for the duration of aparticular application, it can still be manipulated at runtimethrough message passing. When a new resource comesonline, for example, any new relevant scripts or taskdefinitions can be added to a DIPS agent’s domainknowledge through capability insertions. The content of thedomain knowledge and the functionality of a DIPS agent’sinference layer depend on the type of agent. The DIPSsystem currently recognizes two distinct subclasses withinthe DIPS agent architecture: System Agents and ResourceAgents.
DIPS System Agent. A DIPS System Agent represents asystem of primitive resources, so the capabilities of a DIPSSystem Agent (e.g., a Satellite) consist only decomposable compound tasks. A DIPS System Agentdoes not maintain a local schedule for it has no localresources; rather it coordinates a group of subagents, someof which may also be System Agents. When a DIPS SystemAgent receives a high-level goal request, it uses apredefmed decomposition from its domain knowledge tocreate a plan for that task, and then uses its constraintmanagement layer to create a feasible schedule for thatplan. Each subtask in the plan is assigned a certain timeinterval based on the decomposition constraints, andsubtask requests are sent out to all subagents.
4O
DIPS Resource Agent. A DIPS Resource Agent representsa physical onboard resource. Its capabilities are allprimitive tasks that can be performed via calls topredefined low-level scripts. When a DIPS Resource Agentreceives a primitive task request, it posts new temporalconstraints describing the task to the constraint database.The inference layer uses the constraint management layerto verify the feasibility of its new augmented local scheduleand to generate an instance if feasible.
Constraint Management Layer
The constraint management layer of a DIPS agent is basedin a version of the Prolog language called SICStus Prolog,developedby the Swedish Institute of Computer Science(SICS). SICStus Prolog has capabilities for ConstraintLogic Programming in Finite Domains (CLPFD) that allowseveral important developments. Most notably, CLPFDallows arithmetic constraints on variables to be introducedinto a program, and it can perform arithmetic on thesevariables even when they are uninstantiated (Pountain1995). For example, one interval [SA,EA] can beconstrained to overlap a second interval [SB,EB] using thefollowing constraints:
SA--<SB,EA>=SB,EA--<EB.
A database of constraints is maintained by the inferencelayer of a DIPS agent, and the SICStus Prolog emulator isused as a back-end schedule solver. When a DIPSResource Agent receives a task request, it posts any newconstraints regarding that task to the constraint databaseand then queries the Prolog eonstraint management layerfor a feasible instance of its local schedule. When the newconstraints are propagated through the constraint network,the schedule will reflect these changes.
A DIPS System Agent uses its constraint managementlayer for a different purpose. Because a DIPS SystemAgent has no local resources and therefore no localschedule to maintain, it uses the SICStus emulator togenerate regional schedules for individual taskdecompositions.
Hierarchical Modeling
As mentioned in the introduction, a planning process basedon a HTN representation first constructs a plan containingabstract high-level activities and then refines thesecomponents in more detail. This process of refinementcontinues until these high-level activities correspond to thephysical actions in the real world. The advantage of thisapproach is that the feasibility of a plan can be studiedincrementally. If a DIPS agent is implementing the aboverefinement process then domain knowledge of the tasks andtheir components have to be codified in some language.
We provide here some examples of HTN representations(similar to Das, Fox et al. (1997)) used in DIPS.
Compound GoalsA compound task specification used by DIPS has twocomponents: 1) a set of subtasks that compose a possibleplan for achieving the goal; 2) a set of temporal constraintsincluding constraints on the ordering of the subtasks. Thesesubtasks may also be compound themselves. A simplifiedexample task decomposition for a DIPS Satellite Agent is3rovided below:infrared-picture[Start, E nd,Filter, Long, Lat] -
{ task1 span 8; task2 span 2; task3 span 5;task1 before task2; task2 before task3;task1 during; [Start, End]; task3 during [Start,End]; }
This defines the high-level goal "infrared-picture" interms of its subeomponents. Each of these subeomponentsmay be compound in turn; a DIPS agent earl only reasonabout the immediate sublevel in the HTN. The exampledecomposition has three subtasks: 1) A Camera Agenttakes the picture; 2) A Recording Agent records thepicture; 3) A Transmitter Agent transmits the picture toEarth.
The second component of the example containsconstraints that relate the subtasks to each other and to therequest domain. The minimum duration of each subtask isspecified as an integer by the "span" constraints, while therest of the constraints may be any of those recognized bythe DIPS constraint management layer. Thisdecomposition plan, a list of subgoals and temporalconstraints, is sent through a query to the SICStus Prologscheduling predicate, which returns a feasible instance ofthe schedule. The agent can then distribute the subtasks tothe appropriate subagents with the allocated portions of theoriginal request domain.
Primitive TasksEach primitive task (or atomic action) in the DIPS scenarioworld corresponds to a call made to a scripting languagesuch as SCL. These scripts themselves may contain severalactions, but due to the fixed nature of a primitive task,these are considered immutable subatomic actions. Anexample of a primitive task specification for a Power Agentis provided below:power-on[Start, End] -
{ "power-on from <Start> to <End>" }{ task1 span 1 }
Here the "plan" for achieving this goal is simply a scriptcall, and the constraints component describes the minimumduration for the task--in this case 1 time unit.
41
Agent CommunicationCoherence, cooperation and conflict resolution can beimproved by carefully desL~ning the amount and type ofcommunication among agents in the form of messages(Patil, Fikes et al. 1992). The information communicatedshould be relevant, timely and complete (Durfee 1985).Any inter-agent communication in DIPS uses a KQML-compliant format to enhance robustness and modularity.
A DIPS KQML message is considered valid if it has atleast ~e following fields: sender, receiver, id and path.Every KQML message also has a performative thatdescribes the type of communication. Most messages alsohave a content field containing an expression describingthe purpose of the message.
Agents from the DIPS system currently use only a subsetof the standard KQML performatives. The most commonlyused are the following: insert, evaluate, confirm, authorize,and sorry.
Following is a simple example of a goal request sentfrom a CameraA~ent to a FilterA~ent:evaluate :content goal(set -filter[125,135])
:id Home-22-Satellite1-0-3-CameraAgent2-0-2:priority I 0 :sender CarneraAsent2 :receiver FilterABentl
The id field describes the absolute path followed by thisgoal request thread from its originating agent to the currentnode in the HTN, including the index of the decompositionused and the index of the subtask that spawned the currentrequest.
Decentralization and CoordinationThe key concept of the DIPS system is to incrementallypartition the scheduling problem into smaller independentsubproblems of increasing granularity which can then besolved in parallel. While this may sacrifice globalcompleteness and optimality in the search for a feasibleplan, the distributed scheduling approach greatly reducesthe complexity of a large-scale multiple-resourcescheduling problem.
Least Commitment SchedulingThe important development made by the use of theconstraint management layer is that relational constraintson time and resource consumption can be specified in thescheduling process. This allows the full and precisedescription of plans and task decompositions without anyspecification of actual start times. Empowering a DIPSagent with this mentality of least commitment allowsreactive planning and dynamic rescheduling; the Prologscheduler will allow local changes to be made whileadhering to the original global constraints.
Recognized Temporal Constraints. As proposed by Allen(1984), we recognize 7 basic temporal relations betweentwo actions. These relations for two actions, A and B with
inteIWalS [SA,EA] and [SB,EB] respectively, are shownbelow in Table 1. Any other relation can be expressed asthe inverse of one of these.
1.A before B E^<SB,2. A during B SB<S^, E^<EB3. A overlaps B S^<SB, SB<E^<EB4. A equals 13 SAmSB, EA’EB5. A meets B EArnSe6. A starts B S^-SB, E^<EB7. A finishesB S~< S^, EA- Eu
Table 1: Recognized Temporal Constraints
The first three constraints, before, during, andoverlaps, are the three basic types of relations.Constraining two actions with these relations allows someflexibility in the instantiation of real start and end times.The last four can be considered special eases of the basictypes, which all involve reasoning about specific start orend times for the actions and do not allow any flexibilityfor one event once the other has been bound to a realinterval.
Domain Distribution Algorithm
In contrast to previous distributed planning and schedulingsystems such as DAS (Burke 1991), DIPS employs domain distribution algorithm that typically allows afeasible plan to be found after only the first coordinationeffort, therefore greatly decreasing the need for inter-agentnegotiation during the scheduling process. As an extensionto the least commitment approach, each node in the DIPSHTN leaves as much flexibility in the next sublevel aspossible when coordinating the domain distribution. Thebasic underlying algorithm: when choosing a feasibleschedule (partial ordering) of subtasks for a givencompound goal, allocate to each subtask as generous(large) a time interval as possible without allowing globalconstraints to be violated when the subtasks are iustantiatedon the next level in the HTN.
The simplest solution is to allocate to each subtask aportion of the whole domain the size of which is relative tothe duration of the subtask. This solution works perfectlywell when dealing only with the ordering of tasks (whenthe only type of constraint being used is the beforeconstraint). Consider the following exampledecomposition: Two tasks, A with interval [SA,EA] and Bwith interval [SB,EB], are to be scheduled during therequest domain [100,200]. The only constraints on thetasks are their durations A spans 10, B spans 30, and Abefore B. The following schedule could be generated thatwould satisfy the constraints without using a generousdistribution:
42
Using the DIPS generous approach to domaindistribution~ however, these subtask domain~ would be aslarge as possible in order to provide flexibility at lower
° . ,levels m the HTN (note that the ratio of the domain sinesA:B remains the same)
A2OO
The second instance of the schedule will allow flexibilityin the instantiation of both subtasks when they aredistributed to the subagents. In both cases the originalconstraints are fulfilled, but the fast example is more likelyto require inter-agent negotiation (and thus to some extent global search) when local resources are overscheduledduring certain intervals. The second example demonstratesthe least commitment paradigm by relaxing the constraintson the tasks as much as possible.
Distribution Conflicts. Applying a generous domaindistribution algorithm is clearly simple in cases of basicordering between tasks (only using the before constraint).In order to distribute portions of a scheduling problem thatincludes any of the other temporal relations, a system formanaging global constraints must be developed.
Let us consider a slightly more complicated exampleregarding the same tasks A and B, except that they arerelated with the following consWaint: A overlaps B. (SeeTable 1.) A flawed generous approach might produce thisschedule instead:
Consider the possible instantiations for each subtask onthe next level of the HTN. It is entirely possible that Acould start and finish (e.g., [100,110]) before the start of (e.g., [115,145])
The DIPS algorithm solves this problem by treating theconstraints during and overlaps as special cases. TheProlog decomposition predicate increases the size of thedomain of each subtask within the following boundaries: ifone subtask is related to another by one of the inflexibleconstraints, (meets, starts, finishes, equals), the domainsize is left equal to the duration of the subtask; if thesubtask is constrained to other subtasks only by the beforerelation, the domain size is expanded proportionally to theduration of the subtask; if there exist any constraintsrelating this subtask to another with during or overlaps,several new variables are introduced in order to reasonabout the constrained intervals. An interval [Ss,EB]allocated for task B has three components at thedecomposition level: the domain start SB, the domain endEB, and the expected duration spanned by the task DB. Bydefinition, DB =< EB -- SB.
For every task A that is constrained to overlap B, the sizeof the domains of A and B may be increased while A cannotbe started anywhere within its domain sfieh that it does notoverlap B, and vice-versa.
SA+DA>=EB--DB,SB>=EA--DA,EA<=SB+DB.
For every task A that is constrained to be during B, thesize of the domains of A and B may be increased while Bcannot be started anywhere within its domairt such that itdoes not fully include the domain of A.
EB-SA--<DB,EA-SB=<Ds.
Again examining the above intervals A=10 and B=30,the improved generous approach might produce thefollowing schedule instead. This schedule still providesflexibility on the next level but without the possibility ofglobal consWaint violation:
ImplementationA scenario is simulated with a Java application that startseach DIPS agent as an independent thread with its owninitialization file of capability insertions in the form ofKQML messages. An interface to the Launcher allowscustomization of the scenario at runtime.
Figure 3: DIPS Launcher Interface
In this example view, SAT3, has 5 Satellite siblings(middle row) and 6 child agents (bottom row), each which is a DIPS Resource Agent. As shown above the linkbetween certain agents can be disabled to simulate acommunications lapse. Another window (see Figure 4)displays the satellites in their physical location relative tothe Earth. Note the message being transmitted from Sat0 toSat2 via Satl.
43
We can also see the resulting messages sent to Home1 inFigure 7. Notice that the high priority task, 2-0, wassuccessfully authorized, while ..the conflicting low-prioritytask, 3-0, could no longer be scheduled consistently on allnecessary resources, and a sorry message was thereforereturned ~ the HTN to the Home1 DIPS
Figure 4: Three Dimensional View of Constellation
Through this interface, goal requests (in KQML format)are introduced into the DIPS community. Whenever twotask requests conflict on a local resource, the DIPS SystemAgent that originated the request will automatically attemptto reschedule that subtask on the next
Figure 5: Agent Local Schedule
Figure 5 shows the local schedule of a DIPS Transmitteragent, containing three locally scheduled tasks, two ofwhich (2-0, 3-0) are conflicting, but only one of which, 2-0, is high priority (or forced). Because task 2-0 is stilltentative, the agent has allowed a lower priority task to begiven the same time interval. When the task is authorized(finalized by the originating agent), it will force out anyconflicting requests due to its high priority. Thus in Figure6 below the conflicting request 3-0 has been removed fromthe schedule once 2-0 was authorized.
Figure 6: Authorized Local Schedule
Figure 7: Task Authorization Replies
In addition to dealing with request conflicts, we submit aset of similar task requests within a certain time interval inorder to examine the performance of the DipS-basedcommunity under heavy request and scheduling loads.Communications travel in both directions through thehierarchy, including confirm and sorry replies fromsubagents pertaining to high-level goal requests. Anexample scenario consisting of 4 System agents and 14Resource agents (a total of 18 HTN nodes) can distributeand schedule 35 high-level goal requests corresponding to280 primitive tasks in under 5 minutes, even when runningon a single CPU.
Conclusion and Future WorkIn this paper, we have demonstrated how our distributedapproach to planning and scheduling helps to achieve high-level goals and thereby enhances spacecraft autonomy. Ahierarchical syntax has been adopted for representingdomain knowledge of task decompositions and employedto solve the task decentralization problem. A constraintpropagation paradigm has been employed for the requiredplanning and scheduling tasks performed by anautonomous agent, and an innovative system for thedecentralization of a global scheduling problem has beendeveloped and employed with promising results. Priority-based scheduling has been implemented, and a hierarchicalinter-agent confirmation/authorization system was used forglobal goal coordination.
The relative speed with which new requests can beprocessed indicates two areas of success by the DIPSsystem: 1) efficient multiple-resource scheduling in distributed environment by reduction of the complexity ofthe global scheduling problem; and 2) implementation of generous domain distribution algorithm that minimizesinter-agent negotiation. The global scheduling problem inour multi-resource scheduling example would becomputationally difficult for a single scheduling agent tosolve as a whole; yet after decentralization through theDIPS HTN, the total search space was reduced
44
exponentially, and a solution was produced with relativeefficiency. A solution is found with much greater efficiencywhile still satisfying global constraints.
Due to the emphasis on autonomy, the efforts of theDIPS system currently focus on individual schedulecreation and maintenance rather than global scheduleoptimization. Further efforts include the use of CPU idletime for replanning and schedule optimization based oncost utilities. Limited parent-child negotiation will beintroduced to solve difficult scheduling problems. Thereare ongoing efforts to enhance the GUI. The currentscenario will be enhanced to demonstrate the uniquescheduling and conflict resolution features of DIPS.
Acknowledgements
The authors would like to thank Paul Gonsalves and DanGrecu of Charles River Analytics for their contributions tothe planning and scheduling algorithm, Dan Knights ofCharles River Analyties for the initial implementation, andAllan Posner and David Woodard of ICS for theircontributions to the scenario. This work was performedunder contract NAS5-99168 with NASA Goddard SpaceFlight Center.
References
[1] Allen, J. F. (1984). "Towards a General Theory Action and Time." Artificial Intelligence 23.
[2] Boddy, M. (1994). "Temporal reasoning for planningand scheduling." SIGART Bulletin 4(3).
[3] Burke, P., and Prosser, P. (1991). "A distributedasynchronous system for predictive and reactivescheduling." Artificial Intelligence in Engineering 6:106-124.
[4] CACM (1994). Intelligent Agents - Communication the ACM, ACM Press.
[5] Chaib-draa, B. M., Mandiau, R., and Millot, P. (1992)."Trends in distributed artificial intelligence." ArtificialIntelligence Review 6: 35-66.
[6] Chapman, D. (1987). "Planning for ConjunctiveGoals." Artificial Intelligence 32: 333-378.
[7] Conry, S. M., R. and Lesser, V.R. (1988). Multiagentnegotiation in distributed planning. Reading inDistributed Artificial Intelligence. A. a. G. Bond, L.,Morgan Kaufmann: 367-384.
[8] Currie, K. a. T., A. (1991). "The Open PlanningArchitecture." Artificial Intelligence 52(1): 49-86.
[9] Das, S. K., J. Fox, et al. (1997). Decision Making andPlan Management by Autonomous Agents: Theory,Implementation, and Applications. First InternationalConference on Autonomous Agents, California.
[10]Dean, T., Firby, R. J., and Miller, D. (1988)."Hierarchical planning involving deadlines, travel
time, and resources." Computational Intelligence 4:381-398.
[11]Durfee, E. H., Lesser, V.R., and Corkill, D.D. (1985).Increasing coherence in a distributed problem-solvingnetwork. 8th International Joint Conference onArtificial Intelligence.
[12]Ferguson, I. A. (1992). Touring Machines: Architecture for Dynamic, Rational. Mobile Agents,Computer Laboratory, University of Cambridge.
[13]Fikes, R. a. N., N. (1971). "STRIPS: A new approachto the application of theorem proving to problemsolving." Artificial Intelligence 2:189-208.
[14]Genesereth, M. R. and S. P. Ketchpel (1994)."Software Agents." Communications of the ACM37(7): 48-53.
[15]Georgeff, M. (1983). Communication and interactionin multi-agent planning. AAAI.
[16]Georgeff, M. P. (1987). "Planning." Annual Review Computer Science 2: 359-400.
[17] Interface & Control Systems, Inc. (1999).http://www.selrules.eom/.
[ 18] LePape, C. (1990). Constraint propagation in planningand scheduling.
[19]McAllester, D. a. R., D. (1994). Systematic nonlinearplanning. AAAI-94.
[20]Muller, J. P. a. P., M. (1994). Modeling interactingagents in dynamic environments, l lth EuropeanConference on Artificial Intelligence.
[21]Museettola, N. (1994). Integrating planning andscheduling. Intelligent Scheduling. M. a. Z. Fox, M.,Morgan Kaufmann.
[22]Patil, R. S., R. E. Fikes, et al. (1992). The DARPAKnowledge Sharing Effort: Progress Report.Proceedings of Knowledge Representation andReasoning (KR%R-92). C. Rich, W. Swartout and Nebel: 777-788.
[23]Pountain, D. (1995). "Constraint Logic Programming."Byte.
[24]Rosensehein, J. S. (1982). Synchronization of multi-agent plans. National Conference on ArtificialIntelligence.
[25]Sacerdoti, E. (1974). "Planning in a hierarchy abstraction spaces." Artificial Intelligence 5:115-135.
[26]Simmons, R. (1991). "Coordinating planning,perception, and action for mobile robots." SIGARTBulletin 2: 156-159.
[27]Tate, A. (1977). Generating project networks. 5thInternational Joint Conference on ArtificialIntelligence.
[28]Wilkins, D. E. (1988). Practical Planning: Extendingthe Classical AI Planning Paradigm, MorganKaufmann Publishers.
