38050 Povo (Trento), Italy Tel.: Fax: e mail: url:

Transcription

1 CENTRO PER LA RICERCA SCIENTIFICA E TECNOLOGICA Povo (Trento), Italy Tel.: Fax: e mail: prdoc@itc.it url: PLANNING AND VERIFICATION TECHNIQUES FOR THE HIGH LEVEL PROGRAMMING AND MONITORING OF AUTONOMOUS ROBOTIC DEVICES Carlucci Aiello L., Cesta A., Giunchiglia E., Pistore M., Traverso P. December 2001 Technical Report # Istituto Trentino di Cultura, 2001 LIMITED DISTRIBUTION NOTICE This report has been submitted forpublication outside of ITC and will probably be copyrighted if accepted for publication. It has been issued as a Technical Report forearly dissemination of its contents. In view of the transfert of copy right tothe outside publisher, its distribution outside of ITC priorto publication should be limited to peer communications and specificrequests. After outside publication, material will be available only inthe form authorized by the copyright owner.

2

3 Planning and verification techniques for the high level programming and monitoring of autonomous robotic devices Luigia Carlucci Aiello ½µ, Amedeo Cesta ¾µ, Enrico Giunchiglia µ, Marco Pistore µ, Paolo Traverso µ ½µ DIS - Univ. di Roma Via Salaria 113, Roma, Italy aiello@dis.uniroma1.it ¾µ IP-CNR Viale Marx 15, Roma, Italy cesta@ip.rm.cnr.it µ DIST - Univ. di Genova Viale Causa 13, Genova, Italy enrico@dist.unige.it µ ITC-IRST Via Sommarive 18, Povo (TN), Italy pistore,traverso@irst.itc.it Abstract Autonomy and safety are two major compelling requirements for space applications. From one side, real-life experiments with space missions have recently shown that planning techniques can provide in practice the desired level of autonomy. From the other side, they have also shown the need for planning techniques that guarantee a high level of safety. In this paper we describe a prototype system based on the idea of Planning as Model-Checking. The system allows both for the validation and for the automatic generation of safe plans, i.e. plans that are guarantee to satisfy user-defined (safety) requirements. This work has been done within SACSO (SAfety Critical SOftware for planning in space robotics), an on-going three years project funded by the Italian Space Agency (ASI). INTRODUCTION During the week of May 17th 1999, the Remote Agent took control of NASA s New Millenium Deep Space One spacecraft. The experiment successfully demonstrated the applicability of closed-loop planning and execution in space missions. However, this success was not without surprises. Indeed, a deadlock due to a missing critical section in the code, caused the ceasing of the Remote Agent controlling activities. The ability to quickly detecting and recovering from the problem has been at the basis of the success of the experiment [1]. Since then, the exploitation of verification techniques for the validation of planners has become an important issue for spatial missions (see, e.g., [2]). In this paper we describe the work done within SACSO (SAfety Critical SOftware for planning in space robotics), an on-going three years project funded by the Italian Space Agency (ASI). SACSO aims at the integration of planning and verification techniques for safe planning. By safe planning, we mean the task of generating and validating plans which not only achieve the goal, but verify also a set of other user defined properties. With this marriage, our goal is to retain the capability to program and (more important) re-program the robotic device at a high level of abstraction: this feature has been the basis of the NASA success for overcoming problems during RAX experiment; have the possibility to automatically verify the correctness of the (automatically or manually) generated programs: this feature is important while developing the system, but also to verify the new versions with respect to new properties, in case some malfunctioning happens.

