Data Model for Strategic Action Planning and Scheduling Problems in DisasterResponse Teams

Paper: Reza Nourjou; 2014/4/17

Data Model of the Strategic Action Planning and SchedulingProblem in a Disaster Response Team

Reza Nourjou1, Pedro Szekely2, Michinori Hatayama1,

Mohsen Ghafory-Ashtiany3, and Stephen F. Smith4

1Informatics Graduate School and Disaster Prevention Research Institute, Kyoto University, JapanE-mail: {nourjour, hatayama}@imdr.dpri.kyoto-u.ac.jp

2Information Sciences Institute, University of Southern California, USAE-mail: pszekely@isi.edu

3International Institute of Earthquake Engineering and Seismology, IranE-mail: ashtiany@iiees.ac.ir

4The Robotics Institute, Carnegie Mellon University, USAE-mail: sfs@cs.cmu.edu

[Received ; accepted ]

Abstract. Abstract. Problem: Strategic action plan-ning and scheduling (SAP) in the coordination of adisaster response team involves selecting and decom-posing an objective into sub-goals, grouping availableunits into coalitions and assigning them to the sub-goals, allocating units to tasks, and adjusting the de-cisions that have been made. The primary responsi-bility of a team’s incident commander (IC) in SAP isto coordinate the actions of operational units in disas-ter crisis/emergency response management by makingmacro/strategic decisions.

Objective: In this paper, we completely model areal-world problem and present data related to theSAP problem. This data model is used to support thedesign and development of an appropriate approachto SAP.

Method: The employed methodology is to analyzeand study the SAP problem, which is composed of sixessential dimensions: the problem domain, geographicinformation, geospatial-temporal macro tasks, strate-gic action planning, strategic action scheduling, andteam structure.

Result: The contribution of this paper is the SAPproblem data model. It is designed as a unified mod-eling language (UML) class diagram consisting of en-tity types, attributes, and relationships associated withSAP problem data modeling.

Conclusion: To evaluate the quality of SAP datamodeling, the SAP problem data model is used to pro-pose and develop an intelligent assistant software sys-tem to assist and collaborate with incident comman-ders in SAP. The study makes five novel contributions:1) a complete data model for SAP problem modeling,2) a presentation and aggregation of task informationin geographic objects, 3) the expression and encodingof human intuition as human high-level strategy guid-ance for SAP, 4) the formulation of a strategic actionplan, and 5) the integration of strategic action sched-

ule information with other entities.

Keywords: Data Model, Problem Formulation, Strategicand Macro, Action Planning and Scheduling, Coordina-tion, Incident Commander, Disaster Emergency Response

1. Introduction

A review of previous disasters demonstrates the impor-tance of efficient responses to emergencies. Urban searchand rescue (USAR) is thought to represent a major part ofdisaster emergency response operations with the objectiveof reducing the number of fatalities in the first few daysafter the occurrence of a disaster [10]. A number of dif-ferent teams and organizations, such as Red Crescent So-ciety rapid response teams, International Search and Res-cue Advisory Group (INSARAG) teams, volunteer teams,fire-fighting teams, medical services, and road-clearingbulldozers are involved in these operations in response tocrisis situations or in supporting the activities of respon-der teams.

A disaster response team is a hierarchical organizationthat consists of two levels. The lower or operational levelincludes a number of different field units, called ratio-nal and semi-autonomous agents in this paper. Agentsmay be human personnel, robots, or human-robot teams.Their roles are to perceive their local environment, followand execute decisions made by the team’s senior officials,make their own decisions, coordinate their actions withother units, accomplish tasks according to their plans, andreport their observations of the local environment to theincident commander (IC). The IC is at the top of the hier-archy and has a global view of the environment (the stateand crisis situation of the disaster-affected area). As ahuman planner, the IC’s role is to formulate action plansand schedules for field units. Therefore, a team has an

Journal of Disaster Research Vol.0 No.0, 200x 1

Nourjou, R., et al.

Fig. 1. : Organizational structure of a disaster responseteam.

organizational structure composed of cooperative agentsdistributed over different levels. Fig. 1 presents this teamstructure and the characteristics of the two levels.

Effective coordination is crucial in emergency responsemanagement [6]. Coordination is difficult because ofthe characteristics of this domain, such as uncertain in-formation, time constraints, limited resources, and taskflow [5]. According to coordination theory, coordinationis the act of managing interdependencies among activitiesperformed to achieve a goal [23]. Coordination in disas-ter emergency response includes the management of taskflow (tasks and interdependent relationships), recourses,information, decisions, and responders [6]. Inefficient co-ordination results in ”idle” agents (inactive field units),conflict between actions, or ”redundant” activities thatcause operations to take a very long time to complete.

Planning and scheduling are two major coordinationmechanisms for the management of task dependenciesand shared resources [6], [5], [23]. Crisis response sys-tems should utilize these mechanisms in disaster crisismanagement [14], [17]. An approach to coordination inagent-based systems is to engage the agents in multi-agentplanning and scheduling [33]. The problem of how agentsshould get from the current state of the world to the de-sired goal state through a sequence of actions (a plan) rep-resents a planning problem in multi-agent systems. Thescheduling problem in multi-agent systems relates to thesuitable assignment of limited resources (agents) to time-consuming tasks within a specified time window and cop-ing with a set of constraints and requirements over time inorder to maximize an optimization criterion.

In organization theory, strategic management toachieve organizational objectives consists of four basicelements: environmental scanning, strategy formulation,strategy implementation, and evaluation and control [12].Strategic planning is a coordination approach to managingrelationships among tasks by setting objectives (goal se-lection and goal decomposition) and grouping people intounits [23]. For example, the incident command system isa top-down approach that uses strategic/macro planning tocoordinate the actions of operational units. The incidentcommand system of the National Incident ManagementSystem creates incident action plans over five phases: 1)understanding the situation, 2) establishing incident ob-jectives (priorities, objectives, strategies, tactics/tasks), 3)developing an action plan, 4) preparing and disseminat-ing the plan, and 5) continually executing, evaluating, and

Fig. 2. : The strategic action planning and schedulingwork flow in a team.

revising the plan [3], [1], [9].SAP (strategic action planning and scheduling) com-

prises coordination mechanisms within a team. SAP in-cludes selecting and decomposing an objective into sub-goals, grouping available units into coalitions and assign-ing the consequent coalitions to the sub-goals, allocatingtasks to units, and adjusting the decisions that have beenmade. In other words, solving a SAP problem results inthree types of decisions: a high-level strategy, a strate-gic action plan, and a strategic action schedule. Relativeto tactical decision-making, which is carried out by units,SAP involves making macro decisions for team activitiesthat constrain and limit the micro activities of field unitsat the lower level. SAP, therefore, is critical in teams. Fig.2 shows a SAP workflow completed at a team’s top levelby the IC. The SAP problem will be discussed in Section3.

SAP is the key task of ICs in order to coordinate opera-tional units during disaster emergency response manage-ment. As a result, it is necessary to develop approachesthat are appropriate for SAP. Several good studies havebeen carried out in the area of multi-agent coordination,and each has been undertaken under some requirements,a problem definition and a problem setting. Several novelapproaches most of them based on multi-agent systemshave been developed to coordinate disaster/crisis emer-gency operations [1], [36], [28], [11], [18], [7], [2], [34],[22], [15] that they provide proper solutions for specificproblems. They unfortunately do not represent appropri-ate solutions for the SAP problem, which are provided inthis paper.

According to SAP, the limitations and constraints iden-tified in related works can be classified into the followingfour categories:

1 Automated planning systems vs. human-machinecollaboration. Automated planning systems do notallow human planners to be involved in SAP. Thesesystems do not incorporate human intuition and do

2 Journal of Disaster Research Vol.0 No.0, 200x

Data Model for Strategic Action Planning and Scheduling Problems in DisasterResponse Teams

not collaborate with humans for SAP. Their main ob-stacle is scale, as it is currently unfeasible for fullyautomated systems to effectively reason about allthe possibilities that might arise during the execu-tion of tasks in a complex environment [21]. Mixed-initiative planning systems are those where humansand machines collaborate in the development andmanagement of plans, with each contributing itsstrongest capabilities [4]. In general, they can oftengenerate better solutions for complex problems.

2 Tactical vs. strategic decisions. Tactical decisions(action plans and schedules) are related to the lowerlevel of the hierarchy and exactly specify the microactions of agents. However, it is impossible for ICsto fully specify these types of decisions for agents.

3 Micro vs. macro task information. These systemsuse micro task information to create a global view ofthe SAP problem when the top level does not haveaccess to micro task information. Operations centersgather information and data from different resourcesand integrate them to create a global picture of theenvironment. Thus, ICs have inaccessible, global,and uncertain information of the state of the entiretask environment, but agents have direct, complete,and accurate information about the state of their localenvironment.

4 Non-geographic vs. geospatial information. Somerelated works do not integrate geographic informa-tion systems (GIS) and neglect the importance of ge-ographic information in SAP. Because the SAP prob-lem has a geospatial aspect, it requires GIS, whichprovides ICs with tools to analyze, visualize, andmanage geographic and location-based information[16], [11].

With regard to the limitations addressed in previousworks, approaches (intelligent software systems) appro-priate to SAP must be proposed, developed, and applied.An ideal system collaborates with an IC to make betterstrategic decisions with regard to SAP problem analysis.The first critical phase to achieve this goal is to modelSAP problem data.

