Anytime heuristic search in temporal HTN planning for ... - IOS Press

AI Communications 25 (2012) 321–342 DOI 10.3233/AIC-2012-0539 IOS Press

321

Anytime heuristic search in temporal HTN planning for developing incident action plans Pan Tang a,b , Hongwei Wang a,∗ , Chao Qi a and Jian Wang a a Institute

of Systems Engineering and State Key Laboratory of Image Processing and Intelligent Control, Huazhong University of Science and Technology, Wuhan, China E-mails: [email protected], {hwwang, qichao}@mail.hust.edu.cn, [email protected] b School of Emergency Management, Jinan University, Guangzhou, China Abstract. Extreme events challenge emergency managers’ decision making capabilities of developing unified action plans to ensure effective coordination for multiple responding agencies. In this paper, we present a novel HTN planner, called XEPlanner, aimed at working in dynamic emergency response environment with critical time constraints. By understanding incident action plans developing process and characteristics of flood controlling, this paper proposes a set of planning requirements as the guidance for designing a domain specific HTN planner, which challenge the current known HTN planners. Based on the classical AI planning technologies, our planner is designed and implemented for adapting to the application domain. It follows the anytime principles: the first feasible plan can be quickly produced and the quality of the plans is improved as more time is available. Additionally, a set of heuristics for selecting search nodes is proposed for taking into account preferences of emergency managers during the planning process. Moreover, the priorities of incident objectives can be handled effectively. Our experimental results demonstrate that our planner satisfies all the proposed planning requirements and has advantages when it’s applied in flood evacuation domain. Keywords: Extreme events, emergency response, HTN planning, anytime heuristic search, priority

1. Introduction Extreme events have potentially high and broad consequences and require large-scale emergency response [17]. The goal of emergency management is to enhance response efficiency by eliminating duplication of efforts and lessening response time and costs [8]. However, due to poorly shared mental models and possible conflicts among various involved agencies, the persistent problem is the lack of coordination during emergency response process [45]. The plan-based coordination is an effective approach to reduce confusion and conflicts for coordinating all agencies involved. Therefore, effective planning and decision making provides foundation for emergency management of extreme events. However, extreme events response involves many non-routine events or combination of them. The pre* Corresponding author: Hongwei Wang, Institute of Systems Engineering and State Key Laboratory of Image Processing and Intelligent Control of Ministry of Education, Huazhong University of Science and Technology, Wuhan, 430074 China. E-mail: [email protected].

prepared standard operations procedures almost never fit the current emergency situations when a crisis occurs. During emergencies, emergency managers must develop and deploy incident actions plans in real time for adapting to the actual emergency situations. Our research interest is how to improve and support the incident action plans developing process for emergency command teams (ECT) during extreme events response process. ECT is a team of responsible experts from multiple involved agencies and is assembled in the emergency command center, where they work together for responding to extreme events [54]. Unfortunately, due to the enduring characteristics of extreme events, such as rarity, uncertainty and complexity, the pre-defined action plans cannot be used to address unplanned contingencies and complex emergency situation directives [28]. Facing the complex and ill-structured decision problems, emergency managers must develop unified incident action plans for all responding organizations in the dynamic environment with critical time pressure [9]. Moreover, it exceeds the cognitive ability of emergency managers to solve these problems. To close the gap between them, appropriate

0921-7126/12/$27.50 © 2012 – IOS Press and the authors. All rights reserved

322

P. Tang et al. / Anytime heuristic search in temporal HTN planning for developing incident action plans

decision models must be designed and built to provide assistance for reasoning and developing incident action plans [48]. AI planning [21] referring to cognitive process and reasoning, can be used to mimic human reasoning and support the decision making process [36]. AI planning technologies have shown to provide commanders with action plans efficiently in emergency management domain. Especially, HTN planning [16] involves finding action plans for achieving a set of objectives by decomposing tasks successively, which is similar to the means and end analysis method in human decision making [44]. Additionally, it has great expressive power for representing real-world problems [7]. Therefore, HTN planning has the potential to support incident action plans developing process. On one hand, a number of HTN planners have been developed and applied to address these problems in the current time. Firstly, the domain independent statebased forward HTN planner SHOP2 [34] and its predecessor SHOP [33], are applied to assist military commanders to plan evacuation actions [30,35]. Another state-based forward HTN planner [5,6], named SIADEX, achieves efficient and expressive handling of time and has been used for designing forest fire fighting plans [10,11]. Biundo proposed a hybrid planning paradigm that integrates HTN planning and POCL planning to provide flexible support for flood crisis management [4,39]. Additionally, the domain independent HTN planning architecture O-Plan2 [47] has been applied in disaster relief domain for generating action plans [42]. Finally, another domain independent HTN planner SIPE-2 [53], has been applied to oil spills [1] and joint military operations planning [49]. On the other hand, the inherent characteristics of extreme events response challenge current HTN planning paradigms for applying in such a real-world domain. Firstly, the task environment is highly dynamic, complex and unpredictable. Secondly, there is fundamental complexity of synchronization for multiple responders from different organizations to perform numerous, interdependent and heterogeneous tasks. Finally, the available deliberation time is limited when responding to extreme events. Therefore, emergency response process proposes specific planning requirements to provide suitable decision support for developing incident action plans, including: numerical features, predictive information, the process features of actions and parallelism of them, complex time constraints, preferences and optimization, limited time for generating action plans and incident objectives with

priorities. All of them require that the planning techniques are more expressive and provide a wider range of capabilities for adapting to the characteristics of the application domain [50]. Unfortunately, although the HTN planners have several practical applications, they only represent a small step in the direction. The current known HTN planners hardly satisfy all of the above planning requirements. Therefore, it is not straightforward to select a HTN planner for assisting ECT to develop incident action plans [43]. We are interested in bridging the gap between the planning requirements and AI planning technologies for providing suitable decision support. Firstly, a set of planning requirements are proposed, which are intended to define a reference framework for designing a “good” HTN planning paradigm applied in this domain. Comparing to our list of planning requirements, the main shortcomings of current known HTN planners are discussed. Based on this guidance, a new HTN planner for developing incident action plans is designed and implemented. It is an anytime heuristic HTN planner and can handle durative actions, metric temporal constraints, exogenous events, preferences of emergency managers and incident objectives with priorities. Additionally, a set of heuristics representing different search strategies coupled with a pruning strategy are provided for guiding the planner to generate better action plans during the planning process. The remainder of this paper is organized as follows. Section 2 introduces the incident action plan developing process and analyzes why HTN planning is appropriate for supporting it. Then, we propose a set of planning requirements of HTN planning when applying to the real-world domain and discuss the main shortcomings of current known HTN planners in Section 3, which also shows contributions of our work. In Section 4, temporal enhancement of a state based forward HTN planner is proposed. In Section 5, an anytime heuristic planning algorithm for supporting the decision logic of incident action plans developing process is given. Additionally, we show how our planner accomplishes the proposed planning requirements in the above two sections. In Section 6, we define a flood evacuation domain and conduct a set of experiments in the specific domain for testing our planner. Finally, we give a conclusion and introduce the future work. 2. Background Toward developing a better decision model for providing effective decision support, the design process


needs a detailed understanding of appropriate cognitive behavior and characteristics of incident action plans developing process [27,28]. In this section, we analyze the incident action plans developing process and discuss why HTN planning is suitable for supporting it. 2.1. Incident action plans developing process Managing extreme events requires that multiple decision makers from responsible organizations work together to make decisions. When faced with complex and non-routine situations, the emergency command team must develop and deploy new procedures in realtime for adapting to the dynamic situations. However, extreme events always are multi-faceted, requiring emergency managers to combine many standard operation procedures and rework their knowledge in novel ways. Based on relevant literatures, a number of steps can be identified in the incident action plans developing process [32]. A formal description is list as following: Step 1. Develop and maintain the situation awareness. The first phase includes gathering, recording, analyzing and displaying incidents, environment and resources information, which is achieved by situation awareness process [15]. Developing and maintaining accurate situation awareness is essential for effective decision making. The situation awareness is the perception of the elements in the environment within a volume of time and space, the comprehension of their meaning and the projection of their status in the near future [15]. The emergency situation elements include magnitude, complexity and development trend of incidents, environmental entities and available resources, weather conditions and so on. Step 2. Establish a set of specific incident objectives and strategies. ECT identifies a set of incident objectives in the current situation and strategies for achieving them based on situation assessment. To be effective, incident objectives should be specific, measurable, assignable, reasonable, time-related and with strict priorities [23]. Additionally, evaluation criteria representing preferences of emergency managers is also identified in this step, such as preserving safety of human life, minimizing response costs, minimizing total time of response process and so on. Step 3. Develop incident action plans. After implementing the above two steps, the decision problem is identified, which states the responders must achieve incident objectives in the current emergency situation. Subsequently, step 3 is executed to find a set of fea-

323