4 Within the SACSO project, we construct a prototype showing the viability of these ideas. The feasibility of this somehow ambitious project is due to two facts. First, in the last few years, we have seen a tremendous boost in the performances of planning and formal verification tools. Right now, a variety of planning and Formal Verification systems capable of handling complex domains with huge search spaces are available. Second, in this variety of systems, we have seen that a common technology is at the basis of these engines, namely procedures for propositional satisfiability based on Davis Logemann Loveland Procedure (DLL) or Ordered Binary Decision Diagrams (OBDDs) (see, e.g., [3, 4, 5]). In this paper we focus on OBDD-based techniques. We show how it is possible to define a high-level language for the specification of safe plans. We use the Model Based Planner MBP [6] both to validate plans against specifications and to generate plans from specifications. MBP performs plan validation and generation along the lines described in [7, 8], where the planning as model checking paradigm [9, 10, 11] is extended to deal with goals that can express temporal properties in non-deterministic domains. The paper is structured as follows. We start describing the high level language for plan specifications and the structure of plans that can be validated and generated by MBP. Then we describe the main functionalities of MBP and how the user can interact with the planner during the different phases of the development process. We also discuss how plan validation and generation are performed within MBP by means of OBDD-based techniques. Finally, we draw some conclusions and discuss some related work. A LANGUAGE FOR THE SPECIFICATION OF SAFE PLANS We present a high-level language for the specification of plans that control robotic devices. The language allows the user to specify plans at the level of goals, or requirements, that the plan should satisfy. A formal account, syntax, and semantics of the language for the specification of goals can be found in [7, 8]. Here we provide some intuitions and an informal description based on a user friendly language for plan specifications that we are currently defining. The language is based on basic propositions, temporal operators, and strength operators. Basic propositions are, for instance, engine-off, engine-on, pos-ü, stating that the engine of the robot arm is turned off, turned on, and the arm position, respectively. Each basic proposition represent a set of possible states of the robotic device under control, namely all the states where the basic proposition holds. Propositions can be composed with usual connectives like and, or, implies, not. Thus, for instance, the proposition engine-off and pos-ü represents the set of states where the robot has its engine on and is in a given position. Temporal operators allow the user to specify temporal conditions that the device should satisfy along task executions. Temporal operators are reach [while preserving], maintain, avoid, then. Intuitively, reach p means that the plan should lead the robotic device to a state that satisfies proposition p. reach p while preserving q states that the plan, before reaching a state satisfying p, all along its execution, should preserve the property expressed by proposition q. maintain p states that property p should always be satisfied all along the (possibly infinite) execution of the plan. avoid p is the dual specification, p should never hold. spec1 then spec2 specifies a sequential ordering of the specifications spec1 and spec2: spec1 should be satisfied first, and spec2 afterwards. We have two strength operators, do and try. do spec states that spec should be guaranteed, in spite of all exogenous events (e.g., other agents working in the same environment), external environment behaviours (e.g., input/commands issued by the user), and system failures. try spec means that spec is desired but not strictly required for all possible situations, and it is acceptable that the plan satisfies spec only in some cases (e.g., the nominal ones). Specifications can be themselves combined with usual connectives, like and, or. For instance, do maintain p and try reach q states that the plan should guarantee that condition p is maintained and, at the same time, it should reach a state where q holds whenever this is allowed by non-determinism. In the following, we describe how the language can be used to specify safe plans with some simple examples. The user can specify that a camera (or a robot arm) should move to a desired position pos with: reach pos If not specified, the default strength operator is do: reach pos is equivalent to do reach pos, which means that that the plan should guarantee that the position pos is reached. The user can specify the weaker requirement: try reach pos In this case, the planner generates a plans that tries to move the camera to the desired position, accepting the fact that non-deterministically some situations may prevent this, e.g., in the case of failure of some components. The operator then specifies an order in which the plan should satisfy different parts of the specification, like in the case we want the camera to move to pos before, and to pos afterwards:

5 curr. state curr. context task next context 0 engine-off reach pos-2 then reach pos-0 turn-on reach pos-2 then reach pos-0 1 engine-on and pos-0 reach pos-2 then reach pos-0 moveto-1 reach pos-2 then reach pos-0 2 engine-on and pos-1 reach pos-2 then reach pos-0 moveto-2 reach pos-2 then reach pos-0 3 engine-on and pos-2 reach pos-2 then reach pos-0 moveto-1 reach pos-0 4 engine-on and pos-2 reach pos-0 moveto-1 reach pos-0 5 engine-on and pos-1 reach pos-0 moveto-0 reach pos-0 6 engine-on and pos-0 reach pos-0 turn-off 7 engine-off reach pos-0 turn-on reach pos-0 8 engine-on turn-off 9 engine-off nop Fig. 1: A plan for reach pos-2 then reach pos-0 reach pos then reach pos Now let us suppose we want the camera to point to a given moving object (e.g. the moon) and after that, we want to keep the camera pointing at that object. We can specify: reach pos then maintain pos We can specify different strengths for this requirement, like reach pos then try maintain pos, or try reach pos then maintain pos, or try reach pos then try maintain pos. We can furtherly refine the plan specification by requiring that the camera should do all of this by avoiding to point at another position danger-pos, e.g., by avoiding to point at the sun: (reach pos then maintain pos) and avoid danger-pos As a further example, consider the case in which we need a plan that is guaranteed that a given position pos is maintained during the mission (e.g. pointing the camera to the moon), and leaves open the non-deterministic possibility to reach a different position pos (e.g. taking the picture of another desired object just if possible): maintain pos and try reach pos As a final example, consider the case in which the user nests reach and maintain specifications, e.g., in order to specify that the camera should always maintain the possibility to shut down according to a safe procedure : do maintain try reach safe-shut-down SAFE PLANS A plan is a data structure that describes tasks to be executed in given situations. More precisely, a plan can be seen as a table whose columns are current states, current and next contexts, and tasks. The current state specifies the situation of the system under control (e.g. the position of the camera) and the current context defines the specification to be satisfied (e.g. the camera must reach a certain position). The task describes what has to be performed in the current state and current context, while the next context represents the specification that remains to be satisfied afterwards. For instance, a plan that satisfies the high level specification reach pos-2 then reach pos-0 is shown in Fig.1. Assume the camera is initially at position 0 and the engine is off. According to the plan, the, engine is turned on (line 0), then the camera is moved to pos-1 (line 1) and then to pos-2 (line 2). Once position 2 is reached, specification reach pos-2 is satisfied and the new context becomes reach pos-0 (line 3). The camera is moved back to pos-1 (line 3) and to pos-0 (line 5). Now, also specification reach pos-0 is satisfied. Finally the engine is turned off (line 6) and the robot becomes inactive (line 9). We remark that, given a state, the plan can execute different tasks depending on the current context. Plans of this form are strictly more expressive than plans that simply map states to actions to be executed, like universal plans [12], memory-less policies [13], and state-action tables [9, 11]. Indeed, they allow to specify the task to be executed in a given state depending

6 MBP Plan Generation Domain Description Plan Validation OBDD based model Plan Specification Control Automaton Plan Description yes/no(counterexample) OBDD based Plan Library Fig. 2: MBP: Plan Generation and Validation on the history of execution and on the conditions that should still be fulfilled. For instance, in the previous example the first time the camera is in position 1, the context specifies that the plan has still to satisfy the whole specification reach pos-2 then reach pos-0, and task moveto-2 is performed (line 2). Once pos-2 is reached, the context changes (see next context in line 3). When the camera gets back to pos-1 the only specification to satisfy is reach pos-0. Therefore, task moveto-0 is performed (line 5). A further remark is in order. The plan shown in the example is more powerful than a sequential plan. Indeed, no a-priori sequence of tasks is precompiled in the plan. The plan encodes a reactive behaviour that, depending on the state of the world and on the current context, executes a suitable task. This allows for the specification of plans that are robust with respect to unexpected behaviours at execution time. For instance, let us suppose that for some reason (e.g. an alarm, a high priority event) the engine must be turned off while the plan is moving the camera to pos-0. The plan execution would not fail; rather, it would reactively jump to line 7, turn on the engine again and start again to move the camera towards pos-0. As a further example, let us suppose that the engine has some temporary fault such that the task turn-on might fail and leave the engine off. The plan in Fig.1 would iteratively try to turn on the engine until it succeeds by repeatly executing task turn-on, testing whether the engine is on or off, and executing again the same task is the engine is off. SAFE PLANNING The MBP planner can perform two main functions: Plan Validation and Plan Generation (see Fig.2). The user can provide three kinds of inputs to the planner: a plan specification, a domain description, and a plan description. The plan specification is provided in the high-level language introduced previously. The domain description mainly consists of a description of the possible states of the device (e.g., the positions of a robotic arm) and of the basic tasks that it can perform (e.g., the task of moving the arm to a given position). For instance, moveto-ü can be described as a task that can be applied if the engine is on, that leads the device to position Ü if the task succeeds, and that may lead to a different position in the case of failure. The plan description specifies which tasks should be performed by the device in different situations. Plan validation takes in input a domain description, a plan specification, and a plan description. It checks whether the plan satisfies the plan specification in the given domain. If this is not the case, MBP provides a counterexample to the users, i.e., it shows a behaviour of the system that does not satisfy the requirements. The user can validate plans incrementally. For instance, the user can check whether a plan is guaranteed to move the robot arm to a given position. Then he/she can add a further constraint, e.g., the fact that the plan should avoid to bring the device to unsafe positions while moving to a desired position, and check the plan against the more restrictive constraint. At each step, if the plan does not satisfy the plan specification, MBP provides a counterexample that shows how the