The objective of this study is SAP problem data model-ing. It is necessary to model, formulate, and present dataon the SAP problem to support the development of anyappropriate approaches to SAP. A data model is neces-sary to represent a real-world problem in order to designand implement problem-solving algorithms and methods.The creation of the data model is one of the most criticaltasks in the entire system development process [26]. Adata model is a major determinant of system developmentcosts, system flexibility, integration with other systems,and the ability of the system to meet user requirements. Adata model presents elements of a problem, their proper-ties, and the relationships and interactions among these el-ements. Two research questions arise in this paper: whatis the SAP problem, and what is the SAP problem datamodel?

In this paper, we propose a SAP problem data modelthat is designed as a Unified Modeling Language (UML)class diagram consisting of entity types, attributes, and re-lationships associated with SAP problem data modeling.This data model is used for four purposes: 1) to modeland present a real-world problem on a computer, 2) to im-plement a geo-database, 3) to design and develop an in-telligent software agent, called GICoordinator, and 4) toimplement a geographic information system. Five maincharacteristics of our contributions are as follows:

1 The SAP problem data model. It models and formu-lates the SAP problem. Furthermore, this data modelis essential for the successful implementation of theGICoordinator.

2 Location-based temporal macro (LoTeM) task infor-mation. The SAP data model presents and summa-rizes task information for different geographic ob-jects (buildings, city blocks, etc.) and transfers taskinformation related to spatial topology relationshipsbetween layers from one geographic layer to another.A LoTeM task is the accumulation of all tasks (bothenabled and disenabled tasks) of the same type thatare spatially contained within the geographic objectof the macro task at a specific time.

3 Human high-level strategy. The SAP problem datamodel formulates and encodes human intuition ashuman high-level strategy for SAP. It enables humanplanners to express and specify their intuition for theintelligent assistant system to make strategic actionplans and schedules in a collaborative approach.

4 Strategic action plan. This data model formulates astrategic action plan and integrates with other enti-ties. The execution of the strategy, i.e., optimal as-signments/allocations of agents to threads, etc., re-sults in the strategic plan that presented by the datamodel.

5 Strategic action schedule. The SAP data model in-tegrates and presents the temporal assignments ofagents to LoTeM tasks. An instance of a strategicaction schedule determines: 1) the location of the as-signed macro task, 2) the type of macro task, 3) thestart time, 4) the finish time, 5) the amount of com-pleted tasks, and 6) the set of agents allocated to thisLoTeM task.

2. Review of Related Works

2.1. Comparison CriteriaDifferent data models have been developed to address

different problems. Each aims to address a number ofcharacteristics and aspects required for an approach tosolve a specific problem. It is obvious that different prob-lems require different types of data modeling according totheir demands and requirements. In fact, the complexity

Journal of Disaster Research Vol.0 No.0, 200x 3

Nourjou, R., et al.

Table 1. : Features of works related to SAP data model-ing.

FeaturesRelated works 1 2 3 4 5 6[28] B A B B B -[36] A A A B - B[18] A A B B B B[2] B B B B B B[22] A B B A A B[11] A A A C - -[34] A B B A - -

Features Description:1: Decision-Maker Level. A- Top (IC), B- Down2: Information. A- Geographic, B- Non-Geographic3: Tasks Scale. A- Macro, B- Micro4: Approach. A- Human-Machine Collaboration, B-Automated, C- Human5: Plan Type. A- Strategic, B- Tactical6: Schedule Type. A- Strategic, B- Tactical

and efficiency of a data model depends on the character-istics/requirements of a problem. For example, the num-ber of teams, the hierarchical level, recourse management,the role of field units in planning and scheduling, and thecomplexity of task structure, among other factors, affectthe formulation and presentation of a problem.

This paper proposes SAP data models to formulate andmodel the SAP problem. The levels of completeness ofthese models are compared according to the following sixcharacteristics: 1) geographic information, 2) macro taskenvironment, 3) human-machine collaboration, 4) strate-gic action planning, 5) strategic action scheduling, and 6)the IC (the top level of the team).

The question is whether there is a previously devel-oped data model that can completely model the problemat hand. A perfect data model should consider six maincharacteristics: 1) the IC is the decision maker at the topof the team; 2) the geographic and location-based infor-mation should be modeled; 3) tasks have spatial, macro,and temporal characteristics; 4) human intuition shouldbe included/involved in problem-solving techniques; 5)plans include strategic/macro decisions, and 6) schedulesinclude strategic/macro decisions.

This comparison will indicate the originality of theSAP data model.

2.2. ReviewGood research has been conducted in the area to pro-

vide appropriate solutions to specific problems. This sec-tion reviews and compares a few related works and theirdeficiencies and limitations with regard to SAP data mod-eling. Table 1 summarizes the features of these works inrelation to SAP problem data modeling.

A simple conceptual model of spatial coordination in aUSAR team was designed and used in the development ofspatially distributed intelligent assistant agents and geo-simulations of USAR scenarios [Error: Reference sourcenot found28]. In this data model, a damaged building con-tains a group of search and rescue tasks such that each

search task can release or discover a rescue task. Eachtask should be assigned to one proper field unit. This datamodel focuses on distributed coordination among agentsby allocating and distributing micro tasks.

A conceptual model for human group task allocation inrescue management was designed by [36]. It was used toimplement a greedy spatio-temporal task allocation algo-rithm in a GIS environment. This model contains spa-tial and non-spatial layers (parcels, networks, damagepoints, tasks, field personnel, task-list, distributed tasks,and cost). This data model is applied using an automatedinformation system that assigns segment-based tasks tofield units. Although this approach contains macro tasks,it does not consider interdependencies among tasks, andeach macro task can be assigned to only one unit.

The goal of the RoboCupRescue simulation project isto simulate rescue teams acting in large urban disasters[18]. Rescue agents try to minimize damage caused byearthquakes, such as civilians buried under rubble, burn-ing buildings, and blocked roads. In this project, there arethree different teams and six types of agents: 1) a fire sta-tion with several fire brigades, 2) a police station with sev-eral police forces, and 3) an ambulance center with sev-eral ambulance teams. Although this approach containsan IC for each team, the decisions that are made are tacti-cal/micro and the presented tasks are micro. Humans arenot involved in the planning loop, and each field agent hasa specific capability.

C-TAEMS (coordinated task analysis, environmentmodeling, and simulation) [2], which is an adaptationof TAEMS [7], formulates and models distributed multi-agent coordination problems. It was used to develop theCOORDINATORS program through different approaches[35], [20]. An instance of a C-TAEMS problem contains aset of agents and a hierarchically decomposed task struc-ture. Each agent has a set of activities, known as methods,that he or she can perform. The nodes in the graph are ei-ther complex tasks, each of which is composed of a groupof tasks and/or methods, or executable methods as leafnodes that are executed once by a specified agent. Eachnode may have temporal constraints at the earliest starttime and the deadline as well as non-local effect depen-dencies that represent hard (enables and disenables) andsoft (facilitates and hinders) relationships. The methodshave probabilistic outcomes in terms of duration, quality,and cost.

STaC is an approach that adapts C-TAEMS to involvehuman intuition in multi-agent coordination [22]. It in-tegrates human strategy guidance with C-TAEMS to en-able human-agent collaboration to improve the efficiencyof the COORDINATOR project. Unfortunately, this ap-proach formulates location-based and micro tasks. Thus,task assignments made through this approach do not havethe macro feature.

Some research has used and applied GIS for disasteremergency management. GIS are used to integrate, ana-lyze, and visualize geospatial data. Emergency manage-ment uses geo-information technologies in all five phasesof the emergency management process, i.e., planning,

4 Journal of Disaster Research Vol.0 No.0, 200x

Data Model for Strategic Action Planning and Scheduling Problems in DisasterResponse Teams

Fig. 3. : The SAP problem.

mitigation, preparedness, response, and recovery [9]. Forexample, three collaborative geo-information platformswere developed to 1) allow for synchronous and asyn-chronous collaboration between decision makers, 2) sup-port GIS use by mobile emergency management teams,and 3) provide open standards-based web portal technolo-gies [11]. Although GIS is used by ICs, it is not suffi-cient for SAP. It must be integrated with other systems forstrategic action planning and scheduling.

DEFACTO (demonstrating effective flexible agent co-ordination of teams through omnipresence) incorporatesstate-of-the-art artificial intelligence, three-dimensional(3D) visualization and human-interaction reasoning into aunique high-fidelity system to train ICs [34]. Its main fea-ture is a focus on adjustable autonomy, which refers to anagent’s ability to dynamically change its own autonomy,possibly to transfer control over a decision to a humanor other agent. DEFACTO comprises various transfer-of-control strategies. Unfortunately, this approach is not re-lated to SAP.

The incident command system is a disaster manage-ment tool based on a series of rational bureaucratic prin-ciples for disaster response. It provides a set of rules andpractices to guide the actions of the various organizationsresponding to disasters and creates the necessary divisionof labor and coordination mechanisms among them [3].The basic system objectives and plans are established ator near the top of the hierarchy and used as the basisfor decisions and behaviors at lower levels. The IC as-sesses the situation, identifies contingencies, develops ob-jectives, ascertains resource needs and generates an ini-tial action plan [1]. Unfortunately, although the FederalEmergency Management Agency (FEMA) provides a setof useful guidelines about practices [9], it does not makeexplicit the design requirements for information systemsto create incident action plans.