sible incident action plans. The cognitive process can be regarded as a sequence of retrieval and refinement stages [29]. In the first stage, emergency managers search a set of plan fragments named emergency operation plans or standard operation procedures [32], which might be taken in given situation to achieve specific goals. Always, they define a set of steps with temporal constraints and can be viewed as fundamental building blocks for developing incident action plans. Then, in the second stage, they evaluate the alternatives and select an optimum or feasible one that actually will be taken according to the identified evaluation criteria. Step 4. Disseminate the plans and monitor the execution process. This step involves translating incident action plans into operation orders, monitoring the execution process and unexpected events in the response environment. Because the environment is dynamic, the current situation must be observed at each execution step and the responders try to execute the next steps at the observed state. In fact, planning for emergency response is a continuous process. In this paper, we only focus on the third step which involves the reasoning process for searching a set of action plans to achieve the identified incident objectives in the current emergency situation. The cognitive process can be conceptualized as a search and assembly process, which may be influenced by factors, such as available time for deliberation, the result of prior decisions and dynamic response environment. 2.2. HTN planning for developing incident action plans How to develop incident action plans is a typical complex and ill-structured decision problem in emergency management. Considering cognitive limitation of emergency managers, research on how to provide cognitive-level support for developing incident action plans is needed. A way to alleviate the cognitive effort of ECT is to develop a decision model to mimic the cognitive process and let it to compute incident action plans for providing assistance [26]. Decision models have the potential to provide powerful decision supports, particularly in the decision situation with time constraints and high decision load. One approach to design decision model for developing incident action plans is HTN planning, which solves problems by decomposing tasks and is similar to the cognitive process of incident action plans developing process [36]. HTN planning provides a systematic and effective approach to generate action plans.

324


In the current time, it has applications in several domains, including flood controlling [4,39], forest fire fighting [10,11], evacuation planning [30] and so on. We summarize the main characteristics of HTN planning, which make it suitable for supporting the incident action plans developing process. Firstly, HTN planning is expressive for real-world problems. The knowledge formalism can support human-friendly representation of domain knowledge. Especially, the procedural knowledge of HTN planning presents multiple ways to achieve the objective under different situation conditions. It reflects different team strategies and tactics that are available and can be used to guide the decision making process for developing incident action plans. Due to the expressiveness and efficiency, HTN planning is suitable to solve read-world planning problems, especially in domain with multiple types of domain knowledge as emergency management. Secondly, the hierarchical task network representing goal/subgoals decomposition relationships, which are instantiated by the planner, provides detailed and explicit contextual information for making decisions during incident action plans developing process. Emergency managers can bring contextual information and knowledge that is not available to computers to the decision process. Therefore, it provides an effective decision structure for developing incident action plans. Thirdly, it is close to how the emergency managers think about in the decision-making process. HTN planning is highly goal-directed and separates the process of determining how it is possible to accomplish a goal from the process of deciding how it is best to accomplish the goals. Therefore, it is similar to the cognitive process for searching and assembling domain knowledge in step 3. Finally, due to procedural domain knowledge for supporting the reasoning process and controlling the search space, HTN planning can scale up to complex problems and generate action plans in domains with thousands of objects and hundreds or thousands of actions [52], which is important for solving real-world problems. Comparing to classical planning approaches which search in the space of possible world states, it improves efficiency in time and search space.

3. Planning requirements and discussions To better support incident action plans developing process, the HTN planner must adapt to the character-

istics of this application domain. In this section, a flood evacuation case is introduced for analyzing characteristics of emergency response. Then, we propose a set of planning requirements which also provide principles for designing a HTN planner applied in this specific domain. Additionally, they also provide a reference framework for analyzing and evaluating the current planning approaches. Then, the shortcomings of current known HTN planners are discussed to show the impetus of our research in this paper. 3.1. A flood evacuation case A massive flood is a typical extreme event. Organizations in its impacting region must undertake many response-related activities to reduce threats and damages. To fight floods effectively, flood commanders should develop unified incident action plans in a very time-constrained situation for commanding and coordinating all activities of multiple responders. Therefore, flood controlling provides a typical application domain to study decision support technology for developing incident action plans. Our planner is principally dedicated to support flood commanders for developing incident action plans during flood controlling. This section introduces a flood evacuation case for analyzing the characteristics of the specific application domain. As shown in Fig. 1, the flood evacuation area involves a flood controlling command center, a water level station, a meteorological station, five residential areas, three shelters and five teams. Team1 is the ECT during flood controlling and is located in flood controlling command center. The other four teams (Team2, Team3, Team4 and Team5) have capability of transporting residents in danger to destination shelters if they get orders from Team1. Additionally, populations in residential areas begin to prepare evacuation and wait for transportation at given collection locations once Team1 issues evacuation commands to them. All the above entities locate at different locations in the evacuation area. The transportation network in the evacuation area, which consists of locations and roads connecting them, is predefined. According to the incident action plans developing process in Section 2.1, once a flood occurs, flood commanders must identify the current situation, which consists of the flood level, information about the residents, the transportation teams and so on. Additionally, they must assess and forecast development trends of the flood. Based on the current emergency situation, Team1 in flood controlling command center identifies


325