7 constraints are violated. The user can refine and modify plans and specifications until satisfied. Plan generation takes in input a domain description and a plan specification. MBP generates automatically a plan that is guaranteed by construction to satisfy the specifications. A plan generated automatically will always be validated successfully by MBP. There are cases in which it is impossible to generate a plan that satisfies the specifications. For instance, the user can ask the planner to find a plan that moves a robotic arm somewhere without passing for a given area while the only possible way to get there is thorough that area. In this case, MBP explores exhaustively all the possible tasks and states of the model, and terminates its search with failure. When failure is returned by the plan generation function, then we are guaranteed that no plan exists that satisfies the specifications in the given model of the domain. If this happens, this probably means that the domain and/or the plan specification need further analysis. Plan generation and plan validation can be used in different phases of the development process, and can be combined iteratively. Automatic plan generation can avoid the error-proning and time consuming task of describing the plan by hand from scratch and in all the details. In the first phases, plan generation can thus be a valuable and convenient functionality. However, after that a plan has been generated, the user can modify it by suggesting a better solution based on his/her experience. The resulting plan can be validated against the original plan specifications in order to guarantee safety. Moreover, both models of the domain and requirements on plans evolve during the project, and they are iteratively refined and modified. Both automatically generated and user-defined plans can be validated against the changes in the requirements or the domain specifications. SAFE PLANNING BY MODEL CHECKING In this section we show how safe planning can be done by using model checking techniques. Model Checking [14] is a well-known technique for the formal verification of digital systems. In order to deal in practice with the huge size of realistic domains, we use symbolic model checking techniques [15] based on OBDDs [16]. From Domain Descriptions to Models The user description of the domain is translated automatically into a state-transition system. A state-transition system is a directed graph whose nodes represent the possible states of the device and whose arcs represent possible transitions when tasks are executed. Realistic applications lead to huge models of the domain, where the explicit definition of the statetransition system is impossible. MBP makes use of the so-called symbolic techniques for representing state-transition systems. The basic idea is that of representing symbolically sets of states and transitions in the graph, rather than each single state and each single transition. Sets of states and transitions can be represented symbolically through a logic formalism, and in particular by means of propositional formulas. Thus, for instance, the set of states where the engine is off can be represented with the propositional variable engine-off. This proposition encodes very compactly a possibly huge number of explicit states, since, e.g., it does not constrains at all the possible positions of the camera. Transitions from states to states are represented by propositions on variables representing the current states, the task, and the next states resulting from executing the task. For instance, all the transitions caused by the task turn-on and leading from the set of current states where the engine is off to a set of next states where the engine is on, can be represented by the formula: (engine-off and turn-on) implies next(engine-on) A symbolic representation of a non-deterministic task turn-on that my unpredictably leave the engine off can be done as follows: (engine-off and turn-on) implies (next(engine-on) or next(engine-off)) Symbolic representations can be manipulated by means of different techniques (e.g., with satisfiability decision procedures or model checking). MBP is based on Ordered Binary Decision Diagrams (OBDDs) [16] that allow for a compact representation of symbolic representations and for their effective manipulation. MBP translates automatically a domain description into an OBDD-based model representing compactly the corresponding state-transition system (see Fig.2). From Plan Specifications to Control Automata For each plan specification, MBP constructs a control automaton (see Fig.2) that is used to control the search for a plan in the symbolic representation of the model of the domain. The nodes are the control states of the planner during the search. They correspond to the current sub-goals that need to be resolved by the planning algorithm, and constitute the