3. Analyzing the SAP Problem

The SAP problem is composed of a number of differ-ent dimensions. Fig. 3 shows the conceptual model ofthe components that form the SAP problem. This sectionanalyzes and describes these dimensions.

3.1. The Problem DomainUSAR is the problem domain chosen in this paper be-

cause of its major role in earthquake disaster response.The global goal of USAR operations is to rescue the great-est number of people trapped under debris from damagedbuildings in the shortest amount of time.

USAR tasks involve a sequence of dependent tasks: (1)conduct reconnaissance and assessment by collecting in-formation on the extent of damage; (2) search and locatevictims trapped in collapsed structures; (3) extract andrescue trapped victims, and (4) transport/dispatch injuredsurvivors to hospitals or refuges. Rescue tasks are fur-ther classified into three categories: light, medium, andheavy rescue. Further, there are other supporting tasks,such as road-clearing and fire-fighting tasks, that facili-tate and support USAR tasks.

To save a person, it is necessary to define the set ofUSAR tasks. Sometimes, several people are trapped dueto a destroyed building. USAR tasks are location-basedentities that are distributed in an extensive geographicalarea.

Accomplishing each task requires the consideration ofduration and the requirement of a specific capability orseveral synchronous capabilities. Capability requirementsdetermine which agents are allowed to complete whichtasks.

In this domain, coordination involves managing taskflow. The ”enabling” dependency between tasks speci-fies that when a task is completed, another task can beperformed. In other words, when a disenabled task is en-abled depends on the completion of the task that causes itto be enabled. For example, the rescue of a trapped personis dependent on the search for that person.

3.2. Disaster Response TeamsA variety of responsible or supporting teams are in-

volved in disaster emergency response and crisis manage-ment, such as search & rescue robots, autonomous un-manned vehicles, Red Crescent Society rapid responseteams, INSARAG teams [13], volunteer teams, fire-fighting teams, medical services, or road-clearing bull-dozers. Fig. 1 shows the organizational structure of ateam. A team is essentially composed of an IC at the toplevel of the team and several agents (field units) at thelower level. They cooperate with each other to achievethe team’s objectives.

3.2.1. Field Units (Agents)A team’s operational/field units may be human person-

nel, robots, or human-robot teams that act like multia-gent systems. They are considered geospatial, mobile,and semiautonomous agents that are distributed in a ge-ographic area. Their main role is to complete tasks usingtheir capabilities in the operational area.

Agents may be capable of heterogeneous actions thatallow them to engage in tasks for which they can pro-vide the required capabilities. Each action provides a

Journal of Disaster Research Vol.0 No.0, 200x 5

Nourjou, R., et al.

set of capabilities. Agents execute their actions at dif-ferent speeds. They are categorized into several types ofagents according to their capabilities and performance,such as (1) ”reconnaissance”, (2) ”canine search”, (3)”electronic search”, (4) ”light rescue”, (5) ”medium res-cue”, (6) ”heavy rescue” and (7) ”volunteer”.

Agents are required to coordinate their actions for threereasons. The first is to manage interdependencies amongthe actions of agents because of dependency relationshipsbetween tasks. The second is to manage redundant ac-tions for the completion of joint tasks. The third is tomanage agents as shared resources that are assigned totime-consuming tasks. Efficient coordination minimizesthe operation time for all tasks.

3.2.2. Incident Commander (IC)An IC is a human planner located at the top of the team

hierarchy. His or her main role is to plan and schedulethe actions of agents to coordinate disaster response man-agement. Fig. 2 is an activity diagram of an IC in a teamaccording to SAP.

The IC has global, and uncertain information about thestate of the environment. His/her perception/observationof the disaster situation is global, in contrast to agents’perceptions of their local environments.

3.3. Geographic InformationThe problem domain is related to a geographical en-

vironment that includes different geographic layers, suchas buildings, city blocks, and road networks. Each layeris composed of geographic objects. These layers providebase layers to which task information, agents, strategicaction plans, and schedule information are geo-located.

There are topological relationships between spatial ob-jects in geographic layers [8]. For example, each buildingis contained within a specific city block and adjacent to acertain road segment.

3.4. Location-based Temporal Macro Tasks(LoTeM Tasks)

Macro task information forms the ICs’ globalview/perception of the task environment. A macro taskis the accumulation of all tasks (enabled and disenabled)that are of the same task type and are spatially containedwithin a specific geographic object at a specific time.Topological relationships between geographic objects en-able the ICs to extract and present macro task informationfor different geographic layers.

A macro task indicates the total number of capabilitiesrequired to complete a set of homogenous tasks. It pro-vides an estimation of the number of required teams andthe duration of the operation. Because of the temporal en-vironment, the number of enabled and disenabled macrotasks varies over time. This leads to a series of discretetemporal macro tasks.

Four sources generate task information: 1) estimationand forecasting, 2) direct observation and gathering of

Fig. 4. : Task flow diagram of a geographic object’sLoTeM tasks at a specific time.

task data, 3) information sharing by other teams, and 4)fusion and integration of information.

Macro tasks have an ”enabling” dependency in theUSAR problem domain. Fig. 4 shows a task flow of sixLoTeM tasks associated with a geographic object. For ex-ample, all reconnaissance tasks (enabled and disenabled)can reveal search tasks that are disenabled in the same lo-cation. .

3.5. Strategic Action Planning

The goal of SAP is to coordinate agents in a teamthrough a strategic action plan formed by the team’s ICusing a global view.

The SAP concept proposed in this study is similar tothe incident action planning process [9], [12]. An inci-dent action plan (IAP) is created by an incident commandsystem in five phases: (1) understand the situation; (2) es-tablish incident/response objectives (priorities, objectives,strategies, tactics, tasks, and work assignments); (3) de-velop the plan; (4) prepare and disseminate the plan; (5)execute, evaluate, and revise the plan.

SAP assigns/allocates a subset of agents to a subsetof LoTeM tasks. SAP includes two phases: (1) specifyhuman high-level strategy guidance and (2) execute andadapt the specified strategy [22].

A strategic action plan constrains and limits the behav-iors and actions of agents. It is obvious that a strategicaction plan strongly influences team performance. There-fore, the IC plays a major role in defining a good strat-egy, intelligently executing strategies, monitoring the sit-uation, and refining and adjusting strategies to adapt to thecrisis situation.

6 Journal of Disaster Research Vol.0 No.0, 200x

Data Model for Strategic Action Planning and Scheduling Problems in DisasterResponse Teams

3.5.1. High-level StrategyHigh-level strategy guidance enables an IC, as a hu-

man planner, to express and encode his or her intuition forSAP. A strategy is composed of a set of parallel threadsthat are prioritized from high to low, according to theirimportance. Furthermore, threads can operate in parallelduring execution, based on agent availability. A threadis composed of a unique ranking, a sub-team (a subset ofagents), sub-objectives (a subset of task types), and sub-locations (a subset of geographic objects). Agents mayengage in several threads because of limited resources.

A strategy decomposes a difficult and complex prob-lem into simpler problems that can be solved by tradi-tional artificial intelligence techniques and automated sys-tems. In other words, high-level strategy guidance parti-tions and decomposes the entire problem space into a setof small problems under human supervision. The decom-position of a coordination problem into some threads gen-erates two new types of interdependency among threads:1) agents shared among threads and 2) ”enabling” de-pendencies that are formed among the LoTeM tasks ofthreads.

3.5.2. Strategic Action PlanCreating a strategic action plan is a problem of appro-

priately assigning agents to threads at specific times. Be-cause agents are shared among threads, an agent shouldbe allocated to only one thread at a time. As a result, it isnecessary for the IC to dynamically execute the specifiedstrategy and adapt the established strategic plan to newdisaster situations and agent availability by optimally as-signing agents to threads or intelligently releasing agentsfrom their thread into the next thread.

The assignment of a specific thread to a specific agentforces that agent to adapt his/her behaviors and actionswith regard to the thread definition. The establishedstrategic plan is sent from the operation center to eachagent, so that these agents can make their own tacticalplans/decisions for distributed multi-agent execution toaccomplish tasks in the operational area.

3.6. Macro Action/Task SchedulingStrategic action scheduling estimates the makespan and

assigns agents to LoTeM tasks according to the estab-lished strategic action plan. Strategic action schedulingdoes not schedule all the detailed actions required foragents to accomplish tasks at the tactical level.

A strategic action schedule contains the following as-signment information: (1) the location (geographic ob-ject) of the LoTeM task; (2) the type of macro task; (3) thestart time; (4) the finish time; (5) the number of tasks thatwill be completed in this duration; (6) the set of agents as-signed to this schedule; and (7) the number of dependenttasks that will be revealed at this location. The importantpoint is that strategic action scheduling can be applied todifferent geographic layers.

On account of the geospatial, temporal, and macro as-pects of tasks, strategic action scheduling takes eight rules