Fig. 1. A map of the flood evacuation area. (Colors are visible in the online version of the article; http://dx.doi.org/10.3233/AIC-2012-0539.)

which residential areas will be flooded and must be evacuated. Then, the third step is executed to develop the incident action plans for achieving the identified incident objectives which state how to organize the evacuation process. Finally, flood commanders translate the action plans into operation orders, command and monitor the emergency activities of all involved responders, including residents and transportation teams. 3.2. Planning requirements Our aim is to develop a HTN planner for adapting to main characteristics of the specific application domain. By understanding details of incident action plans developing process in the above flood evacuation case, we propose six planning requirements for designing our HTN planner. All of them are listed as following: (1) Numeric features and predictive information The emergency situation has numeric features. For example, the flood level, capacity of transportation teams, and number of populations in residential areas must be described by numbers. The other needs for numbers are time, sharable resources having specific capacity, available continuous resources in limited quantities and so on [41,50]. Therefore, reasoning with numbers is essential in this real-world domain.

Additionally, flood commanders have some ability to predict development of the current emergency situation, such as the flood development trend and weather conditions forecast in the near future. During emergency response process, predictive capability can enhance emergency managers’ ability to determine outcomes of alternatives [37]. For better decisions, it is needed to express and handle predictive information when developing incident action plans. Based on the above discussion, we define the first planning requirement as following: PR1. The planner must represent and reason with numbers and predictive information. (2) Durative operators and concurrency control mechanism Operators are abstractions of elementary emergency actions executed by multiple geographically dispersed agencies participating in emergency response work. In fact, there are complex processes behind the elementary actions. For example, the driving activity executed by transportation team consists of multiple steps by the members of it. Therefore, it is necessary to model the characteristics of these processes, such as variable durations, conditions that must be satisfied before specific time points or during any interval, and effects which occur at any time point during execution.

326


Moreover, there is a fundamental complexity of synchronization for multiple responders to perform numerous, interdependent and heterogeneous emergency actions. In the above case, multiple teams can transport the residents in danger at the same time. Therefore, a concurrency control mechanism is essential to ensure coordination and parallelism of emergency actions. The second planning requirement is defined as following: PR2. Expressive durative operators representing process characteristics of emergency actions and concurrency control mechanism for them are needed. (3) Complex time constraints Quantitative time constraints represent exact temporal relations between tasks of different durations for improving quality of decisions. Firstly, incident objectives are time specific and must be achieved before extreme events cause disastrous effects. Therefore, incident objectives have deadlines, which are metric time constraints on the start time or end time of them and the reference time of emergency response process. Additionally, complex synchronization relations between tasks must be encoded in order to represent temporal dependence between tasks with duration. On the other side, as emergency managers in high levels do not have detailed information about the durations of tasks, they only represent partial order relationships between them, which is also called qualitative time constraints [40]. They are useful to synchronize tasks with unknown durations. The third planning requirement is listed as following: PR3. HTN planner must represent both qualitative and quantitative time constraints, and generate action plans satisfying all the complex time constraints during the planning process, where time constraints are generated increasingly. (4) Preferences and optimization Preferences play a significant role in human decision making [3]. As introduced in Section 2.1, a set of evaluation criteria is identified in step 2, which also represents preferences of emergency managers for evaluating generated action plans. In fact, it determines how to select the strategies and tactics during the incident action plans developing process. Additionally, if multiple action plans achieving the given incident objectives exist, preferences of ECT as a whole specify the criteria for evaluating them. Therefore, unlike classic planning, in which the plan is evaluated by the number of

steps, the action plans are evaluated by the plan metric defined by preferences in emergency response context. Additionally, the preferences have significant impact on the planning process. To address the problem of preference-based planning, we require a language for representing preferences of emergency managers, as well as an approach for generating optimum plans with high quality effectively. Based on the analysis, the fourth planning requirement is list below: PR4. To achieve problem solving strategies closer to incident action plans developing process, our planner needs to represent preferences of emergency managers and use it to guide the planning process. (5) Reactivity and time limitation for generating action plans Due to the enduring characteristics of extreme events, such as high dynamic nature and uncertainty, reactive response is necessary for emergency action planning. Additionally, when emergency managers are faced to achieve a set of incident objectives with specific deadlines, the time spent on developing incident action plans decreases the time available for execution [28]. However, developing incident action plans are typical complex and large scale decision problems involving thousands of objects and hundreds of actions. The problem solving process needs considerable computing efforts and takes much time. Therefore, when working in real-time, dynamic and complex task environment, emergency managers should generate action plans for adapting to the current decision situations. The incident action plans developing process has not to output absolute optimal plans, but to obtain a response according to the environment demands. Based on the above analysis, we propose the fifth planning requirement as following: PR5. The planner should be responsive to a wide range of time allocations and search multiple feasible action plans within the limited time effectively. (6) Incident objectives with priority Emergency managers cannot always achieve all the identified incident objectives with available resources in the critical time constraints during emergency response. Therefore, the incident objectives are assigned strict priorities and the ones with higher priority takes precedence over others to be achieved for adapting to the over-subscription situation. In the above case, evacuating the residents is of higher priority to be achieved than transporting hazardous chemicals in flooded area.


Therefore, the following planning requirement must be satisfied: PR6. Incident objectives with higher priorities should take precedence over others to be achieved during the planning process. The above six planning requirements provide the guidance on how to design a HTN planner for developing incident action plans. Our objective in this paper is to propose a domain specific HTN planner providing high accomplishment for all of them.

327

this planner is that it plans for tasks in the same order that they will be executed later. Comparing to our planning requirements, SHOP2 cannot represent and handle the predictive information. The operator in SHOP2 is same as classic planning. It does not handle concurrency of actions directly and explicitly. Despite the Multi-Timeline Preprocessing can translate durative actions into SHOP2 operators, it is not automated and has always been done by hand. Additionally, it cannot support parallel actions in the generated plans. Therefore, we evaluate that SHOP2 accomplishes PR2 partially. SHOP2 only represents simple ordering constraints between tasks and cannot handle metric time constraints. Therefore, it cannot represent quantitative time constraints and does not satisfy PR3. Moreover, the planner cannot represent preferences and only find feasible plans achieving the initial task net by depth first search process. Finally, one can specify a time limit to stop the search process in SHOP2. However, there is no given designed time in the extreme events response context. Therefore, it does not support the PR4 and PR5.

3.3. Discussion for shortcomings of current known HTN planners The set of planning requirements provide design principles for developing HTN planner for this domain. Unfortunately, they present challenges for current known HTN planners. At present time, a number of HTN planners are available for distinct kinds of problem domains and purposes. However, they are designed based on specific basic assumptions and domain features. In this section, we describe the current known HTN planners, which illustrate what has been achieved in the planning community. Additionally, we discuss the shortcomings of them comparing to the list of planning requirements. The comparison between current known HTN planners and proposed planning requirements is listed in Table 1. Obviously, none of them satisfies all the planning requirements. Moreover, the discussions also show motivation of our research and contributions of this paper. The detailed discussions are described in the following:

(2) SIADEX SIADEX [5,6] is another state based forward planner on the same foundation of SHOP [33] and SHOP2 [34], but it achieves efficient and expressive handling of time, which is still a pending task for most HTN planners. SIADEX allows numeric-valued functions to represent numerical objects as the definition in PDDL 2.1 [18]. However, predictive information cannot be handled by the planner. Primitive actions in SIADEX can represent effects which are achieved at any time during execution. However, they cannot represent and reason temporally annotated conditions in durative operator as defined in PDDL 2.1 [18]. Additionally, the temporal reasoning framework is devoted to primitive tasks in

(1) SHOP2 SHOP2 is a domain independent state based forward HTN planner, which received one of two awards for distinguished performance in 2002 International Planning Competition [34]. The primary characteristic of Table 1

Comparison between current known HTN planners and planning requirements PR1

PR2

PR3

PR4

PR5

PR6

SHOP2 SIADEX O-PLAN2 SIPE2 IxTeT

Partly No Yes Partly Yes

No Partly Yes Partly Yes

No Partly Yes Yes Partly

No No No No No

No No No Partly No

No No No No No

Hybrid planner

No

Partly

No

No

Partly

No

Notes: Legend on the rating: ‘Yes’ means ‘is satisfied’, ‘No’ means ‘not satisfied’ and ‘Partly’ means ‘is somehow satisfied’.

328


SIADEX. When decomposing compound tasks, there are possible time conflicts. That is to say, it accomplishes the planning requirement PR1, PR2 and PR3 partially. Moreover, preferences cannot be represented and used during planning process. It only generates a feasible plan that satisfies all the logical goals. Therefore, it does not adapt to planning requirement PR4 and PR5. (3) O-PLAN2 O-PLAN2 provides a generic domain independent architecture exploring issues of coordinated planning and controlling, and has been widely used in emergency management domain [47]. Comparing to our planning requirements, this planner only specifies the initial state of the world with a list of STRIPS propositions and cannot represent predictive information. Additionally, knowledge formalisms of O-PLAN2 cannot represent actions with time annotated conditions and delayed effects. The preconditions of operators are predicates that must be satisfied before the actions are executed [46]. All kinds of time constraints on tasks can be represented and handled using incremental time constraints management algorithm by O-Plan2. Moreover, it searches suitable plans in the state space for achieving given conditions according to a depth-first search strategy. That is to say, it cannot be applied to problems in which optimal solutions are needed. Additionally, it does not support reactivity for adapting to environment demands. Therefore, it satisfies PR3 and does not support PR4 and PR5. (4) SIPE2 SIPE2 [42] is an AI planner, which has the ability to generate action plans with parallel actions, conditional actions and resource assignments. It has been applied in containing oil spills [1] and joint military operators planning [49]. For the first planning requirement, it cannot represent predictive information. Secondly, all the preconditions of operators must be satisfied before the operator is applied in SIPE-2, and the effects are achieved when the action has been executed [51]. Therefore, it supports PR2 partly. SIPE-2 provides access to powerful temporal representation and reasoning capabilities. It allows specification of any of the 13 Allen temporal relations and quantitative constraints between any pair of actions, and calls a temporal reasoner to propagate these time constraints. Therefore, it provides high achievement of PR3.

Preferences of the planning domains cannot be represented and handled by the planner. For coping with dynamic and uncertain environment, the planning system performs asynchronous run-time re-planning to recover from the failures. However, it is achieved by PRS-CL, not by SIPE-2 directive. According to the analysis, we consider that it only satisfies PR5 partly. (5) IxTeT The IxTeT system is a lifted partial-order temporal planner based on CSPs [20,25]. The input to the planning system is the initial state, expected changes in the world and required goals. For satisfying PR1, it can represent numbers using numeric-valued functions and handle predictive information by event model. Additionally, it provides the capability of representing time annotated conditions and delayed effects. Unlike classic HTN planning, the goals are represented by desired states of the world and the deadlines of them cannot be specified. Therefore, it satisfies the PR2 and PR3 partly. Finally, it only performs a depth-first search as long as the current partial plan is acceptable. When it is not acceptable, it backtracks according to a best-first strategy. Moreover, it does not take into account reactivity resulting from dynamic environment and action failures. Therefore, it does not satisfy PR4 and PR5. (6) A hybrid planner The hybrid planner is developed by Biundo for providing flexible support in crisis management [4,38,39]. The operator is defined as STRIPS, and the concurrency controlling of them is achieved by the POCL planning technology. Additionally, the planner only supports definition of the partial orders of tasks and cannot handle numbers, predictive information, durative actions and quantitative time constraints. It provides different planning strategies that should be followed during the plan refining process. Therefore, for the list of planning requirements, it satisfies PR2, PR3 and PR5 partly and does not support PR1 and PR4. The planning requirement PR6 cannot be satisfied by all the above planners. Other HTN planners are more limited in application or have other emphasis. Therefore, they are excluded for the detailed discussion because of space limitations. For engineering a practical planning system for this particular real-world domain, it is not that straightforward to simply select an available planning model. According to the above discussion, a number of planning requirements remains unaccomplished or are accomplished partly by the current known HTN planners.


We are interested in bridging the gap between current HTN planning technologies and the proposed planning requirements for the real-world domain. The following sections will introduce our HTN planner which provides high accomplishment of the above requirements and supports incident action plans developing process effectively.

4. Temporal enhancement of the state-based forward HTN paradigm This section explains how XEPlanner has been extended for temporal enhancement of the current statebased forward HTN planning paradigm. Firstly, an enhanced model of durative operators for expressing the process characteristics of actions and a method model for encoding complex time constraints are given. Then, we introduce the concurrency controlling and time constraints management mechanism for XEPlanner. 4.1. Knowledge formalism Knowledge formalisms for describing incident action plans developing process are the basis of designing a HTN planner for this specific application domain. Unfortunately, there has been a gap between the modeling requirements and what can be expressed by the knowledge formalisms of current known planners. Firstly, PDDL 2.1 [18] does not include method models for expressing procedural knowledge. Moreover, the durative operators in PDDL 2.1 cannot represent the process characteristics of emergency actions. Additionally, the method model in SHOP2 does not encode complex time constraints for satisfying PR3. In this section, based on PDDL 2.1 and HTN formalism of SHOP2, a modeling language which is capable of expressing the characteristics of emergency actions and complex time constraints is proposed. The details of the knowledge formalisms are list as following: (1) Durative operators To get a more flexible representation for elementary emergency actions, we make the operators to be temporally annotated, including instantaneous preconditions, invariant preconditions and delayed effects. The instantaneous preconditions are those that must be satisfied before a specific time point during execution. The invariant preconditions are logical atoms which should be hold for any interval. The effects can take place at arbitrary time points in execution. Addition-

329

ally, the variant duration and cost should also be expressed. Our representation of operators is as following definition. Definition 1. Operator has the form (:operator head, instantPres, invarientCons, Deli , Addi , Deld , Addd , dur, cost): (1) head = (name, x1 , . . . , xn ) is a primitive task, consisting of the operator’s name and a list of parameters; (2) instantPres = {instantPrei = (logicalExpi @ti )} is a set of instantaneous preconditions; instantPrei is an instantaneous precondition indicating that the logical expression logicalExpi must be satisfied by the planning state before the time ti during execution; (3) invariantCons = {invariantConi = (pi −(st, et))} is a set of invariant conditions, invariantConi is an invariant condition representing that the predicate pi cannot be deleted in the time interval (startTime + st, startTime + et) during the planning process (startTime is the time when the operator is executed). (4) Deli = {pi } and Addi = {pi } are a set of predicates representing the delete list and add list of the instantaneous effects. They define the negative and positive effects respectively when the operator is executed. (5) Deld = {ei = (pi − ti )} and Addd = {ei = (pi + ti )} (ti < dur) define the delete list and add list of the delayed effects, consisting of a collection of events which are used for updating the planning state. The events Deld and Addd is scheduled to be triggered in specific time deltas; (6) dur and cost are terms representing duration and cost for executing the operator, respectively. Unlike actions in classical planning, the above knowledge formalism of operators is not instantaneous and has variable duration. The preconditions are complex logical expressions and have time annotations. Additionally, the effects can be triggered immediately or at any time after the action is executed. Therefore, the above durative operators are more expressive. An example of the operator representing driving a vehicle during flood controlling is shown in Fig. 2. The instantaneous preconditions must be satisfied before it is applied. The keyword “call” represents an external function for doing numeric evaluation as SHOP2 [34]. When it is executed, it deletes the logical atom (at ?t

330


(:operator (!drive ?t ?loc-from ?loc-to) ;;instantaneous precondition ((((at ?t ?loc-from) (distance ?loc-from ?loc-to ?d) (velocity ?team ?v) (assign ?duration (call / ?d ?v))) @ 0) ) ;;invariant conditions () ;;delete list for instantaneous effects ((at ?t ?loc-from)) ;;add list for instantaneous effects () ;;delete list for the delayed effects () ;;add list for the delayed effects (((at ?t ?loc-to) + ?duration)) ;;duration ?duration ;;cost 50 ) Fig. 2. An example of a durative operator model.

?loc-from) from the planning state at the start time of the operator, adds the logical atom (at ?t ?loc-to) to it at the end of the duration. (2) Temporally-enhanced methods Encoding activities at multiple abstraction levels is crucial in extreme events decision making. A method indicates how to decompose a complex task into a set of subtasks with temporal constraints. It provides a hierarchical modeling mechanism for representing multiple alternatives to achieve high level goals and constraints defined on the plan structure [31]. Therefore, we use methods to represent strategies and tactics of a team of responders working together for achieving given goals. The definition of a method is as following definition. Definition 2. A method is of the form: (:method h (instantPres, taskList, timeContraints)), where h is the name of a compound task representing the specific objective of a plan fragment; (instantPres taskList timeContraints) represents an alternative way for achieving the objective, instantPres is a set of instantaneous preconditions as operators; taskList is a partial order list of tasks defining the subtasks and qualitative time constraints on them; timeContraints = {tck } is a

set of metric time constraints representing the quantitative time constraints on the tasks. The quantitative time constraints are encoded by four standard forms: (1) tpi − tpj value; (2) tpi − tpj value; (3) tpi − tpj < value; (4) tpi − tpj > value.tpi = (startOrEndi @indexi ) is a time point representing the start time or end time of a subtask ti or the reference time of the planning process TR; the index of this task in task list taskList1 is represented by indexi ; startOrEndi ∈ {start, end}, if startOrEndi = start, the time point represents the start time of the task. Otherwise, it represents the end time of it; text of {value} is a number. Based on the quantitative time constraint model, we can represent deadlines of a task with the time constraints defining on the start time or end time of it and the reference time of the planning process TR. Additionally, all kinds of the time constraints between tasks with duration can also be encoded. A method model for describing an evacuation strategy during flood controlling is shown in Fig. 3. It has two instantaneous preconditions. The first precondition specified by a predicate must be satisfied by the planning state in some time during the planning process and the other one must be satisfied by 20 time units later. However, these temporal preconditions cannot be represented and handled by SHOP2. For example, we encode the flood-level and the time point as arguments of a predicate, e.g., flood-level (loc1-1, 45, 0) and flood-level (loc1-1, 50, 20). Then, these preconditions must be satisfied at the beginning of the planning process and 20 time unit later. When all the instantaneous preconditions are satisfied, the compound task (flood-evacuate ?area) can be achieved by executing (issue-evacuate-command ?tc ?r ?area) firstly, then executing (!prepare-evacuate ?r ?area) and (organizetransport ?r ?area ?num) in any order. Additionally, the task (issue-evacuate-command ?tc ?r ?area) must be completed with the deadline of 10 time units. (3) Temporally-enhanced axioms Not all predicates in preconditions of methods and operators are explicitly asserted in the current state. The derived predicates defined in PDDL 2.2 [14] support the property, which are predicates that are not affected by the effects of any operator. In other words, no derived predicate occurs in the effects of any operator. The axioms are modeled for inferring derived predicates. Therefore, we call a predicate a derived one if there is an axiom that has it in its head; otherwise we


(:method (flood-evacuate ?area) ;;instantaneous preconditions-1 ( (((flood-level loc1-1 ?h) (call > ?h 42) (capability ?tc Command) (inhabitate-at ?r ?area) (population-num ?r ?area ?num)) @ 0) (((flood-level loc1-1 ?h)(call >= ?h 45)) @ 20) ) ;;subtasks-1 (:ordered (issue-evacuate-command ?tc ?r ?area) (:unordered (!prepare-evacuate ?r ?area) (organize-transport ?r ?area ?num)) ) ;;time constraint list-1 (((end@ 1) - TR < 10)) ) Fig. 3. An example of a method model.

call it a basic one. The axioms are functions that map a set of basic facts (instance of basic predicates) to a set of derived facts (instance of the derived predicates) in a given world state. We represent them by generalized versions of Horn clauses as inference rules, and enhance them with time annotated conditions. Definition 3. An axiom has form: axiom = (head, tail). head is a predicate; tail is the time annotated logical precondition expression as the preconditions of methods. An axiom says that if the precondition defined by tail is satisfied in the current planning state, then the logical atom head is true. An example of the axiom is shown in Fig. 4, which says that the flood warning level is First-Rank if the current flood level in location loc1-1 is more than 45 units and will rise to more than 50 units in 20 time units. (4) Incident objectives and emergency planning problem For adapting to the characteristics of this application domain, we propose the knowledge formalisms of incident objectives and emergency planning problem. Incident objectives are statements of guidance and direction for emergency response. Firstly, due to the

331

(:- (flood-warning-level First-Rank) ( (((flood-level loc1-1 ?h) (call > ?h 45)) @ 0) (((flood-level loc1-1 ?h) (call >= ?h 50)) @ 20) ) ) Fig. 4. An example of an axiom model.

unpredictability and uncertainty of emergency response environment, the goal state cannot be identified. Secondly, the incident objective must be achieved in specified deadline. Additionally, the time is limited and available resources are over-constrained for achieving all identified incident objectives during emergencies. Therefore, they are assigned strict priorities according to emergency response principles and evaluation criteria, which specify preferences of emergency managers. Based on the above analysis, the formalism of incident objectives is listed as following definition. Definition 4. Incident objective is of the form io = task, deadline, priority, where task is a logical work of emergency response representing the task that emergency organization must achieve; deadline defines the deadline of the incident objective, which is described by quantitative time constraints on the start time or end time of the task and the reference time of the planning process TR; the number pri ∈ {1, 2, . . . , N } represents the priority of the incident objective, pri = 1 representing the highest priority. Emergency planning problems are decision problems which ECT faces during the incident action plans developing process. According to the analysis in Section 2.1, the essence of emergency planning problems is how to achieve the identified incident objectives in the current emergency situation. The definition is listed as following definition. Definition 5. An emergency planning problem may have the form, EmProblem = (es0 , inObjSet, metric), where es0 represents the initial emergency situation; inObjSet = {io1 , . . . , ion } represents all the incident objectives which are identified during the incident action plans developing process; metric defines the plan metric which is a numeric expression specifying the preferences of emergency managers.

332


4.2. The state model and concurrency controlling mechanism For expressing numeric feature and predictive information, we propose an enhanced state model for describing the dynamic emergency situation during emergency response process. Additionally, the concurrency controlling mechanism for durative operators is introduced based on the enhanced state model. (1) The state model The state model determines which operator is applied for executing a primitive task and which method is used for decomposing a compound task during the planning process. It should represent main characteristics of the emergency situation. Firstly, emergency response involves multiple elements, including incidents, environment entities, responders, resources and so on. The planning state should describe the specification of these objects and relationships between them. Usually, they are specified by a set of predicate instances, representing attributes and the values of them at the current time. In order to express numeric features of emergency situation, we model numeric expressions as terms of the predicates for achieving mixed symbolic and numeric representation. Secondly, the predictive information described by emergency situation and the specified time stamp of it should be represented by the state model. Definition 6. The state is defined as a tuple s = (A, π, t, Eq) consisting of the following structure: (1) A = {ai } (1 i m) represents the current world state, where ai = (pt1 t2 · · · tn ) is a predicate instance, p is the predicate name and t1 to tn are argument terms; (2) π = {invariantConi = (pi − (st, et))} records a set of invariant conditions as the operator, which need to be protected during specific intervals. (3) t is the time stamp of the state, which describes the temporal attribute of emergency situation; (4) Eq = {ek } (1 k l) is an event queue consisting of a set of updates which are scheduled to occur at specified time in the future. They keep track of changes that will be made to future states. For an event ek = (ak , flagk , tk ), ak is a predicate instance representing an effect, tk specifies the time when an event is scheduled to occur. At the time of tk time units after the time stamp of the state t, the event is triggered. The

flagk represents a Boolean value. If flagk has the Boolean value True, the logical atom ak is added to A after the event is triggered. Otherwise, it is delete from A. Additionally, the events are sorted according to the ascend order of the time stamp in the event queue.

Unlike classical planning, the enhanced state model not only describes the current world state, but also represents the future changes of the world. As timed initial literals defined in PDDL 2.2 [14], the event queue provides a simply way for expressing exogenous events which represent facts that will become True or False at specific time. Events are used to represent the predictive information which is generated in incident action plans developing process by our planner. Additionally, the time stamp of the initial state is assigned the reference time of the planning process TR. This time can be set to any given time point, such as 8:30 AM on a day. The emergency response process can be described as a sequence of the enhanced states, which are transformed by executing plan steps. (2) Concurrency controlling mechanism for multiple durative operators For a given state, there may be multiple primitive tasks that can be applied. Therefore, the concurrency controlling mechanism, which is capable of dealing with concurrent actions with different duration, is very important during the planning process. It can ensure that the actions with the same time stamp are mutual exclusive and can be executed in any order. Bachhus [2] proposed a simple way of modeling concurrency with linear actions sequences, called event queue mechanism. Our planner adopts the concurrency controlling mechanism for ensuring parallelism of multiple durative operators. In this approach, the instantaneous preconditions and the effects of the operator achieve concurrency controlling. At any particular time, a number of actions can be executed concurrently in our planner. Excepting operators, there is a specific action that advances the time stamp of the state: the advance-time action [13]. The advance-time action is applicable in any state that has a non-empty event queue. If there are multiple events having the same minimum time stamp, they will all be removed from s.Eq and be triggered sequentially to update s.A.


4.3. The task net and time constraints management For handling complex time constraints effectively, we extended the model of task net in state-based forward HTN planning paradigm. Additionally, the time constraint propagation algorithm is integrated into the planning process. (1) The task net Task is a general unit of a work representing an activity to be performed. In classical HTN planning paradigm, the task net can only describe partial orders of tasks. In XEPlanner, we add two time points representing the start time and end time of each task. Then, time constraints on all the tasks in the task net are encoded by a Simple Temporal Network STN = (X, D, C) [12]. X = {TR, t1 , t2 , . . . , t2n , t2n+1 }, t2i and t2i+1 represent the start time and end time of a task; D is the domain of time variable and is always the domain [0, +∞]; C = {cij } is a set of time constraints on the time variables in X. The time constraint cij is defined on time points tpi and tpj and have the standard form: aij tpj − tpi bij . Based on the above discussion, the task net is defined as following definition. Definition 7. Task net has the form taskNet = (taskSet, STN), where taskSet = (t1 · · · tm ) represents a set of tasks; STN is a simple time net encoding all the time constraints on the start time and end time of all the tasks in taskSet. Based on the STN, we can represent the qualitative and quantitative time constraints which are defined in the methods with a unified formalism. The qualitative time constraint (:ordered t1 t2 ) is represented by 0 (start@t2 ) − (end@t1 ) +∞. Additionally, the first form of quantitative time constraints in the method model can be encoded as −∞ tpi − tpj value; the second one can be described as value tpi − tpj +∞; the third one is represented by −∞ tpi −tpj value − δ (δ is a minimum positive number), and the last one is encoded as value + δ tpi − tpj +∞. (2) Time constraint management During the planning process, the time constraints are added to the simple time network related to a task net by two kinds of planning steps. Firstly, when an operator unifying to a primitive task is applied, the time constraints defining its start time and duration are added to encode the causal relationship between different oper-

333

ator instances. Secondly, once a compound task is decomposed into subtasks, the detailed time constraints which are described in the method are introduced to the STN for arranging subtasks. To achieve efficient management of the time constraints generated during planning, it is necessary to check consistency of the STN which encodes all the time constraints on tasks in the current task net. When the time constraints are added to STN, the planning algorithm triggers the algorithm PC-2 [12] to check whether the STN related to the current task net is of consistency. It is a time constraint propagation algorithm designed for the planning process, where the time constraints are posted increasingly as the problem is being solved. If the STN is not consistent, the current plan refining step cannot be executed. Therefore, time constraints management provides an effective approach for controlling the search process during planning.

5. Anytime heuristic search algorithm In the emergency response context, the decision logic of developing incident action plans is to search a set of action plans for achieving the identified incident objectives under time constraints. Once an incident occurs, the decision logic is triggered to take the emergency planning problem and domain knowledge as input, and outputs a set of incident action plans. For satisfying planning requirements PR4, PR5 and PR6, it is not feasible to find a complete or optimal plan in the limited time. Therefore, the planning algorithm of our planner follows the design principles of an anytime heuristic search algorithm [22]. In this section, the planning algorithm is presented. Additionally, we introduce the heuristics for selecting the search node, the approach for handing priorities of incident objectives and how to generate the child nodes for a given search node during the planning process. 5.1. An anytime heuristic search algorithm The planning algorithm of XEPlanner is shown in Fig. 5, which is an anytime heuristic search algorithm. The input arguments consist of an emergency planning problem Pro and the domain knowledge D. It performs a search process guided by the heuristics in the space of all the decompositions of the given initial task network. Once the planning process is interrupted, a set of

334

1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: 22: 23: 24: 25: 26:


function HPXEDM (Pro, D) P ← null; T0 ← {t ∈ T | no other task in Pro.w0 precedes t}; openList ← {(Pro.s0 , Pro.w0 , P , T0 , 0)}; planList ← null; bestMetric ← worst case upper bound; while openList is not null and not interrupted do curNode ← extract the best node in openList; if metricFn(curNode) is worse than bestMetric then if curNode.w are null then planList.addPlan(curNode.P ); bestMetric ← metricFn(curNode); else childNodeList ← get all child nodes of curNode; for each childNode ∈ childNodeList merge childNode to openList; end for each end if end if end while if planList = null return planList; else return openList; end if end function

Fig. 5. The anytime heuristic search algorithm.

complete plans sorted by the metric value and search nodes sorted by the heuristic values are returned. As shown in Fig. 5, the variable planList stores the completed plans having been found in the current time. The metric value of the complete plan found in the latest time is recorded by bestMetric. It is initialized to a value representing the upper bound of the worst case. Additionally, the metric value of the complete plan added later is better than the one having been added in the former. Each node in the search space is of the form, (s, w, P , T0 ), where s is the state during the planning process, w represents the task network, P is a partial plan that the planner has already produced and T0 is a set of tasks having no predecessors in w. The variable openList records all the search nodes that have been searched. The initial search node is (Pro.s0 , Pro.w0 , null, T0 ), which is added to openList for initializing it. All the search nodes in openList are arranged according to the heuristics for selecting search nodes, which will be introduced later in Section 5.2. The planning process is performed in the main while loop from line 7 to line 20 and executes a search strat-

egy guided by the heuristics in the search node space. The search process terminates when it is interrupted or the variable openList is empty (line 7). In each iteration, the algorithm extracts the best search node curNode from openList based on the designed heuristics and set it to be the current search node (line 8). If the metric value of it is worse than the variable bestMetric, the planning algorithm prunes the search node curNode from openList (line 9). Otherwise, the condition of finding a new complete plan is checked, which is satisfied when there is no task in curNode.w (line 10). If a new complete plan is found, the planning algorithm adds it to planList (line 11). Additionally, the value of bestMetric is updated by the metric value of curNode (line 12). Otherwise, the algorithm gets all the child search nodes of curNode and stores them by the variable childNodeList. The process of generating the child search nodes for a given search node is introduced in Section 5.3. Then, each search node in childNodeList is added into openList at the specified position which is determined by the heuristic value of it. Finally, after the loop is terminated, if there are complete plans having been generated, the planning algorithm returns a set of plans stored by planList (line 22). Otherwise, a list of search nodes stored by openList is returned (line 24). The algorithm has two distinctive features. Firstly, the search process can be interrupted at any time and outputs plans having been generated at once. Additionally, our planner improves the quality of the action plans progressively and obtains plans of better quality when there is available time. The details are introduced as following: (1) The flexible interruption mechanism XEPlanner is based on the anytime algorithm for providing reactivity and flexible decision support in real-time, dynamic and complex emergency response process. Therefore, it must be interrupted and generates solutions of the emergency planning problem at any time for accomplishing the planning requirement PR5. During the search process, the plans are always represented by search nodes. The current partial plan having been produced is represented by P . Additionally, w represents the plan with abstraction to be executed in the current planning state. If the algorithm is interrupted, the planning algorithm terminates and returns the search space having been constructed so far, which is recorded by the variable openList.


The search node that has been processed longer will contain more detailed information than those which are processed in less planning time. The planning process of XEPlanner is only a part of incident action plans developing process. Despite the output search nodes cannot be executed directive, they can be passed to emergency managers for dealing with the abstractness of the plan representation. (2) Pruning the search space To be effective, the planning algorithm searches for better solutions in the search nodes space based on branch and bound optimization during the planning process. The algorithm prunes any search node which is evaluated not to reach a better complete plan than the best one having been found so far in the variable openList. Pruning is achieved by the planning algorithm in line 9. In each loop, we use the metric value of the best complete plan found so far, which is stored by the variable bestMetric, to prune the search nodes in openList for improving the performance of the search process. The algorithm prunes a search node curNode, if the metric value of it is estimated to be poor than bestMetric. Once a complete plan is found, the value of bestMetric is updated. Therefore, the pruning constraint imposes a tighter bound and causes more search nodes stored in the variable openList to be rejected. The above pruning strategy is sound. Whenever a search node is pruned, the metric value of complete plans generated from it is proved to be worse than the best complete plan having been found. Additionally, the pruning strategy guarantees that the quality of the generated complete plans increases monotonically during the planning process. 5.2. Heuristics for selecting search nodes To be effective and fast for finding solutions, it is essential for the search process to be guided. During the planning process of XEPlanner, the search strategy is how the planning algorithm evaluates the search nodes in openList and selects the most “promising” one to execute the plan refining steps. The search nodes contain all the heuristic information that is used for evaluating and comparing them. In the current time, we have designed three kinds of heuristics for selecting search nodes from openList. (1) Relaxed conditions heuristic

335

The evaluation function of relaxed conditions heuristic is expressed as: f (curNode) = metricFn(curNode) + weight ∗ h(curNode), where metricFn(curNode) is the plan metric value of executing the current partial plan curNode.partialPlan in the initial state and h(curNode) is the estimate of the plan metric value for achieving the task network curNode.w in the planning state curNode.s, weight is the weight value which makes the search process greedier. The value metricFn(curNode) can be computed easily according to the current known partial plan. However, there are many ways to execute the compound task in curNode.w. Therefore, we cannot know the actual value of plans for achieving all tasks in curNode.w until they are all refined. For computing the heuristic value in the polynomial time, we define a relaxed task net based on the temporal HTN planning. In the temporal HTN planning paradigm, the STN implies high expressiveness for handling the time constraints, but it implies additional computation time for checking its consistency. The relaxed task net is constructed ignoring quantitative time constraints and does not check consistency of the STN related to the task net during planning process. Additionally, the invariant conditions of the operators are also ignored during the process of computing the heuristic value. For extracting a relaxed plan in the least time, the algorithm executes a depth first search and backtracking procedure as SHOP2. Firstly, for a compound task having no predecessors in curNode.w, the algorithm decomposes it by the first applicable method m to update the task net. Secondly, for a primitive task having no predecessors in curNode.w, the algorithm applies the first operator for updating the planning state. Finally, if there are events in event queue of curNode.s, the planning algorithm triggers all the events in the event queue with the minimum time stamp. Finally, a relaxed plan rp will be generated, which is executed in curNode.s, and achieves all the tasks in the task net curNode.w. Additionally, a final state rEndState will be got. Then the relaxed task net heuristic value will be computed easily. This algorithm is on the same foundation of SHOP2, which is a state based forward planning algorithm and executes a depth first search and backtracking procedure during the planning process. However, unlike the planning algorithm of SHOP2, in our algorithm, the compound task is decomposed firstly. If there are not tasks having no predecessors and that can be refined

336


in the task net, all the events in current planning state with minimum time stamp are triggered. (2) Planning depth heuristic Excepting the above heuristic, we defined the depth of the search node as another heuristic for guiding the search process. The planning algorithm selects the search node with the biggest depth to execute the plan refining step. The depth of a search node is the number of the planning steps having been executed on the initial search node for getting it. The planning depth heuristic does not take the preferences of emergency managers into account. However, it encourages the planner to find a complete plan in least time. (3) Priority heuristic Though the relaxed task net heuristic can estimate h(curNode) exactly and take into account the preferences, it costs much running time during the planning process. Therefore, we define a third heuristic called priority heuristic, which corresponds to a sequence of evaluation according to the above two heuristics. When comparing two search nodes, the planning algorithm follows the steps: (1) Firstly, it checks their planning depth, and chooses the search node with higher planning depth. (2) If they have the same planning depth, the relaxed task net heuristic values of them are computed and the search node with higher value is selected. Additionally, designing effective heuristics for selecting search nodes that take into account the preferences of the emergency managers is the research interest of future work. 5.3. Generating the child search nodes This section will introduce how to get the child nodes of a given search node, which is another key problem in the planning procedure in Fig. 5. For a given search node, curNode = (s, w, P , T0 ), the child search nodes of it are all the search nodes by executing plan refining steps on it, including: applying operators for the primitive tasks, decomposing the compound tasks in curNode.T0 , and triggering all the events with minimum time stamps in event queue of curNode.s. As well as the search node to be refined is selected, the algorithm will determine which active task having no predecessors in curNode.T0 should be reduced next. Usually, there is more than one active task. We

define the rules for selecting the active task atom as following: (1) the first compound task in curNode.T0 that has never been tried in the current state is chosen; (2) if there are no such tasks, the first primitive task is selected. The heuristic for selecting active tasks gives more chance for decomposing the compound tasks, which is particularly useful for searching complete action plans in limited planning time. Once an active task is selected, the following plan refining procedure is executed for generating the child nodes for the given search node. If the chosen task t is a compound task, the planning algorithm executes the procedure for decomposing it. For each method m unifying to t and each most unifier satisfier mgs, this planning algorithm removes the task t from the task net curNode.w and decomposes it with the method m and the most unifier satisfier mgs for updating curNode.w. Otherwise, the algorithm executes the action execution procedure. For each operator o unifying to t and each most unifier satisfier mgs, the planning algorithm removes the task t from the task net curNode.w and applies the operator to update the state curNode.s. Finally, if there is no task in curNode.T0 which can be refined and the variable curNode.s.Eq is not null, the algorithm triggers all the events with the minimum time stamps in the event queue one by one for getting the child search node. After the above procedures are executed, all the child search nodes are generated and are added to the variable openList. 5.4. Handling priorities of incident objectives To satisfy planning requirement PR6, we propose a mechanism for handling priorities of incident objectives during the planning process. The mechanism includes two steps, which are listed as following: Firstly, a term pri representing priority is added to compound tasks, primitive tasks and operators. During the planning process, when a compound task is decomposed, the priorities of the subtasks are initialized by that of this compound task. Similarly, when a primitive task is applied, the priority of the operator instance equals to that of the primitive task. Secondly, a heuristic is designed to select a task among the active tasks having no predecessors in the task net curNode.w to execute the plan refining steps. If there is more than one task in curNode.T0 having the right to be refined, the planning algorithm selects the task with higher priority to execute the plan refining steps.


The proposed mechanism for handling priorities of incident objectives is useful when multiple tasks are pursued simultaneously and gives more chance to tasks with higher priorities to be refined. Therefore, it handles priorities of tasks in the planning process effectively and adapts to the characteristics of incident action plans developing process.

6. Experimental evaluation In the current time, XEPlanner has been implemented based on JSHOP2, which is a java implementation of SHOP2 [24]. A set of experiments have been conducted to evaluate the performance of our planner based on the prototype implementation of it. In the remainder of this section, we define a flood evacuation domain based on the case in Section 3.1 for testing the performance of our planner. Then, the experimental results are given. Our main aim is not to compare the performance of our planner but to highlight the advantages our planning paradigm brings. 6.1. Knowledge modeling In order to develop incident action plans based on XEPlanner, it is necessary to describe the application domain by the proposed knowledge formalisms. The knowledge for the flood evacuation case consists of emergency actions, standard operation procedures, emergency situation, incident objectives and preference of flood commanders. All of the elements are modeled by the proposed knowledge formalisms. (1) Domain knowledge Firstly, XEPlanner requires a set of operators for describing emergency actions of relevant responders. For example, the emergency actions for issuing evacuation command, boarding the residents on the transportation vehicles, preparing evacuation and so on. All of them are described by the knowledge formalism of durative operators in Section 4.1. Additionally, flood commanders establish a set of programs to act as guidelines for the emergency response work. During the evacuation process, the flood commander should inform the residents in the affected areas if the flood level exceeds 42 m and is forecasted to rise to more than 45 m in the water level station. Moreover, the elementary governments of residential areas in danger must collect all the residents to prepare for the evacuation in the given time once they receive

337

the evacuation command. At the same time, transportation teams should be dispatched to the residential areas in danger for transporting them to specific shelters. All the standard operation procedures are encoded by the knowledge formalism of method in Section 4.1. The domain knowledge for the flood evacuation case includes five operators, four methods and two axioms.1 (2) Emergency planning problem The emergency planning problem consists of three elements, including: emergency situation, incident objectives and preferences of flood commanders. Firstly, the elements of emergency situation include the current flood level and its developmental trend, residents, emergency teams, the road map and so on. For example, the current time of the hypothetical emergency situation is 12:00 on August 1, 2010. The current flood level in water level station (loc-1) is 42 m. Flood commanders forecast that the flood level will rise to 46 m 20 h later in the water level station. Additionally, the initial emergency situation also describes the relevant information of residential areas in danger of flooding, shelters for resettling evacuees, the state of communication tools, emergency teams for transporting evacuees, transportation network in the evacuation area, and so on. All the above information is modeled by the enhanced state model in Section 4.2. Secondly, the incident objectives are described by tasks with deadlines and priorities, which are defined by incident objective model in Section 4.1. In this specific application domain, an incident objective represents which residential areas will be flooded and must be evacuated. Finally, preferences of the flood commanders are usually specified by (1) minimizing response time of achieving all the incident objectives; (2) minimizing cost of the response process. An example of the plan metric representing preferences is expressed as: (plan-metric: minimize (4∗totalTime + totalCost)) as PDDL 2.1. 6.2. Experimental results The above flood evacuation domain is a challenge for many domain-independent HTN planners. In this section, we conduct a set of experiments to evaluate the 1 The knowledge formalism of the domain knowledge model is downloaded from http://tangpan001.blog.163.com/blog/static/ 38261147201102972249812/.

338


performance of XEPlanner in the specific domain and ZenotravelTime domain. All the experiments were run on a PC (Windows 7) equipped with 3.06 GHz Pentium i3 CPU and 2 GB RAM. (1) Evaluation results in flood evacuation domain This experiment is carried out to test the performance of our planner in flood evacuation domain. Firstly, we generated different sets of incident objectives randomly based on the above emergency situation. Secondly, we assume that the number of available teams for transporting residents in flooded areas increases in the experiment. Then, 20 emergency planning problems are generated randomly. Then, the experiment is carried out to solve all the problems for testing the performance of our planner in the flood evacuation domain. The heuristic for selecting search nodes during the planning process is set to be different heuristics in Section 5.2. Additionally, the value of weight in the relaxed conditions heuristics is set to be 1. The plan metric is set to be (plan-metric: minimize (4∗totalTime + totalCost)). Once the first complete plan is generated, the planning process terminates. Table 2 shows the plan metric values of the output plans and the running time for generating them

by XEPlanner with different heuristics for selecting search nodes. Obviously, the solutions generated by our planner when using the relaxed conditions heuristic are more optimal in all emergency planning problems than the other heuristics. However, it costs more running time and solves the least problems. Instead, the plan depth heuristic version of our planer can solve all the problems and cost less running time. However, it generates plans with the worst plan metric values. The experimental results prove that the running time of the priority heuristic version of our planner is within the acceptance range when XEPlanner is used in practical applications. Additionally, the experimental results show that our planner provides an effective method to handle preferences of emergency managers. (2) Comparison of XEPlanner and Sapa The experiment is carried out for comparing the performance of our planner to that of state-of-the-art planners. The most similar state-of-the-art planner to XEPlanner is Sapa. It is a domain-independent heuristic forward chaining planner that can handle durative actions, metric resource constraints, and deadline goals [13]. Especially, it uses the same concurrency con-

Table 2 Experimental results in the flood evacuation domain Problem number

Number of incident objectives

Available teams

Problem1 Problem2 Problem3 Problem4 Problem5 Problem6

2 3 4 5 5 6

Problem7 Problem8 Problem9 Problem10 Problem11

Planning depth heuristic

Priority heuristic

Relaxed conditions heuristic

Plan metric value

Running time (s)

Plan metric value

Running time (s)

Plan metric value

Running time (s)

Team1,2,5 Team1,2,5 Team1,2,5 Team1,2,5 Team1,2,5 Team1,2,5

144.0 178.0 245.6 306.0 306.0 432.0

4.150 10.809 26.271 56.650 57.159 118.797

144.0 171.6 232.8 290.0 293.2 368.0

4.151 10.827 26.271 56.660 57.690 112.789

144.0 – – – – –

7.239 – – – – –

3 3 4 4 5

Team1,2,3,4 Team1,2,3,4 Team1,2,3,4 Team1,2,3,4 Team1,2,3,4

178.0 178.0 212.0 228.0 298.0

10.827 11.873 28.861 28.058 63.373

178.0 178.0 212.0 216.0 –

10.827 11.873 28.892 28.073 –

162.0 174.0 – – –

22.668 23.230 – – –


2 2 2 2 2 3

Team1,2,3,4,5 Team1,2,3,4,5 Team1,2,3,4,5 Team1,2,3,4,5 Team1,2,3,4,5 Team1,2,3,4,5

140.0 140.0 156.0 140.0 156.0 178.0

4.035 4.033 4.033 4.041 4.036 11.540

140.0 104.0 114.0 140.0 114.67 178.0

4.035 4.034 4.038 4.034 4.034 11.538

108.0 104.0 106.0 125.33 114.67 148.67

94.581 32.582 20.057 171.083 87.592 74.209

Problem18 Problem19 Problem20

4 5 5

Team1,2,3,4,5 Team1,2,3,4,5 Team1,2,3,4,5

198.0 250.0 246.0

32.979 67.971 71.060

– – –

– – –

– – –

– – –


339

Table 3 Comparison of XEPlanner and Sapa in the ZenotravelTime domain XEPlanner

Problem number

Sapa

Planning depth heuristic

Make span

Running time (s)

Make span


3.42 23.43 13.26 32.32 22.12 38.82

0.234 0.062 0.078 0.094 0.094 0.094

3.42 23.43 10.18 21.54 19.64 40.16


32.63 40.88 37.08 66.99 34.41 55.83

0.109 0.125 0.141 0.203 0.156 0.422

Problem13 Problem14 Problem15

71.94 − −

0.624 − −

Priority heuristic

Running time (s)

Relaxed conditions heuristic

Make span

Running time (s)

Make span

Running time (s)

0.546 0.535 1.062 3.621 12.886 11.89

3.42 23.43 6.00 − − −

0.546 10.843 83.945 − − −

3.42 23.43 − − − −

0.546 11.358 − − − −

40.08 29.66 29.66 − 31.49 41.03

12.387 35.023 35.538 − 20.094 69.000

− − − − − −

− − − − − −

− − − − − −

− − − − − −

41.03 32.79 43.75

73.092 315.549 7230.448

− − −

− − −

− − −

− − −

trolling mechanism for durative operators as our planner. In this experiment, we selected 15 problems randomly in Zenotravel Time domain. XEPlanner and Sapa are run to solve all of them. The plan metric is set to be (plan-metric: minimize (totalTime)), making it make-span based entirely. The heuristic for selecting search nodes during the planning process is set to be different heuristics in Section 5.2. Additionally, once a complete plan is generated, the planning process of the two planners terminates. Table 3 shows the experimental results. As shown, the plan depth version of XEPlanner can solve most of the problems. The make-span of all plans output by it is not longer than those generated by Sapa. Additionally, XEPlanner can only solve a few problems when it uses the priority heuristic and relaxed conditions heuristic for selecting search nodes during the planning process. However, the plan depth version of our planner costs more running time. The main reason is that it runs PC-2 algorithm for achieving temporal reasoning once new time constraints are generated during the planning process. Instead, Sapa does not support time constraints management. Obviously, XEPLanner performs very well on the specific domain, while it is not comparable to state-of-the-art planners when dealing with HTN benchmark problems.

(3) Evaluating predictive information handling methods Fox proposes an approach that can compile timed initial literals into standard temporal PDDL [19]. For evaluating whether or not the more direct handling method for predictive information of XEPlanner yields benefits, we designed 10 sets of events in the flood evacuation domain. The predictive information described by the events represents the flood developmental trend and available teams that will come into the evacuation area in the future. Then, we model them by the knowledge formalisms of our planner and the PDDL 2.1 handling method proposed by Fox respectively. In this experiment, the plan metric is set to be (plan-metric: minimize (4∗totalTime)). The planner uses planning depth heuristic for selecting search nodes during the planning process. Additionally, the planning procedure terminates, once the first complete plan is generated. The experimental result is shown in Table 4. As shown, these two methods for handing predictive information output the same solution. However, the planner using our directive handling method outputs the plan in shorter running time for all the planning problems. In other words, the proposed method for handling predictive information in this paper yields benefits in flood evacuation domain comparing to the standard PDDL 2.1 encoding.

340

P. Tang et al. / Anytime heuristic search in temporal HTN planning for developing incident action plans Table 4 Comparison of different method in the FloodEvacuation domain Problem number

Directive handling method

PDDL 2.1 handling method

Make span

Running time (s)

Make span

Running time (s)

Problem1 Problem2 Problem3 Problem4

14.5 14.5 14.5 14.5

4.182 12.372 12.045 31.684

14.5 14.5 14.5 14.5

4.550 13.916 12.902 32.963


31.0 28.0 33.0 28.0 31.0 36.0

18.050 3.635 10.828 10.828 11.343 11.342

31.0 28.0 33.0 28.0 31.0 36.0

22.153 5.180 13.393 13.401 12.881 12.887

7. Conclusions and future work Extreme events present social organizations with complex, unpredicted situations and have the potential for widespread catastrophic losses. In this paper, we presented an anytime HTN planner, which is designed to assist ECT for developing incident action plans in dynamic environment with time constraints. This planner is based on the well-known AI planning technologies, such as anytime heuristic search, task decomposition, time constraints management, concurrency controlling, but combines them in a novel approach. The paper proposes a number of main planning requirements for designing HTN planners to support incident action plans developing process. According to the planning requirements and shortcomings of current known HTN planners, an anytime heuristic HTN planner for representing and solving incident action plans developing decision problems during the emergency response process is proposed. As an on-line planner, it is able to generate feasible or suboptimal plans in any given time, and scales up very well in specific application domains of emergency management. Therefore, our planner provides quick response to dynamic emergency situations. A first application of our planner is dedicated to the management of flood controlling. The experimental results show that it adapts to the task constraints and the planning requirements very well. Additionally, our planner can also support the incident action plans developing process for other extreme events. The core contributions of our work are: (1) a set of planning requirements for designing HTN planner for

this specific application domain; (2) an anytime heuristic planning algorithm and the heuristics for selecting search nodes during the planning process for adapting to the response environment demands; (3) an expressive method model for representing standard operation procedures in emergency management. The research work in this paper is the first step during the development of a DSS for extreme events decision making. This planner will be embedded into it to act as a reasoning logic for developing incident action plans.

Acknowledgements This work was supported by National Science Foundation Grant of China (projects No. 90924301, No. 71125001, No. 91024032 and No. 70971048), Fundamental Research Funds for the Central Universities of China (project No. 21612301) and the third phase of 211 major project of Guangdong province “Emergency management theory and practice”.

References [1] J.M. Agosta and D.E. Wilkins, Using SIPE-2 to plan emergency response to marine oil spills, IEEE Expert 11(6) (1996), 6–8. [2] F. Bacchus and M. Ady, Planning with resources and concurrency: a forward chaining approach, in: Proceeding of 17th International Joint Conference on Artificial Intelligence, Morgan Kaufmann, San Francisco, CA, USA, 2001, pp. 417–424. [3] A.J. Baier and A.S. Mcllraith, Planning with preferences, AI Magazine 29(4) (2008), 25–36.

P. Tang et al. / Anytime heuristic search in temporal HTN planning for developing incident action plans [4] S. Biundo and B. Schattenberg, From abstract crisis to concrete relief. A preliminary report on flexible integration on nonlinear and hierarchical planning, in: Proceedings of the 6th the European Conference on Planning, Toledo, Spain, A. Cesta and D. Borrajo, eds, Springer, Heidelberg, 2001, pp. 157–168. [5] L. Castillo, J. Fdez-Olivares, García-Pérez and F. Palao, Efficiently handling temporal knowledge in an HTN planner, in: Proceedings of 16th International Conference on Automated Planning and Scheduling, ACM Press, New York, 2006, pp. 63–72. [6] L. Castillo, J. Fdez-Olivares, O. García-Pérez and F. Palao, Temporal Enhancements of an HTN Planner, Lecture Notes in Computer Science, Vol. 4177, Springer, 2006, pp. 429–438. [7] L. Castillo, J. Fdez-Olivares and A. Gonzalez, On the adequacy of hierarchical planning characteristics for realworld problem solving, available at: http://decsai.ugr.es/~lcv/ Research/Publications/Papers/Ecp01.ps. [8] R. Chen, R. Sharman, H.R. Rao and S.J. Upadhyaya, Coordination in emergency response management, Communications of the ACM 51(5) (2008), 66–73. [9] J. Cosgrave, Decision making in emergencies, Disaster Prevention and Management 5(4) (1996), 28–35. [10] M. de la Asuncion, L. Castillo, J. Fdez-Olivares, O. GarcıaPerez, A. Gonzalez and F. Palao, Knowledge and plan execution management in planning fire-fighting operations, available at: http://www.plg.inf.uc3m.es/~dborrajo/ecai04workshop/papers/AsuncionEtAl.pdf. [11] M. De La Asunción, L. Castillo, J. Fdez-Olivares, Ó. GarcíaPérez and F. Palao, SIADEX: an integrated planning framework for crisis action planning, AI Communications 18(4) (2005), 257–268. [12] R. Dechter, I. Meiri and J. Pearl, Temporal constraint networks, Artificial Intelligence 49 (1991), 61–95. [13] M.B. Do and S. Kambhampati, Sapa: a multi-objective metric temporal planner, Journal of Artificial Intelligence Research 20 (2003), 155–194. [14] S. Edelkamp and J. Hoffmann, The language for the 2004 international planning competition, available at: http://www.cs.unidortmund.de/edelkamp/ipc-4/pddl.html. [15] M.R. Endsley, Toward a theory of situation awareness in dynamic systems, Human Factors 37(1) (1995), 32–64. [16] K. Erol, J. Hendler and D. Nau, Complexity results for hierarchical task network planning, Annals of Mathematics and Artificial Intelligence 18(1) (1996), 69–93. [17] Extreme Event Decision Making, Workshop report, National Science Foundation Board Room, available at: http://www. albany.edu/cpr/xedm/. [18] M. Fox and D. Long, PDDL 2.1: an extension to PDDL for expressing temporal planning domains, Journal of Artificial Intelligence Research 20 (2003), 60–124. [19] M. Fox, D. Long and K. Halsey, An investigation into the expressive power of PDDL 2.1, in: ECAI, Valencia, Spain, IOS Press, 2004, pp. 328–342. [20] M. Ghallab and H. Laruelle, Representation and control in IxTeT, a temporal planner, in: Proceedings of AIPS’1994, AAAI Press, Chicago, IL, USA, 1994, pp. 61–67. [21] M. Ghallab, D. Nau and P. Traverso, Automated Planning: Theory and Practice, Morgan Kaufmann, San Francisco, CA, 2004. [22] E.A. Hansen and R. Zhou, Anytime heuristic search, Journal of Artificial Intelligence Research 28 (2007), 267–297.

341

[23] L.L. Hereth, Setting objectives in a unified command: the “COST” of leadership, in: Proceedings of the 2005 International Oil Spill Conference, American Petroleum Institute, Miami, FL, USA, 2005, pp. 7663–7671. [24] O. Ilghami, Documentation for JSHOP2, Technical Report CSTR-4694, Department of Computer Science, Univ. Maryland, February 2005. [25] P. Laborie and M. Ghallab, IxTeT: an integrated approach for plan generation and scheduling, in: Proceedings of Emerging Technologies and Factory Automation, Paris, France, IEEE Press, 1995, pp. 485–495. [26] F.J. Lerch and D.E. Harter, Cognitive support for real-time dynamic decision making, Information Systems Research 1 (2001), 63–82. [27] P.W. Loria, I. Nikhil and C.J. Lakhmi, Intelligent Decision Making An AI-Based Approach, Springer, Berlin, 2008. [28] D. Mendonca, Decision support for improvisation in response to extreme events: learning from the response to the 2001 World Trade Center attack, Decision Support Systems 43(3) (2007), 952–967. [29] D. Mendonca and W.A. Wallace, A cognitive model of improvisation in emergency management, IEEE Transactions on Systems, Man and Cybernetics – Part A (Systems and Humans) 37(4) (2007), 547–561. [30] H. Munoz-Avila, D.W. Aha, L. Breslow and D. Nau, HICAP: an interactive case-based planning architecture and its application to noncombatant evacuation operations, in: Proceedings of the 16th National Conference on Artificial Intelligence, AAAI Press, Menlo Park, CA, 1999, pp. 870–875. [31] A. Nareyek, E.C. Freuder, R. Fourer, E. Giunchiglia, R.P. Goldman, H. Kautz, J. Rintanen and A. Tate, Constraints and AI planning, IEEE Intelligent Systems 20(2) (2005), 62– 72. [32] National Incident Management System, http://www.icisf.org/ articles/NIMS.pdf. [33] D. Nau, Y. Cao, A. Lotem and H. Munoz-Avila, The SHOP planning system, AI Magazine 22(3) (2001), 91–94. [34] D. Nau, A. Tsz-Chiu, O. Iighami, U. Kuter, J.W. Murdock, D. Wu and F. Yaman, SHOP2: an HTN planning system, Journal of Artificial Intelligence Research 20 (2003), 379–404. [35] D. Nau, A. Tsz-Chiu, O. Ilghami, U. Kuter, D. Wu, F. Yaman, H. Muñoz-Avila and J.W. Murdock, Applications of SHOP and SHOP2, IEEE Intelligent Systems 20(2) (2005), 34–41. [36] J.C. Pomerol, Artificial intelligence and human decision making, European Journal of Operational Research 99(1) (1997), 3–25. [37] A. Roger and J. Pielke, The role of models in prediction for decision, available at: http://www.albany.edu/cpr/xedm/ Materials/Pielke_Cary.pdf. [38] B. Schattenberg, Hybrid planning and scheduling, PhD thesis, available at: http://vts.uni-ulm.de/query/longview.meta. asp?document_id=6895. [39] B. Schattenberg, S. Biundo, M. Ghallab, J. Hertzberg and P. Traverso, On the identification and use of hierarchical resources in planning and scheduling, in: Proceedings of the 6th International Conference on Artificial Intelligence Planning Systems, AAAI Press, Menlo Park, CA, 2002, pp. 263–272. [40] C. Siebra, Planning requirement for hierarchical coalitions in disaster relief domains, Expert Update 8(1) (2005), 20–24. [41] C. Siebra, A unified approach to planning support in hierar-

342

[42]

[43] [44] [45]

[46] [47]

[48]

P. Tang et al. / Anytime heuristic search in temporal HTN planning for developing incident action plans chical coalitions, PhD thesis, available at: www.aiai.ed.ac.uk/ project/ix/project/siebra/resources/SiebraThesis.pdf. C. Siebra and A. Tate, I-Rescue: a coalition based system to support disaster relief operations, in: Proceeding of 3rd International Conference on Artificial Intelligence and Applications, Benalmadena, 2003. M. Silvia, Plan management in the medical domain, AI Communications 12 (1999), 209–235. H.A. Simon, The New Science Of Management Decision, Prentice Hall, Upper Saddle River, NJ, 1977. W. Smith and J. Dowell, A case study of coordinative decisionmaking in disaster management, Ergonomics 43(8) (2000), 1153–1166. Task Formalism Manual, Artificial Intelligence Applications Institute, http://scom.hud.ac.uk/planet/repository/htnkb.html. A. Tate, B. Drabble and R. Kirby, O-Plan2: An Open Architecture for Command, Planning and Control, Morgan Kaufmann, San Francisco, CA, 1994. S. Tufekci and W.A. Wallace, The emerging area of emergency management and engineering, IEEE Transactions on Engineering Management 45(2) (1998), 103–105.

[49] D.E. Wilkins and R.V. Desimone, Applying an AI Planner to Military Operations Planning, Intelligent Scheduling, Morgan Kaufmann Publishers, San Mateo, CA, 1994. [50] D.E. Wilkins and M. desJardins, A call for knowledge-based planning, AI Magazine 22(1) (2001), 99–115. [51] D.E. Wilkins and K.L. Myers, A common knowledge representation for plan generation and reactive execution, Journal of Logic and Computation 5(6) (1994), 731–761. [52] D.E. Wilkins and K.L. Myers, A multi-agent planning architecture, in: Proceeding of the 1998 International Conference on AI Planning Systems, AAAI Press, Pittsburgh, PA, USA, 1998, pp. 154–162. [53] D.E. Wilkins, K.L. Myers, J.D. Lowrance and L.P. Wesley, Planning and reacting in uncertain and dynamic environments, Journal of Experimental and Theoretical Artificial Intelligence 7(1) (1995), 197–227. [54] J.L. Wybo and K.M. Kowalski, Command centers and emergency management support, Safety Science 30 (1998), 131– 138.