8 pos and pos all all some c1 pos all c2 pos c1 = maintain pos and try reach pos c2 = maintain pos Fig. 3: The automaton for maintain pos and try reach pos contexts of the plan that is being built. The transitions correspond to possible evolutions to different control states in the search. Consider, for instance, the following plan specification, where the user requires a plan that must guarantee that position pos is maintained and that there is a chance to reach position pos : maintain pos and try reach pos During the search, the planning algorithm has mainly to deal with two cases. In the first case, pos has been already reached, and the algorithm must look for a plan that guarantees that pos is maintained. In the second case, pos has still to be reached, and the planner must both leave a chance to reach pos, thus satisfying try reach pos, and guarantee that pos is maintained, thus satisfying do maintain pos. MBP constructs the automaton, presented in Fig.3, that represents these two cases. Consider the state ½ = maintain pos and try reach pos of the automaton. This control state corresponds to the situation where the planner has still to satisfy both try reach pos and maintain pos. From control state ½, we have two possible transitions, corresponding to the two cases described above. The transition labelled with pos and pos corresponds to the case where pos is reached, and thus leads to state ¾ = maintain pos. The transition is also marked with all, to mean that the planner must guarantee the maintainability of pos in all non-deterministic possibilities. In control state ¾, pos must be maintained forever. For this reason, we have a transition from ¾, which is labeled pos and loops back to ¾. The other transition from state ½ corresponds to the case where only pos holds, but not pos, i.e., pos is not reached yet. The transition forks to two different control states. It corresponds to a conjunction of two requirements that must be both satisfied. Indeed, the plan has to guarantee both that in all next states of the domain pos is maintained (arc marked with all and leading to ¾ ) and that there is some state where try reach pos is satisfied (arc marked with some and looping back to ½ ). From Plan Descriptions to Plans The user can provide in input plans to the planner. We are currently investigating different possible languages for plan descriptions. A possibility for the user will be to describe plans in a tabular form, like the one of the example shown in Fig.1. A different possibility is to provide a procedural language. The language should specify the tasks that should be executed when the device is in different states, and the controller of the device is in different contexts. Given a description of a plan in a proper language, MBP can generate an OBDD-based encoding of the plan (see Fig.2), very much in the style used for representing transitions. Conversely, given an OBDD-based encoding of a plan, MBP can generate its description in the tabular format of Fig.1. Plan Generation and Validation We can now describe in some detail how the the two main functionalities of MBP are performed. Plan validation is reduced to a model checking problem. From the model and the plan, a new model is extracted. The extracted model corresponds to a state-transition system that encodes only the behaviours of the system when it is controlled by the given plan. Plan specifications correspond to a formula in temporal logic [7]. Plan validation is then reduced to model checking the new model against the plan specification. This is done by means of standard symbolic model checking techniques. In our case, since MBP is based on NuSMV [17], a state of the art symbolic model checker, plan validation is reduced to model checking in NuSMV.

9 In plan generation, given the symbolic model generated by the description of the domain, and the control automaton generated by plan specifications, MBP searches through the symbolic model guided by the control automaton. The algorithm associates to each context in the control automaton a (symbolic representation of a) set of pairs of states and tasks. The context of the control automaton and the associated states and tasks constitute a putative plan, that is incrementally refined during the search. The algorithm starts with a plan that associates to each context all the state-task pairs. The plan is then incrementally updated and refined by eliminating iteratively states and tasks from a context. Whenever the algorithm recognizes that the requirements encoded in the arcs of the control automaton are not satisfied by the next states reachable by executing a given task in a given state, then that state-task pair is eliminated from the context. Let us consider the case of context ½ in the example of Fig.3. The algorithm distinguishes two cases. The first one corresponds to the arc marked with pos and pos, and covers the case of the states where pos holds. In this case a state-task pair is eliminated if it may lead to a next state that does not belong to context ¾ (namely to a next state where pos is not guaranteed to hold in the future). The second case corresponds to the arcs marked with pos, and cover the states where pos does not hold. In this case a state-task pair is eliminated if it may lead to a state not in ¾ (arc marked with all), but also if no next state belongs to ½ (arc marked with some). The algorithm terminates when no more state-task pairs can be eliminated. CONCLUSIONS AND RELATED WORK In this paper we have shown how OBDD-based model checking techniques can be used to do safe planning. Based on the results presented in [7, 8], we have described how the MBP planner [6] performs plan generation and validation. This work is a starting point in the SACSO project, a project sponsored by ASI. The aim of SACSO is the development of techniques and tools for the support of autonomy and safety in space applications. Within the SACSO project, we are also addressing the problem of safe planning by applying the planning as satisfiability approach [18]. Within the planning literature, most of the works on planning for temporally extended goals restricts to deterministic domains, see for instance [19, 20]. Deductive planning can be considered as the first attempt to merge planning and formal verification techniques. In this case, theorem proving can be used to generate (and validate) plans that satisfy temporal goals, and planning domains can be non-deterministic, see, e.g., [21]. However,the practical automatic generation of plans by deductive planning is still an open problem. SIMPLAN [22] generates plans for LTL-like goals in non-deterministic domains by searching through an explicit representation of the state-space. The use of symbolic model checking techniques, opens up the possibility to deal in practice with large state spaces that are very hard to be tackled with explicit state techniques. REFERENCES [1] A. Jonsson, P. Morris, N. Muscettola, and K. Rajan. Planning in interplanetary space: theory and practice. In Proc. 5th Int.nl Conf. on Artificial Intelligence Planning and Scheduling (AIPS 2000), [2] B. Smith, M.S. Feather, and N. Muscettola. Challenges and Methods in Testing the Remote Agent Planner. In Proc. 5th Int.nl Conf. on Artificial Intelligence Planning and Scheduling (AIPS 2000), [3] A. Cimatti, E. Giunchiglia, F. Giunchiglia, and P. Traverso. Planning via model checking: a decision procedure for AR. In Lecture Notes in Computer Science, volume 1348, [4] F. Giunchiglia and P. Traverso. Planning as Model Checking. In Susanne Biundo, editor, Proceeding of the Fifth European Conference on Planning, Lecture Notes in Artificial Intelligence, Durham, United Kingdom, September Springer-Verlag. [5] H. Kautz and B. Selman. Planning as satisfiability. In Proc. ECAI-92, pages , [6] P. Bertoli, A. Cimatti, M. Pistore, M. Roveri, and P. Traverso. MBP: a Model Based Planner. In Proc. of IJCAI 01 workshop on Planning under Uncertainty and Incomplete Information, August [7] M. Pistore and P. Traverso. Planning as Model Checking for Extended Goals in Non-deterministic Domains. In Proc. Ø International Joint Conference on Artificial Intelligence (IJCAI-01). AAAI Press, August [8] M. Pistore, R. Bettin, and P. Traverso. Symbolic techniques for planning with extended goals in non-deterministic domains. In Proc. 6th European Conference on Planning (ECP-01). Springer Verlag, September 2001.