into account: (1) more than one agent can be assigned toa LoTeM task, and assigned agents form a coalition to co-operatively execute this decision; (2) assignments are dy-namic, which means that over time, new agents can join acoalition assigned to the LoTeM task; (3) agents assignedto a LoTeM task are maintained at that task until all taskshave been accomplished; (4) scheduling should follow theestablished strategic action plan; (5) agents need to con-sider the travel time to reach the location of a LoTeM taskthrough the road network; (6) heterogeneous agents pro-vide the different capabilities required for heterogeneoustasks; (7) a coalition of many professional agents can ac-complish a LoTeM task faster than other coalitions; (8)LoTeM tasks may have dynamic numbers of enabled anddisenabled tasks because some agents may complete sometasks while other agents may release new tasks.

4. Data Modeling of the SAP Problem

4.1. Data Modeling BackgroundSoftware engineering uses the data model in two related

senses: 1) describing the objects represented by a com-puter system together with their properties and relation-ships and 2) collecting concepts and rules used to definedata models. The main aim of data models is to supportthe development of information systems by providing thedefinition and format of data. Data models are catego-rized into four types: 1) database model, 2) data structurediagram, 3) entity-relationship model, 4) geographic datamodel, 5) generic data model, and 6) semantic data model.

A data structure diagram is a diagram of the conceptualdata model that documents the entities and their relation-ships, as well as the constraints related to them. There areseveral data modeling languages (and data modeling di-agrams), such as UML, which is a standardized general-purpose modeling language in software engineering. Itincludes a set of graphical notation techniques to createvisual models of object-oriented software-intensive sys-tems.

4.2. The SAP Data ModelOur contribution in this paper is the SAP data model.

Data modeling of the SAP problem, which was analyzedin the previous section, results in a SAP data model. Fig.5 and Fig. 6 show the UML class diagram of this datamodel. Classes and relationships are presented in Fig. 5,and the attributes of these classes are shown in Fig. 6.

4.3. Description of the SAP Data ModelTo gain a better understanding of the SAP data model,

detailed information is provided in the following subsec-tions. It helps us gain an insight into classes, relationshipsamong classes, and the types of information provided bya certain class. It provides the fundamental knowledgewe need to design and implement problem-solving algo-rithms. Future works such as [29], [30] need to know, for

Journal of Disaster Research Vol.0 No.0, 200x 7

Nourjou, R., et al.

Fig. 5. : SAP data model based on a UML class diagram: classes and relationships.

.

example, how to obtain and extract the required data froma data model, how to design algorithms, and how to dealwith a database that supports SAP information.

We classify the designed classes into eight groups tomodel, formulate, and present the eight dimensions of theSAP problem as shown in Table 2.

4.3.1. Urban Search and Rescue DomainThe problem domain is modeled using the ”taskType”,

”capabilityType” and ”taskDependency” classes. In-stances of these classes are initially defined by humanusers.

The ”capabilityType” class is used to define the set ofcapabilities required by the problem domain. Capabilitiesare defined to determine 1) which capabilities are required

by tasks and 2) which subset of capabilities is providedby each agent. The ”capabilityType” class connects the”taskType” class with the ”agentCap” class. It thereforeenables the system to identify particular agents that areeligible to take part in specific tasks.

The ”taskType” class defines all types of tasks in theproblem domain. Real tasks are initialized using thisclass. An instance of a type of task requires a collectionof capabilities (List <string > CapTypeIds) to be accom-plished. A specific type of task may require either onlyone definite capability or several synchronous (simultane-ous) capabilities in order for a unit of this type of task tobe accomplished in a certain amount of time (the ”dura-tion” attribute). The calculation of the duration of a typeof task includes uncertain information with a probability

8 Journal of Disaster Research Vol.0 No.0, 200x

Data Model for Strategic Action Planning and Scheduling Problems in DisasterResponse Teams

Fig. 6. : SAP data model based on a UML class diagram: class attributes.

Journal of Disaster Research Vol.0 No.0, 200x 9

Nourjou, R., et al.

Table 2. : Grouping the classes of the SAP data model with regard to the components that constitute the SAP problem.

Dimensions of the SAP Problem Classes of the SAP Data Model

1- Problem DomaincapabilityTypetaskTypetaskDependency

2- Disaster Response TeamagentCapagentCapagentteam

3- Geospatial Information

buildingcityBlocksegmentzoneshortestPath

4- Geospatial-Temporal Macro Tasks macroTasktemporalMacroTask

5- Human High-level Strategy Guidance threadstrategy

6- Strategic Action Plan threadAssignment

7- Strategic Action Schedule temporalMacroTaskAssignmentlegalAssignment

8- States of the World stateNode

”p”.The ”taskDependency” class defines dependency rela-

tionships among task types. It abstractly formulates allinterdependencies among LoTeM tasks that are containedwithin a common geo-object. The ”enabling” and ”fa-cilitating” dependencies between tasks are considered incoordinating agents.

4.3.2. Team

The aim of this dimension is to model the structure ofa disaster response team using four classes: ”agentCap”,”agentType”, ”agent”, and ”team”. A team IC initiallyspecifies the structure of the team.

The ”agentCap” class formulates all types of capabil-ities and actions that agents within the team may pos-sess in the problem domain. An instance of the ”agent-Cap” class indicates a specific action to state how many(the ”amount” attribute) of a certain subset of capabilities(List <string> CapTypeIds) can be completed at a certainspeed.

The ”agentType” class categorizes agents into differ-ent agent types according to their capabilities. A typeof agent may have one or several types of actions (List<agentCap> AgentCaps). It also indicates that an agentcan select a type of action at a time to carry out all thecapabilities provided by this action.

The goal of the ”agent” class is to represent all agentsin a team. The type of an agent specifies its capabilitydomain. Because of uncertainty in data, the approximateand real-time locations (”realtimeLocationId”) of agentsare defined by adjacent segments (street segments).

An instance of the ”team” class presents a team. Thelower level of the team is composed of a number of agents(List <agent > Agents team). The IC should specify theteam’s global objective, which includes a subset of goalsin a part of the disaster-affected area. The ”zone” and”taskType” classes are used to define an objective.

4.3.3. Geospatial InformationThe ”building”, ”cityBlock”, ”segment”, ”zone” and

”shortestPath” classes organize some important geo-graphic layers. The primary role of GIS is to provideefficient tools for the incident command post to imple-ment, develop, share, and manage a geospatial databasethat contains geographic information and location-baseddata.

Instances of these classes are geospatial objects dis-tributed in the area. These classes enable the comple-tion of six goals: 1) geo-visualizing geographic informa-tion on GIS thematic maps, 2) presenting and managingnon-spatial information associated with geographic infor-mation, 3) presenting spatial relationships, 4) composinga set of macro tasks for each geographic object, 5) inte-grating task information from one layer to another, and 6)viewing and perceiving task information in different geo-graphic scales. Each geographic object includes a set ofmacro tasks (List <macroTask> ).

Each instance of the ”shortestPath” class indicates theshortest distance between the centers of two segments ina road network at a specific time. GIS calculates theseinstances for the road network. The blockage states ofroads change over time because some blocked roads arecleared by road-clearing teams (bulldozers).

4.3.4. Location-based Temporal Macro TasksThe ”macroTask” and ”temporalMacroTask” classes

model and formulate LoTeM tasks. A directed acyclicgraph (DAG) is applied to the presentation of LoTeMtasks. A set of tasks with dependencies can be modeledby a DAG, which is a directed graph with no directed cy-cles [19]. A task represents a vertex in the DAG; a di-rected edge (u,v) represents the dependency between twotasks and implies that task u must be completed beforetask v. Other complementary information, such as cost,duration, and deadline, can be defined for each vertex.

A macro task has a definite task type and is composedof a set of temporal macro tasks (List <temporalMacro-

10 Journal of Disaster Research Vol.0 No.0, 200x

Data Model for Strategic Action Planning and Scheduling Problems in DisasterResponse Teams

Task> TemporalMacroTasks) that specifies a series ofquantitative information about the accumulated tasks lo-cated within a definite geographic object (the ”geoObjec-tId” attribute).

An instance of the ”temporalMacroTask” class spec-ifies quantitative information about the macro task inquestion. It defines how many enabled (the ”en-abledAmount” attribute) and disenabled tasks (the ”dis-enabledAmount” attribute) of a specific type are observedor estimated at a specific time (the ”updatedTimeG0”attribute). Any changes in the quantitative information(”enabledAmount” or ”disenabledAmount”) lead to a newinstance of ”temporalMacroTask”. An instance of thisclass may contain one instance of the ”temporalMacro-TaskAssignment” which is calculated by strategic actionscheduling algorithms.

4.3.5. High-level Human StrategyThe ”strategy” and ”thread” classes express and encode

high-level human strategy guidance. These classes enablethe IC to specify a high-level strategy used in strategicaction planning.

A strategy is composed of a collection of threads (List<thread> Threads) that encode and formulate human in-tuition. A strategy partitions a complex planning probleminto interdependent, parallel and prioritized threads.

A thread defines a sub-problem. It essentially com-prises four attributes: 1) the ”threadId” attribute, whichis a unique ranking id that identifies its priority (impor-tance) relative to other threads; 2) the ”AgentIds defined”attribute, which represents a subset of agents permitted toact in the thread domain; 3) the ”TaskTypeIds defined”attribute, which represents a subset of task types that de-fine the domain of a goal; and 4) the ”ZoneIds defined”attribute, which represents a subset of zones that define ageographic scope for the thread. The relationships of the”thread” class with the ”agent”, ”taskType” and ”zone”classes are necessary to model this dimension.

4.3.6. Strategic Action PlanThe ”threadAssignment” class formulates a strategic

action plan. The assignment (allocation) of agents tothreads results in a strategic action plan. This process iscompleted either by the related algorithm or by humanplanners.

A strategic action plan is enclosed by the ”stateNode”class, which enables the system to extract informationabout the start or finish times of the established strategicaction plan.

For each thread, there is an instance of the ”threadAs-signment” class at a specific time. This class is associatedwith a subset of permissible agents (List <string> Agen-tIds assigned) assigned to this thread.

It is important to take the following three facts into ac-count: 1) an agent can only be associated with one threadat a specific time; 2) thread assignment does not involve ascheduling problem; and 3) agents assigned to a particu-lar thread are responsible for completing tasks defined bytheir thread.

4.3.7. Strategic Action Schedule

The ”temporalMacroTaskAssignment” and ”legalAs-signment” classes model a strategic action schedule. In-stances of these classes are calculated by strategic actionscheduling algorithms.

An entity of the ”temporalMacroTask” class can com-prise an entity of the ”temporalMacroTaskAssignment”class. This class consists of four properties: 1) the ”start-Time” attribute, which is the operation’s start time; 2)the ”finishTime” attribute, which is the operation’s finishtime; 3) the ”doneAmount” attribute, which represents theestimated number of tasks that need to be completed; and4) the ”LegalAssignments assigned” attribute, which is asubset of legal assignments.

The ”legalAssignment” class is associated with the”temporalMacroTaskAssignment” and ”agent” classes. Alegal assignment states the assignment of an agent to aLoTeM task. This class includes other detailed informa-tion, such as the maximum capability that an assignedagent can provide for the LoTeM, or the time at whichan assigned agent can start performing the LoTeM tasks.

4.3.8. State of the World

The ”stateNode” class is used to model and simulatethe state of the environment. This class is used by searchalgorithms to find the optimal strategic action plan.

The class includes dynamic elements of the SAP prob-lem. A state node has six properties: 1) start time, 2)finish time, 3) the team, 4) the strategic action plan thatis established and valid for its duration, 5) segments withtheir own macro tasks for strategic action scheduling, and6) the parent node id.

5. Evaluation of the SAP Data Model

5.1. Objective of Evaluation

It is necessary to evaluate the quality of the SAP prob-lem data model, especially from a completeness perspec-tive. Completeness refers to whether the data model con-tains all the information necessary to support the requiredfunctionality of the system [26]. We consider several is-sues, including 1) whether the data model is applicable;2) how to use the SAP; 3) how data are produced, bywhom (human, algorithms, or other information systems),and when; 4) how to present/visualize the data; 5) if thedata model satisfies the specified requirement; and 6) howa system or problem-solving algorithm can be developedusing this model.

This section aims to show that the SAP data model ispractical, useful, and efficient in developing approaches tosolving SAP problems. The evaluation consists of severalsteps, including proposing, developing, and applying theGICoordinator [29] to a simulated scenario. This sectionis dedicated to describing these steps.

Journal of Disaster Research Vol.0 No.0, 200x 11

Nourjou, R., et al.

5.2. GICoordinator: A GIS-based Intelligent Coor-dinator

As a GIS-based intelligent assistant system, the GI-Coordinator helps an IC coordinate a team of field unitsin the disaster emergency response domain, especially inUSAR operations [29]. This spatial intelligent systemsupports the IC with intelligent algorithms for action plan-ning and task scheduling related to the centralized coor-dination of a team in a dynamic and spatial environment[30], [32]. Further, it applies a spatial database to geo-graphic and location-based information management anduses GIS functions to support the development of thesespatial intelligent algorithms. An IC has a computer thatruns an instance of the GICoordinator. A society of dis-tributed GICoordinators represents distributed teams [31].A simple version of this system has been developed forfield units [28].

The development of the proposed approach includesthe development of the GICoordinator, the developmentof a spatial database, the implementation of a base GIS,and the integration of the GIS with the GICoordinator.The SAP problem data model is applied using an object-oriented programming language to develop the GICoordi-nator. The model is implemented through the MicrosoftSQL server to develop a base spatial database in orderto achieve four objectives: 1) organizing data (geographicand non-geographic information), 2) implementing a baseGIS, 3) integrating the GIS with the GICoordinator, and4) supporting human-GICoordinator interaction. A baseGIS is connected to the database to provide efficient GIStools for the IC. The integration of the GIS with the GI-Coordinator is accomplished through this database, whichis shared by both.

5.3. Simulation of a SAP ProblemThe simulation method enables us to apply GICoor-

dinator to a simulated SAP in a USAR scenario. Thesimulation consists of the following steps: 1) preparinggeospatial information, 2) defining the domain problem,3) initiating a team, and 4) estimating LoTeM tasks us-ing some loss estimation models [24], [25]. Related dataare defined or initialized by the human planner and areentered into the spatial database.

A part of District 17 in the city of Tehran, with an areaof 0.62 square kilometers, comprising 141 city blocks and4,260 buildings, is chosen as the case study. The geo-graphic layers of this area, which are prepared in GIS, areexported to the spatial database. The shortest distancesbetween the centers of road segments and topology re-lationships among geographic information are extractedusing GIS capabilities.

The next step is to define information for the USARdomain, which is composed of five types of tasks. Thematrix shown in Table 3 represents the task types and theircapability requirements.

A flexible team of 12 agents is initiated for USAR. Ta-ble 4 shows the agents and their capabilities. It was as-sumed that all agents are free and located in the incident

Table 3. : Task types of the problem domain.

Capability RequirementsTask-Types ∆ t C0 C1 C2 C3 C4 C5T0 10 1 0 0 0 0 0T1 20 0 1 0 0 0 0T2 30 0 0 1 0 0 0T3 70 0 0 0 1 0 0T4 110 0 0 0 0 1 0T5 1 0 0 0 0 0 1

Capabilities Description:C0: C0-ReconnaissanceC1: C1-SearchC2: C2-SlightRescueC3: C3-MediumRescueC4: C4-HeavyRescueC5: C5-TransportByVehicle

Task Types Description:T0: T0-ReconnaissanceT1: T1-SearchT2: T2-SlightRescueT3: T3-MediumRescueT4: T4-HeavyRescueT5: T5-MedicalTransportation

Fig. 7. : A thematic map of the distribution of thesegment-based temporal macro tasks.

command post in this snapshot. The location of the agentsis displayed in Fig. 7.

The final step is to simulate the macro tasks that aredistributed in the area and are summarized and aggregatedbased on street segments. This is done in two steps: 1) es-timating LoTeM tasks geo-located to buildings and 2) ex-tracting LoTeM task information for segments using thesedata. First, GICoordinators execute a simple loss estima-tion algorithm to generate LoTeM task information forbuildings. Second, an integration information algorithmis executed by GICoordinator to extract the LoTeM taskinformation associated with the segment data by summa-rizing and aggregating the LoTeM task information forbuildings. The simulated operational area is found to in-clude 1,144 damaged buildings containing 5,401 macrotasks, 53 roads containing 297 macro tasks, and four op-erational zones with 24 macro tasks. Fig. 7 shows a map

12 Journal of Disaster Research Vol.0 No.0, 200x

Data Model for Strategic Action Planning and Scheduling Problems in DisasterResponse Teams

Table 4. : (a). Agent matrix: agent types and their features; (b). 12 assigned agents for the team

(a)

CapabilitiesAgent-Types speed C0 C1 C2 C3 C4 C5

A0-Reconnaissance 4 1 0 0 0 0 01 0 0 0 0 0 1

A1-CanineSearch 1 1 0 0 0 0 03 0 2 0 0 0 0

A2-ElectronicSearch 1 1 0 0 0 0 02 0 1 0 0 0 0

A3-SlightRescue1 1 0 0 0 0 01 0 1 0 0 0 04 0 0 1 0 0 0

A4-MediumRescue1 0 0 1 0 0 02 0 0 0 1 0 01 0 1 0 1 0 0

A5-HeavyRescue 1 0 0 0 1 0 03 0 0 0 0 1 0

A6-Ambulance 1 0 0 0 0 0 4

A7-Volunteer 1 0 0 0 0 0 11 0 0 1 0 0 0

(b)

Agent Agent-Typeag0A0 A0ag1A0 A0ag2A1 A1ag3A1 A1ag4A2 A2ag5A2 A2ag6A3 A3ag7A3 A3ag8A4 A4ag9A4 A4

ag10A5 A5ag11A5 A5

Fig. 8. : A GIS map of the macro tasks for segment se279.

of the simulated SAP problem.As an example, Fig. 8 shows a map that highlights a

segment and several buildings adjacent to it. A total of210 macro tasks estimated/observed for 43 buildings areintegrated to extract at most six macro tasks for segments316 at time zero. The ”T3-MediumRescue” macro taskshows that four medium rescue tasks (to rescue four per-sons who have been located by search teams) are releasedand are ready to be completed by appropriate teams alongthis segment, but 14 tasks have not been enabled and areestimated to be released/discovered by ”Search” opera-tions. It is estimated that all 74 of the search tasks (17enabled and 57 disenabled) have to be accomplished inorder to release (enable) the 35 disenabled rescue tasks.

Fig. 9 represents an algorithm to extract the LoTeMtask information for a definite segment by integrating theLoTeM task information for buildings near this segment.