10 [9] A. Cimatti, M. Roveri, and P. Traverso. Automatic OBDD-based Generation of Universal Plans in Non-Deterministic Domains. In Proc. AAAI 98, [10] F. Giunchiglia and P. Traverso. Planning as model checking. In Lecture Notes in Computer Science, Proc. of the 5th European Conference on Planning (ECP-99). Springer, September [11] A. Cimatti, M. Pistore, M. Roveri, and P. Traverso. Weak, Strong, and Strong Cyclic Planning via Symbolic Model Checking. Technical report, IRST, Trento, Italy, Available at URL [12] M. J. Schoppers. Universal plans for Reactive Robots in Unpredictable Environments. In Proc. IJCAI 87, pages , [13] B. Bonet and H. Geffner. Planning with incomplete information as heuristic search in bellief space. In Proc. AIPS 2000, pages 52 61, [14] E. M. Clarke, O. Grumberg, and D. A. Peled. Model Checking. The MIT Press, Cambridge, Massachusetts, [15] K.L. McMillan. Symbolic Model Checking. Kluwer Academic Publ., [16] R. E. Bryant. Symbolic Boolean manipulation with ordered binary-decision diagrams. ACM Computing Surveys, 24(3): , September [17] A. Cimatti, E.M. Clarke, F. Giunchiglia, and M. Roveri. NUSMV: a new Symbolic Model Verifier. In N. Halbwachs and D. Peled, editors, Proceedings Eleventh Conference on Computer-Aided Verification (CAV 99), number 1633 in Lecture Notes in Computer Science, pages , Trento, Italy, July Springer-Verlag. [18] L. C. Aiello, A. Cesta, E. Giunchiglia, and P. Traverso. Merging Planning and Verification Techniques for Safe Planning in Space Robotics. In Proc. of ISAIRAS 2001, [19] G. de Giacomo and M.Y. Vardi. Automata-theoretic approach to planning with temporally extended goals. In Proc. of ECP99, [20] F. Bacchus and F. Kabanza. Using temporal logic to express search control knowledge for planning. J. of Artificial Intelligence, Submitted for pubblication. [21] W. Stephan and S. Biundo. A New Logical Framework for Deductive Planning. In Proc. of IJCAI93, pages 32 38, [22] F. Kabanza, M. Barbeau, and R. St-Denis. Planning control rules for reactive agents. Artificial Intelligence, 95(1):67 113, 1997.