Fig. 9. : Algorithm for integrating macro task informationfor buildings in order to extract new macro task informa-tion for a road segment.

In the real world, city blocks have spatial topological re-lationships with zone objects.

5.4. Visualizing the Simulated SAP ProblemThe capabilities and analytical tools of the GIS en-

able the IC to visualize and analyze SAP problem infor-mation in order to obtain better awareness/perception ofthe global situation. Furthermore, the GICoordinator pro-

Journal of Disaster Research Vol.0 No.0, 200x 13

Nourjou, R., et al.

Fig. 10. : Using GIS for the 3D visualization of agents,buildings, street networks (segments), city blocks, andzone and geographic layers that compose region 17 ofTehran.

vides some data integration and information fusion algo-rithms/tools that can be applied to the database.

Fig. 7 and Fig. 10 represent GIS-created thematic mapsof the simulated SAP problem. They consist of the zonelayers, the segment layers, the locations of 12 agents andthe spatial distribution of macro tasks. This map modelsand presents the USAR scenario faced by the IC in coor-dinating the actions of agents in order to accomplish tasksin minimal time.

5.5. Applying GICoordinator to Strategic ActionPlanning and Scheduling

There are two significant benefits to applying GICoor-dinator to strategic action planning problems: 1) human-machine collaboration to create a new strategic actionplan and schedule, and 2) automated updation of the cre-ated strategic action plan. GICoordinator tries to providea solution for the workflow presented in Fig. 2.

5.5.1. High-level Strategy Guidance SpecificationA SAP is realized through a collaboration between the

GICoordinator and the IC. First, the IC specifies a strat-egy after he/she perceives the problem space using theGIS. Strategy information is entered into the GICoordi-nator using the interface provided.

Table 5 shows the human strategy for team coordina-tion. The strategy is composed of four threads that for-mulate and encode human intuition in the coordination ofagents. The first thread states that a team’s primary objec-tive is to engage in reconnaissance operations in two op-erational zones, {zo1, zo2}. To accomplish this objectiveand complete relevant tasks, any subset of the six agents{ag0A0, ag1A0, ag2A1, ag3A1, ag4A2, ag5A2} is al-lowed to be assigned to this objective. The second threadexpresses the secondary objective, which is to carry out allsearch operations contained within the same operational

Table 5. : High-level strategy composed of four threadsspecified by the IC for SAP.

thread Id {zone} {task-type} {agent}

1

zo1 T0-Reconnaissance ag0A0zo2 ag1A1

ag2A1ag3A1ag4A2ag5A2

2

zo1 T1-Search ag2A1zo2 ag3A1

ag4A2ag5A2ag6A3ag7A3

3

zo1 T2-SlightRescue ag6A3zo2 T3-MediumRescue ag7A3

T4-HeavyRescue ag8A4ag9A4ag10A5ag11A5

3

zo3 T0-Reconnaissance ag0A0zo4 T1-Search ag2A1

T2-SlightRescue ag4A2T3-MediumRescue ag6A3T4-HeavyRescue ag8A4

ag10A5

zones. Again, any coalition of the six agents {ag2A1,ag3A1, ag4A2, ag5A2, ag6A3, ag7A3} can be allocatedto this thread. The third thread specifies that three types ofrescue operations should be performed within zones 1 and2. To achieve this objective, any subset of the six agentscan be assigned to this thread. The last thread presentsthe lowest-ranking goal defined for the team by the IC. Itstates that all five types of USAR tasks within zones 3 and4 can be completed by any subset of the six agents. Thefour defined threads partition the SAP problem into fourprioritized, parallel, and dependent smaller problems.

To specify the four threads, the IC takes two impor-tant facts into account: 1) agent availability and 2) en-abled tasks. The agents shared among threads and the taskdependencies among defined threads make these threadscompletely or partially interdependent. For example,agent ag4A2, who has many capabilities, is defined inand shared among the first, second, and fourth threads.The rules permit this agent to be assigned to the firstthread, which subsequently releases this agent to the sec-ond thread as the next, specific, and lower-ranking thread.Consequently, it takes time for agent ag4A2 to becomeavailable to accomplish the objective of the fourth thread.As another example, the second thread is completely de-pendent on the first: reconnaissance operations specifiedby the first thread enable the search operations defined bythe second. Agents assigned to the third thread have towait for agents who can reveal their rescue tasks by ac-complishing the search operations defined by the secondthread.

An interesting point is that the action domain of a spe-cific agent, such as ag10A5, is identified and limited bythreads defined in terms of time, space, and goals. Forexample, the third thread allows an agent to engage inonly three types of rescue operations within zones 1 and2. If this autonomous agent is assigned to the third thread,

14 Journal of Disaster Research Vol.0 No.0, 200x

Data Model for Strategic Action Planning and Scheduling Problems in DisasterResponse Teams

Table 6. : Two temporal strategic actions (allocation ofagents to threads) calculated by the assistant softwareagent.

thread Id Agent Allocation to Threads at Time0 579

1

ag0A0 ag3A1ag1A0 ag4A2ag2A1 ag5A2ag3A1ag4A2ag5A2

2 ag7A3 ag7A3

3 ag9A4 ag9A4ag11A5 ag11A5

4

ag6A3 ag6A3ag8A4 ag8A4

ag10A5 ag10A5ag0A0ag2A1

he/she will have partial autonomy.

5.5.2. Optimal Assignments of Agents to ThreadsThe second step in creating a strategic action plan is

to execute the human-specified strategy by optimally as-signing the 12 free (released) agents to the four threadsaccording to the SAP problem information and the humanstrategy. The quality of thread assignment affects the op-erational time (makespan) of the whole problem. There-fore, important questions arise regarding the assignmentof specific idle agents to specific threads at this time, andabout whether it is prudent for a thread to keep for itselfthe maximum number of available agents and release un-wanted agents to the next thread.

Since this is a difficult decision for humans (ICs), theGICoordinator runs a set of sophisticated search algo-rithms to find the optimal solution to this problem. Itcalculates three types of information: 1) the number oftemporal sets of strategic decisions (the ”threadAssign-ment” class), 2) number of temporal sets of strategicaction schedules (”temporalMacroTaskAssignment” and”legalAssignment”), and 3) overall operation time. Thesedata update the spatial database and are presented to theIC in order for him/her to evaluate and understand the evo-lution of the defined strategy. This functionality of theGICoordinator helps the IC formulate a good strategy byrefining and adjusting his/her own strategy.

Table 6 shows two temporal strategic decisions by op-timal assignments of agents to threads computed by theGICoordinator. The first strategic plan is for the currenttime 0, and states that the GICoordinator has decided toassign {ag0A0, ag1A0, ag2A1, ag3A1, ag4A2, ag5A2}to the first thread, as the maximum possible number ofallocable agents, and to release the remaining agents tothe second thread. However, it calculates that the best de-cision is to retain only agent ag7A3 for this thread andsend the others to the next thread. All available agents areassigned to the last thread.

The search algorithms estimate that the current strategyis valid until time 579, when the second new strategic planshould be implemented. The GICoordinator adapts the

Fig. 11. : Diagram of the temporal assignments of agentsto macro tasks for segment se279 as a strategic actionschedule.

strategic plan to the updated states of the world. The resultis to release agents {ag0A0 , ag1A0} from their threads.

The strategic action plans for agents are extracted fromthe SAP problem data, e.g., the strategic action plan foragent ag2A1 states that this agent be sent first to zones 1and 2 for reconnaissance operations from time 0 to 560,and then be assigned to the fourth thread to perform fivetypes of USAR operations located in zones 3 and 4, fromtime 579 to 596. This plan estimates that following this,the agent will no longer be used by the team for USAR.

5.5.3. Strategic Action SchedulingThe GICoordinator calculates a new strategic action

schedule by assigning GMT tasks to agents. Whenevera new strategic action plan is formulated, the GICoordi-nator runs a set of heuristic algorithms to assign macrosegment tasks to agents considering the simulated SAPdata and the strategic plan. These algorithms change thestate of the world (agents, tasks).

We select segment se279 to present an example ofstrategic scheduling information. Fig. 11 shows the tem-poral assignments of agents to macro tasks located in thissegment.

Using the GIS, information about the strategic actionschedules of agents is visualized on a thematic 3D map tocreate an overall picture of the SAP problem.

5.6. Automated Adjustment of the Strategic ActionPlan

Uncertain and dynamic situations in the USAR envi-ronment disturb the strategic action plan, which is cre-ated for a specific time and is executed by agents. It is

Journal of Disaster Research Vol.0 No.0, 200x 15

Nourjou, R., et al.

necessary to refine and adapt this strategic plan to newsituations. Therefore, three key questions arise in rela-tion to this requirement. 1) Is there a right time to releaseagents from their threads and make a new strategic plan?2) Which agents should leave their threads? 3) Whichthreads should release their agents?

The role of the GICoordinator is to continuously andautonomously monitor the SAP problem data, which areupdated over time, in order to address these questions. Ifthe strategic plan must be adapted, the GICoordinator willre-create optimal thread assignments according to the up-dated SAP problem.

This feature is applied to the GICoordinator’s searchalgorithms to recognize the right time to release agentsfrom their threads.

6. Discussion

The modeling of the SAP problem data has two ob-jectives: 1) formulating and modeling the SAP problemto coordinate a disaster response team and 2) providinga framework to support the development of intelligentsoftware systems to formulate strategic action plans andschedules.

The efficiency of our proposed approach is dependenton two criteria: 1) data quality and 2) algorithm efficiency.The SAP problem data model enables and supports theimplementation and development of these criteria.

The SAP problem data model can be considered anappropriate framework to model related SAP problemsas well. Although this paper focused on and analyzeda specific SAP problem, the SAP problem data modeldesigned here can be modified and refined to addressnew requirements, such as those related to firefightingteams, flood evacuation operations, resource allocationproblems, medical emergency transportation operations,road-clearing vehicles, coordination problems among ICsdistributed across multiple teams, new types of informa-tion, tactical decision making, and even military operationcommands.

LoTeM tasks contain uncertain, simple, and approxi-mate information because tasks are abstracted from a lowgeographic layer to a higher one. However, they are im-portant and useful for ICs to accomplish two goals: 1)the efficient visualization of situational awareness and 2)fast but approximate calculations/estimations. The gram-mar of threads, which encode human intuitions to solvecomplex problems, is composed of the four types of in-formation in our SAP problem data model. This makespossible the formulation of other IC insights, such as thespecification of new constraints or types of actions thatneed to be scheduled.

The ”threadAssignment” class models informationabout the allocation of coalitions to sub-tasks in sub-locations for a specific amount of time. Because of spa-tial topology relationships between geographic objects,strategic action plans can be extracted for different geo-graphic layers. Information from this class can be inte-

grated with the internal beliefs and behaviors of agents.The SAP problem data model enables an information

system to extract and mine new information from thedatabase and display these data to ICs. Moreover, it canbe used in the development of disaster management [27]and IC decision support systems.

7. Results

Fig. 5 and Fig. 6 show the contributions of this paper.The SAP problem data model addresses the two researchquestions mentioned in Section 1. It includes five newfindings that evidence the originality of this paper.

The first contribution is the analysis of the SAP prob-lem and the design of the SAP data model to model SAPproblem data. The SAP problem data model is criticalfor the development of any approach to strategic actionplanning in teams to coordinate and manage disaster cri-sis responses.

The second contribution is the modeling of LoTeMtasks through the ”macroTask” and ”temporalMacroTask”classes and their integration with other classes. Theyare used for five purposes: 1) presenting a set of taskssummarized and distributed in geographic objects; 2) ex-tracting and integrating task information from one geo-graphic layer to another, according to their spatial topo-logical relationships; 3) organizing and managing tempo-ral changes in tasks and estimating their effects on depen-dent tasks; 4) creating thematic maps and extracting newinformation; and 5) strategic action scheduling.

The third finding is the encoding and formulation ofhigh-level human strategy guidance using the ”thread”and the ”strategy” classes and their integration into thedata model. These classes enable human agents to engagein the planning process and collaborate with an automatedplanning system. These two classes integrate human intu-ition and initiative in the data model and enable the auto-mated system to apply them to form the optimal strategicaction plan.

The next contribution relates to the use of the”threadAssignment” class to model a high-level strategicaction plan. This class constrains agent behavior by allo-cating them to threads.

The ”temporalMacroTaskAssignment” and the”legalAssignment” classes represent the fifth contribu-tion. These classes represent a strategic action scheduleand are integrated with other classes to form a completedata model of the SAP problem.

8. Conclusion

Our SAP problem data model aimed to model thestrategic planning problem in the coordination of emer-gency response teams during emergency response man-agement. The model is required to develop intelligentsoftware systems that collaborate with humans to addressthe SAP problem through good strategy specification, op-

16 Journal of Disaster Research Vol.0 No.0, 200x

Data Model for Strategic Action Planning and Scheduling Problems in DisasterResponse Teams

timally strategic action planning, and automated adjust-ment. Our data model focused on a specific problem butcan be refined to address the requirements of other ICs.

Future work should follow three directions. The first isto address problem-solving algorithms intended to formu-late strategic action plans and schedules. The proposedapproaches will use the SAP data model. The seconddirection for future work is to improve the SAP prob-lem data model with regard to new requirements or de-mands, e.g., resource allocation problems, the coordina-tion of distributed teams, or the integration of the SAPdata model with field unit decision support systems. Thefinal idea for subsequent research is to integrate the spa-tial database of the GICoordinator with information sys-tems and develop proper algorithms for data/informationextraction and integration in order to obtain the informa-tion required for this system from distributed data ware-houses.

AcknowledgementsR.N. is grateful for financial support from GCOE-HSE of KyotoUniversity, which enabled him to be a visiting scholar at the In-formation Sciences Institute of the University of Southern Califor-nia and the Robotics Institute of Carnegie Mellon University fromNovember 2011 to November 2012.

References:[1] Bigley, Gregory A., and Karlene H. Roberts. ”The incident com-

mand system: High-reliability organizing for complex and volatiletask environments.” Academy of Management Journal 44, no. 6(2001): 1281-1299.

[2] Boddy, M., B. Horling, J. Phelps, R. P. Goldman, R. Vincent, A.C. Long, B. Kohout, and R. Maheswaran. ”C TAEMS LanguageSpecification, Version 2.02.” DARPA, Arlington, VA (2006).

[3] Buck, Dick A., Joseph E. Trainor, and Benigno E. Aguirre. ”A criti-cal evaluation of the incident command system and NIMS.” Journalof Homeland Security and Emergency Management 3, no. 3 (2006).

[4] Burstein, Mark H., and Drew V. McDermott. ”Issues in the devel-opment of human-computer mixed-initiative planning.” Advancesin Psychology 113 (1996): 285-303.

[5] Chen, Rui, Raj Sharman, H. Raghav Rao, and Shambhu Upad-hyaya. ”Design principles of coordinated multi-incident emergencyresponse systems.” In Intelligence and Security Informatics, pp. 81-98. Springer Berlin Heidelberg, 2005.

[6] Chen, Rui, Raj Sharman, H. Raghav Rao, and Shambhu J. Upad-hyaya. ”Coordination in emergency response management.” Com-munications of the ACM 51, no. 5 (2008): 66-73.

[7] Decker, Keith S., and Victor R. Lesser. ”Quantitative modeling ofcomplex environments.” International Journal of Intelligent Sys-tems in Accounting, Finance, and Management 2, no. 4 (1993):215-234.

[8] Egenhofer, Max J., and Robert D. Franzosa. ”Point-set topologicalspatial relations.” International Journal of Geographical InformationSystem 5, no. 2 (1991): 161-174.

[9] FEMA, ”Fema Incident Action Planning Guide.” http://www.uscg.mil/hq/cg5/cg534/nsarc/FEMA%20Incident%20Action%20Planning%20Guide%20(IAP).pdf

[10] Fiedrich, Frank, Fritz Gehbauer, and U. Rickers. ”Optimized re-source allocation for emergency response after earthquake disas-ters.” Safety Science 35, no. 1 (2000): 41-57.

[11] Fuhrmann, Sven, Alan MacEachren, and Guoray Cai. ”Geoinfor-mation technologies to support collaborative emergency manage-ment.” In Digital Government, pp. 395-420. Springer US, 2008.

[12] Hunger, J. David, and Thomas L. Wheelen. Essentials of strategicmanagement. New Jersey: Prentice Hall, 2003.

[13] OCHA, INSARAG Guidelines and Methodology Manual,www.usar.nl/upload/docs/insarag_guidelines_july_2006.pdf

[14] Jain, Sanjay, and Charles McLean. ”Simulation for emergency re-sponse: a framework for modeling and simulation for emergencyresponse.” In Proceedings of the 35th conference on Winter simu-lation: driving innovation, pp. 1068-1076. Winter Simulation Con-ference, 2003.

[15] Jennings, Nick, Sarvapali D. Ramchurn, Mair Allen-Williams, RajDash, Partha Dutta, Alex Rogers, and Ioannis Vetsikas. ”The AL-ADDIN project: Agent technology to the rescue.” In Proceedingsof the First Intl. Workshop on Agent Technology for Disaster Man-agement. 2006.

[16] Johnson, Russ. ”GIS technology for disasters and emergency man-agement.” An ESRI White Paper (2000).

[17] Khalil, Khaled M., M. Abdel-Aziz, Taymour T. Nazmy, and Abdel-Badeeh M. Salem. ”Multi-agent crisis response systems-designrequirements and analysis of current systems.” arXiv preprintarXiv:0903.2543 (2009).

[18] Kitano, Hiroaki, and Satoshi Tadokoro. ”Robocup rescue: A grandchallenge for multiagent and intelligent systems.” AI Magazine 22,no. 1 (2001): 39.

[19] Kwok, Yu-Kwong, and Ishfaq Ahmad. ”Benchmarking and com-parison of the task graph scheduling algorithms.” Journal of Paralleland Distributed Computing 59, no. 3 (1999): 381-422.

[20] Maheswaran, Rajiv T., Pedro Szekely, Marcel Becker, Stephen Fitz-patrick, Gergely Gati, Jing Jin, Robert Neches et al. ”Predictability& criticality metrics for coordination in complex environments.”In Proceedings of the 7th international joint conference on Au-tonomous agents and multiagent systems-Volume 2, pp. 647-654.International Foundation for Autonomous Agents and MultiagentSystems, 2008.

[21] Maheswaran, Rajiv T., Craig M. Rogers, Romeo Sanchez, and Pe-dro Szekely. ”Human-agent collaborative optimization of real-timedistributed dynamic multi-agent coordination.” In Workshop 25:Optimisation in Multi-agent Systems, p. 49. 2010.

[22] Maheswaran, Rajiv T., Pedro Szekely, and Romeo Sanchez. ”Auto-mated adaptation of strategic guidance in multiagent coordination.”In Agents in Principle, Agents in Practice, pp. 247-262. SpringerBerlin Heidelberg, 2011.

[23] Malone, Thomas W., and Kevin Crowston. ”The interdisciplinarystudy of coordination.” ACM Computing Surveys (CSUR) 26, no.1 (1994): 87-119.

[24] Mansouri, B., K. A. Hosseini, and R. Nourjou. ”Seismic humanloss estimation in Tehran using GIS.” In 14th World Conference onEarthquake Engineering, Beijing. 2008.

[25] Mansouri, Babak, Mohsen Ghafory-Ashtiany, Kambod Amini-Hosseini, Reza Nourjou, and Mehdi Mousavi. ”Building seismicloss model for Tehran.” Earthquake Spectra 26, no. 1 (2010): 153-168.

[26] Moody, Daniel L. ”Measuring the quality of data models: an empir-ical evaluation of the use of quality metrics in practice.” In ECIS,pp. 1337-1352. 2003.

[27] Nakabayashi, Itsuki. ”Disaster Management System for Wide-AreaSupport.” Journal of Disaster Research 1: 46-71.

[28] Nourjou, Reza, Michinori Hatayama, and Hirokazu Tatano. ”Intro-duction to spatially distributed intelligent assistant agents for coor-dination of human-agent teams’ actions.” In Safety, Security, andRescue Robotics (SSRR), 2011 IEEE International Symposium on,pp. 251-258. IEEE, 2011.

[29] Nourjou, Reza, Michinori Hatayama, Stephen F. Smith, AtabakSadeghi, and Pedro Szekely. ”Design of a GIS-based Assistant Soft-ware Agent for the Incident Commander to Coordinate EmergencyResponse Operations.” arXiv preprint arXiv:1401.0282 (2014).

[30] Nourjou, Reza, Stephen F. Smith, Michinori Hatayama, NorioOkada, and Pedro Szekely. ”Dynamic Assignment of Geospatial-Temporal Macro Tasks to Agents under Human Strategic Deci-sions for Centralized Scheduling in Multi-agent Systems.” Interna-tional Journal of Machine Learning and Computing, IJMLC 4, no.1 (2014): 39-46.

[31] Nourjou, Reza, and Michinori Hatayama. ”Simulation of an Orga-nization of Spatial Intelligent Agents in the Visual C#.NET Frame-work.”, International Journal of Computer Theory and Engineering,IJCTE 6, no. 5 (2014): 426-431.

[32] Nourjou, Reza, Stephen F. Smith, Michinori Hatayama, and PedroSzekely. ”Intelligent Algorithm for Assignment of Agents to Hu-man Strategy in Centralized Multi-agent Coordination.” Journal ofSoftware, 2014.

[33] Nwana, Hyacinth S., Lyndon C. Lee, and Nicholas R. Jennings.”Coordination in software agent systems.” British Telecom Techni-cal Journal 14, no. 4 (1996): 79-88.

[34] Schurr, Nathan, Janusz Marecki, John P. Lewis, Milind Tambe, andPaul Scerri. ”The defacto system: Training tool for incident com-manders.” In AAAI, pp. 1555-1562. 2005.

Journal of Disaster Research Vol.0 No.0, 200x 17

Nourjou, R., et al.

[35] Smith, S.F., A. Gallagher, T. Zimmerman, L. Barbulescu and Z. Ru-binstein, ”Distributed Management of Flexible Times Schedules”,Proceedings 6th International Joint Conference on AutonomousAgents and Multi-Agent Systems (AAMAS 07), Honolulu Hawaii,May 2007

[36] Vafaeinezhad, Ali Reza, Ali Asghar Alesheikh, Majid Hamrah,Reza Nourjou, and Rouzbeh Shad. ”Using GIS to Develop an Effi-cient Spatio-temporal Task Allocation Algorithm to Human Groupsin an Entirely Dynamic Environment Case Study: Earthquake Res-cue Teams.” In Computational Science and Its ApplicationsICCSA2009, pp. 66-78. Springer Berlin Heidelberg, 2009. no. 1 (2014):39-46.

Name:Reza Nourjou

Affiliation:Ph.D. Candidate, Graduate School of Informat-ics, Kyoto University

Address:611-0011, Gokasho, Uji, Kyoto, JapanBrief Career:• 2006-2009, GIS Engineer, International Institute of EarthquakeEngineering and Seismology.• 2011-2012, Visiting Scholar, the University of Southern California.• 2012, Visiting Scholar, Carnegie Mellon University.Selected Publications:• ”Intelligent Algorithm for Assignment of Agents to Human Strategy inCentralized Multi-agent Coordination.” Journal of Software, 2014Academic Societies & Scientific Organizations:• Association for the Advancement of Artificial Intelligence

Name:Pedro Szekely

Affiliation:Project Leader and Research Assistant Profes-sor, Information Sciences Institute, Universityof Southern California

Address:4676 Admiralty Way, Marina del Rey, CA 90292Brief Career:• 1987, Ph.D., Computer Science, Carnegie Mellon University• 1988-Now, Research Assistant, ISI, University of Southern CaliforniaSelected Publications:• ”Maan: A multi-attribute addressable network for grid informationservices”, Journal of Grid Computing 2, no. 1 (2004): 3-14.

18 Journal of Disaster Research Vol.0 No.0, 200x

Data Model for Strategic Action Planning and Scheduling Problems in DisasterResponse Teams

Name:Michinori Hatayama, Dr. Engeneering

Affiliation:Associate Professor, Disaster Prevention Re-search Institute, Kyoto University

Address:Gokasho, Uji, Kyoto, 611-0011, JapanBrief Career:• 1994-1998 Hitachi System Technology, Ltd.• 2000, Doctor degree (Eng.) in Tokyo Institute of Technology.• 2002-2005, Assistant Professor in Disaster Prevention Research Institute,Kyoto University.• 2005-Now, Associate Professor in Disaster Prevention ResearchInstitute, Kyoto University.• 2006, Guest Researcher in Laboratory for Safety Analysis, Swiss FederalInstitute of Technology.Selected Publications:• ”Implementation Technology for a Disaster Response Support Systemfor Local Government”, Journal of Disaster Research, Vol.5, No.6,pp.677-686, 2010.• ”Design and implementation of grouped rescue robot system usingself-deploy networks”, Journal of Field Robotics 28(6): 977-988, 2011.Academic Societies & Scientific Organizations:• Information Processing Society of Japan (IPSJ)• Japan Society of Civil Engineers (JSCE)• GIS Association of Japan (GISA)

Name:Mohsen Ghafory-Ashtiany

Affiliation:• Distinguished Professor, Int. Institute of Earth-quake Engineering and Seismology, IIEES, Iran• Affiliated Faculty, GFURR, Virginia Tech,USA

Address:21, Arghavan st., North Dibajie, Farmanieh, Tehran, IranBrief Career:• 1989- Professor of Earthquake Engineering and Risk Management,IIEES• 2013- Affiliate Member of Iran Academy of Science• 2007- Chairman: IASPEI Comm. on Earthquake Hazard, Risk andStrong Ground Motion.• 2010- Chairman: SPRMI Insurance Earthquake Risk ManagementInstitute.Selected Publications:• ”An Automated Model for Optimizing Budget Allocation in EarthquakeMitigation Scenarios”; H. Motamed, M. Ghafory-Ashtiany and BijanKhazaie; Journal of Natural Hazard. (2014) 70:5168Academic Societies & Scientific Organizations:• 2009-President: Iranian Earthquake Engineering Association (IEEA)• 2009-Founding Member of the Integrated Disaster Risk ManagementSociety-IDRiM• 2008-Director: IAEE-World Seismic Safety Initiative.• 2008-Chairman: Joint IAEE-IASPEI Working Group• 2009-Advisory Board of the GeoHazard International, USA.• 1990-Permanent Member of the Iran Seismic Design Standard

Name:Stephen F. Smith

Affiliation:Research Professor, The Robotics Institute,Carnegie Mellon University

Address:5000 Forbes Avenue, Pittsburgh PA 15213Brief Career:• 1980 Ph.D., Computer Science, University of Pittsburgh• 1982 Joined Faculty of Robotics Institute at Carnegie Mellon University• 1989 Present, Director Intelligent Coordination and LogisticsLaboratorySelected Publications:• ”Distributed Coordination of Mobile Agent Teams: The Advantage ofPlanning Ahead”, Proceedings 9th International Conference onAutonomous Agents and Multi-agent Systems, Toronto CA, May 2010.Academic Societies & Scientific Organizations:• The Association for the Advancement of Artificial Intelligence (AAAI)• The Institute for Operations research and Management Science(INFORMS)• The Association of Computing Machinery (ACM)

Journal of Disaster Research Vol.0 No.0, 200x 19

The author has requested enhancement of the downloaded file. All in-text references underlined in blue are linked to publications on ResearchGate.The author has requested enhancement of the downloaded file. All in-text references underlined in blue are linked to publications on ResearchGate.