Abstract: The process of emergency decision-making during a catastrophe is subject to uncertainty. This process is sufficiently complicated that it requires substantial knowledge, information support and multi-subject collaboration. Based on system science theory, the study analyzed the characteristics of emergency decision-making during catastrophes and discussed the internal architecture of the resulting system for the development of an emergency plan. In addition, the study combined general intelligent planning with an advanced knowledge-engineering approach. Furthermore, the hierarchical collaborative feature of the emergency plan was based on an ontology emergency knowledgebase. Moreover, this study defined ontology notations for general emergency planning based on the emergency domain and plan ontologies. In conclusion, the study provides a basic framework for multi-layer, multi-subject and multi-task emergency planning during catastrophes.
INTRODUCTION
Disasters are occurring in increasing frequency and are becoming more drastic. The more recent major events include the almost worldwide SARS outbreak that originated in China in 2002, a widespread power outage in California in August 2003, a tsunami in the Indian Ocean in 2004, the Wenchuan earthquake in China in 2008, the earthquake in Japan in March 2011, which caused a tsunami and a nuclear meltdown at a Fukushima plant and the recent hurricane (Sandy) that struck the northeastern United States in 2012. These types of disastrous events occur suddenly, which results in a shortage of information. These disasters also require emergency activity, which challenges not only the economic and social system’s capability to bear these disasters but also the emergency decision-making of the rescuing organizations. As an unusual social event, a catastrophe has the characteristics of coupling, derivation, abruptness and destructiveness and has long-lasting and significant impacts (Fan, 2007). Hence, the emergency decision-making during a catastrophe occurs under highly uncertain and dynamic conditions. Any mistake during this decision process would significantly affect the economic development, social stability and ecological health of the region (Smith, 2004). The construction of a scientific system for emergency planning during a catastrophe is crucial for building a complete and effective emergency management system (Pine, 2007).
Catastrophes are abrupt, unpredictable and uncontrollable. Catastrophes’ corresponding emergency plans have to be determined under conditions of high uncertainty, and the decision information has a high degree of randomness, deficiency and fuzziness. Hence, an emergency plan for a catastrophe involves decision-making during periods of notably high uncertainty. The response process during a catastrophe is different from that which occurs during a usual event because it requires us to accomplish tasks within a very short time after the occurrence of the tragedy to minimize the damage. In addition, there is a shortage of cases that can be used for reference and execution standards.
An emergency plan for a catastrophe should be analyzed under the uncertain planning theory framework. In the emergency activity process, an emergency planning process system should be able to meet the real-time process requirements, such as the rapid generation, acquisition, analysis, communication and dynamic updating of the activity plan for the various tasks (Jain and McLean, 2006). In addition, the emergency rescue activity relies on team collaboration. An effective emergency plan also depends on the collaboration between different departments from different areas because the collaborative process covers different domains (Mendonca and Wallace, 2009). Hence, the system needs to solve the problem of understanding the consistency that is required by the different domains.
This study attempts to describe a complete solution to an emergency planning system that meets the abovementioned requirements and provides the basis for the rapid response of uncertain and complicated tasks. The study first analyzes the hierarchy of a multi-subject emergency plan and classifies the types of emergency tasks. Second, according to the characteristics of a multi-subject emergency activity, the study built a general framework for an emergency task planning system based on an emergency knowledgebase. Third, a collaborative planning mechanism was introduced into the conventional emergency plan to convert the single emergency ontology behavior into a team collaboration that can be used as research key points. In conclusion, the study proposes an ontology-based task planning notation to provide a feasible solution to the inconsistency that exists between multi-subject and multi-domain emergency entities.
BASIS OF A HIERARCHICAL COLLABORATIVE EMERGENCY PLAN
Multi-layer division of an emergency decision: As shown in Table 1, the task layer is generally called the strategy layer to explain the goal of making the plan through an abstract description of the issues at a higher level. This layer also indicates the tasks that are required to achieve the goal. In addition, the task layer generates a group of subtask goals, although it does not elaborate these goals (De Albuquerque Siebra, 2006). The main activity in this layer is to analyze the relevant global information and to define the direction of the task(s). For example, in an earthquake, the emergency rescue control center is given the tasks of “rescuing the trapped”, “helping the injured” and “minimizing the damage within the disaster area”.
The resource layer refines the tasks from the task layer by analyzing the knowledge and information in the operational environment in detail to provide the resources that are needed for the various tasks and to manage and coordinate these resources (Castillo et al., 2006). Therefore, the resource layer decision influences the organizational activities to a certain extent. The study defines the resource types, the task constraint conditions, and the relevant relationships that are used for the accomplishment of a task by refining the task goals. The collaboration between the resources indicates the task execution process. For example, assume that the goal of a task is to “avoid the leakage of nuclear material by expanding it to x area”. In the corresponding resource layer, according to the knowledge of a nuclear leakage rescue professional, as well as additional practical information, the fire center is responsible for executing the analysis of the resources and the division of the goal.
The operation layer, which is also known as the meta-layer, includes the execution process of all of the meta-activities that are dynamic. The execution process can be preset by a single responsibility unit. The responsiveness and operational speed of the execution subject has a direct influence on the emergency results.
Framework of hierarchical, collaborative, ontology-based emergency plan system: Based on the abovementioned hierarchical division, an emergency plan is a multi-layer and multi-party distributed planning process that involves different emergency activity subjects that collaborate with each other to achieve the goal (Asuncion et al., 2005). The whole process requires a continuous information exchange. Therefore, this study introduced multi-subject team collaborative planning theory to analyze the complete task generation process and to build a collaborative planning system. The basic task of the system is to provide a mutual operational notation model for emergency task sharing that allows the team members to understand each other’s emergency plans and to support each other’s emergency activities (Ghallab et al., 2004; Yong et al., 2011). In addition, a set of coordination mechanisms should be designed to allow the team members to coordinate their emergency activities under the same emergency goal. Based on this research idea, this study designed an ontology-based emergency task planning process.
| Table 1: | Emergency decision layers |
| • | The emergency domain ontology knowledgebase should be constructed such that it meets the emergency plan requirements. The concept of ontology is introduced to systematically model, acquire and organize the planning domain knowledge. The content and notation capacity of the knowledgebase can meet the planning process requirements and supports the planning system’s solving process to improve the efficiency of the system |
The ontology knowledge in the planning domain is the abstract description of the dynamic environment in a planning system. The domain knowledge includes atomic propositions of the properties, the relationships of all of the objects in the planning system and all of the practicable tense activity operational rules. The atomic proposition can be divided into a true value variable proposition and a constant proposition. The constant proposition is the rational knowledge of the object’s attributes or relationships in the emergency planning domain. The emergency knowledge would be realized by the unified modeling of the emergency planning domain knowledge and the construction of an ontology-based emergency task notation model, storage and organization system. The ontology knowledge base includes the multi-source emergency domain objects and their attributes and the operational rules for various types of emergency activities. This knowledge base thus supports key nodes of the intelligent planning process for the identification of the emergency solution in the emergency response process.
| • | The system can dynamically plan tasks based on the emergency domain ontology knowledge base and generate the global optimized emergency task solution based on the different stages and units of the emergency plan. The segmentation, formulation and global integration of the emergency plan would be executed by the superior-subordinate relationship and the decision-making levels between departments. The proper extension of the recently advanced general intelligent planning technology would not only develop the strengths of the current technology but also enable the established general ontology knowledgebase to reasonably and effectively plan and solve the problem. The introduction of domain knowledge is equal to increasing the useful planning constraints to ultimately decrease the solution space. In addition, this process improves the solving speed and the resulting solution quality because it allows the system to reach or near the practical level |
In view of the above, the study designed the complete framework of an emergency planning system, as shown in Fig. 1. The main functions of the emergency planning system are described based on the framework:
| • | Global information integration: The system receives real-time data, which is transmitted by different information sources via an interface input. The data includes the crisis site equipment, environmental information, site video monitoring information, emergency guarantee resource information and mobile and satellite communication information. Because the multi-source data have different description patterns for the same entity or event, it is necessary to identify the information and integrate the input data sources. The system can generate a global information view using the identification and a universal description of the data, including figures, tables, texts and videos. Therefore, the entire emergency response community is able to quickly confirm the critical attributes, such as the exact location of the key nodes that were caused by the disaster, the disaster site situation, the basic geographical environment within the range of influence and the progress of the disaster relief |
| • | Disaster situation evaluation: The complete disaster situation should be evaluated. In addition, the evaluation of the current situation regarding the corresponding goals of the tasks should be generated according to the upper-level ontology instructions. The system should also predict any possible secondary or derived disasters |
| • | Task segmentation and distribution: Based on the results from the situation evaluation and the integration of the global information view, the system prioritizes the tasks in the complete emergency plan. Furthermore, each complete task is divided into several subtasks. In addition, the system distributes the subtasks to the different emergency plan units according to the task types |
| • | Unit plan results generation: According to the distributed tasks, each emergency plan unit collects the domain knowledge that is needed for the planning process from the emergency knowledgebase through a planning domain analyzer. In addition, based on the description of the planning issue, the system would use the activity operator set and the domain constraints to solve the plan and identify the plan result that best meets the unit requirements of the emergency plan |
| Fig. 1: | Emergency task planning system framework |
The emergency ontology knowledge base stores the relevant knowledge and the code standards for the complete issue solving domain. The base integrates the database, the preset standard emergency operational programming base, the knowledge base and the reasoning machine functions. Hence, this knowledge base supports the sharing and reuse of the knowledge.
| • | Plan integration: A globally coherent and non-redundant plan is integrated by eliminating any redundancy and any conflicts between the individual plans to obtain a multi-subject collaborative emergency. Furthermore, the system segments the issue into executable nodes (operation layer) according to the issue layers. In addition, the constraint mechanism should check the activity execution conditions to eliminate any conflicts and then perform a distribution of the standard executive programs |
| • | Plan distribution and command configuration: When a disaster occurs, each emergency subject can quickly start the emergency plan. In addition, the system would receive the detailed emergency program and activity information to assist the collaborative emergency activity. Furthermore, a visual communication system should be constructed to visualize all of the layers of the command architecture (Tecuci et al., 2008). The emergency command, which should be configured at both fixed and mobile terminals, can work alone or via a network to penetrate the forefront of the crisis and disaster |
Emergency team facing the unified task-planning mechanism: The emergency response is realized by the team; thus, the planning system should develop a good coordination mechanism between the different issue-solving units from the beginning. During the planning process, the coordination mechanism from the different member activities reflects a set of constraint mechanisms from the multi-subject unified activities. As a multi-subject system, each subject represents oi, (where i = 1, 2…n); each oi is composed of a unified activity team. Plan task P is achieved by collaboration oi. When the team starts to perform but does not finish task P, any member should exit the execution of task P if the motivation Q to achieve the goal of task P no longer exists. Furthermore, a team member who is bound by commitments when building the team should use upper-level subject communication language to notify another subject to cancel the cooperation. The team would later be dismissed with the agreement of the cooperation cancellation. If one subject does not receive the agreement from another, the member could not leave the team without authorization and should maintain the original basic team status. If the team task is achieved, the team members should each acknowledge this achievement and agree to dismiss the team, which would subsequently be subject to redistribution of the system’s usable resources. Therefore, defining JI (Θ, p, e), where p is the goal that is guaranteed by the team and represents the execution plan for the goal achievement and e is the continuous execution conditions (Tate, 2003).
The collaboration process, which is based on unified planning, includes the following:
| • | Team identification of the collaborative emergency activity goal |
| • | Building team status space. The status space describes the situation of each team member, including the plan layer where the member is located and the member’s behavior pattern assembly that reflects the emergency functions and describes the emergency resources |
| • | Team building collaboration operator. This operator shows the collaborative activity from different viewpoints. Defining the shared belief as EBel (O, PI), this means the achievement of the emergency plan goal. The unified activity plan P = {pi} is built according to the emergency activity knowledge base rules. In addition, based on the description of the team status space, it can specify and authorize a role for each member in the unified activity plan (Siebra et al., 2004) |
| • | Sharing mechanism of the execution process and implementation of the plan. As shown in Fig. 2, each activity appears as a subtask and is authorized to be a set of constraint mechanisms. When the activity does not satisfy a constraint, a delegation failure would be reported and the feedback sent to the upper-level plan to trigger a new planning process. All of the activities should be based on the exact time axis and with the qualitative or quantitative time as a reference to confirm the relationships, such as the sequence or simultaneity between activities. Furthermore, in the plan it should limit all activity increases, time constraints and resource constraints. During the implementation, each subject should continuously exchange the current status and execution progress. Hence, the system can coordinate the activities according to the unified plan goal |
GENERAL MODEL CONSTRUCTION OF AN EMERGENCY PLAN
Use of domain ontology knowledge base in the planning process: The emergency domain knowledge base includes the emergency domain objects, the static knowledge of their attributes (including some attribute default values), all of the activity operators that can be used for the planning process and the dynamic knowledge of their application premise and effects. In addition, this knowledge base also covers the domain constraints that limit the activity parameter value ranges to prevent the appearance of unfeasible operations in the planning results.
| Fig. 2: | Plan sharing based on information exchanges |
Furthermore, the base states that the axiom knowledge of the objects and the relationships between the object’s attributes (including incompatible relations) should meet the requirements of the planning process. Thus, the specific functions of the knowledge base in the planning process are classified as follows:
| • | The static knowledge is mainly used to complement the initial conditions of the planning issue that are not indicated in the issue description but belong to the default. Because the knowledge amount of the default values of the object attributes is tremendously high and the knowledge base also includes a large amount of unrelated content, the planning analyzer should filter the data based on a useful activity collection operator. In addition, only the propositions that appear at a certain precondition of the activity operator can be added to the issue’s initial status |
| • | The dynamic knowledge is mainly used to generate a useful activity collection operator for the planning process. To realize the conversion from a domain dynamic concept to an activity operator easily, it is necessary to uniformly define the attributes that the activity operator should have. Furthermore, the acquisition of this content is emphasis when building the knowledge base. Therefore, the corresponding contents in the issue domain which are directly extracted by the planning domain analyzer, will generate a useful activity collection operator |
| • | The axiom knowledge is mainly used to generate the domain constraints that can assist in the planning process. The planning domain analyzer can directly generate the domain constraint collection based on the issue domain. The constraint collection is used to eliminate the unreasonable nodes in the planning layout and to assess the incompatible relationships between some of the nodes during the planning process. The specific usage reflects the planning layout generation algorithm which is based on the domain constraints |
Emergency plan ontology and notation: The concept of ontology stems from philosophy. However, with the continuous development of computer science, ontology has developed a unique meaning: modal and explicit specification of shared and conceptualized information. The main objective of ontology design is to allow knowledge to be shared and reused and to make this knowledge consistent and uniform by using the same vocabulary which is based on an agreed contract. In addition, the planning issue requires a standard planning process. In single decision subject, a planning only needs to consider the efficiency of the decision-making and execution processes. However, in multi-subject planning process design, it must consider the common understanding of the domain concepts between different subjects (Decker and Li, 2000). Ontology provides a conceptual shared model that can be used for the construction of a framework that supports the planning and execution processes using unified collaborative planning. In addition, the emergency plan is the result of emergency in the planning process and the collection of a set of activity sequences. This study defined the ontology notations of a plan that provided the methods of domain information sharing in a multi-layer, multi-subject unified emergency plan.
Ontology of the layer architecture of the plan: Some approaches for the construction of an ontology model exist. For example, <I-N-C-A> (Issues-Nodes-Constraints - Annotations) (Tate, 2003; Tate et al., 2004) is a general ontology model that can be used to construct a hierarchically organized multi-subject plan. The <I-N-C-A> ontology model is composed of four basic concepts: issues, nodes, constraints and annotations.
This study considers the emergency plan ontology a generalized plan ontology model and an emergency domain ontology model to generalize the plan. The hierarchy between the different ontology concepts in the pre-plan can not only improve the efficiency of the ontology construction but also can easily extend and integrate the ontology. The basic hierarchical architecture of the ontology of the emergency plan is shown in Table 2.
Formalized framework for the emergency plan ontology: The construction of an emergency task planning domain ontology requires the definitions of the objects (as well as their attributes) that are involved in the emergency and the plan domains. In addition, this construction also requires all of the operational operators (activity patterns) that are used in the emergency planning process and their application premises and effects. In addition, the ontology covers the domain constraints that limit the value ranges of the activity parameters. Moreover, the ontology states that the axiom knowledge of the objects and the relationships between the objects’ attributes (including the incompatible relationships) should meet the requirements of the planning process. The top ontology of an emergency plan has the following ontological concepts:
| • | Emergency status: EvS is the status set of the possible emergency events. In addition, supposing evs as a limited and unified proposition set. Moreover, evs represents the ontology behavior basis of the plan system such that evsεEvS. T is the possible time collection such that tiεT. Therefore, S = {(evs1, t1), (evs2, t2)...(evsn, tn)} represents a set of event sequences, where, (evsi, ti) is a status description |
| • | Emergency plan issues: Depending on the emergency status, the system is required to solve the issue description. There are five types of issues: the original task issue concerns which issues should be solved; the tool issue concerns how the issues would be solved; the standard issue concerns the standards that could be used for solving the issues; the concept issue concerns how to explain an involved concept and the fact issue asks what the issue status is and whether it is true. Hence, the issue should be planned (e.g., initial status, goal status, class, level and instruction) |
| • | Standard activity program: The ontology executable activity collection includes the promise, the results and the execution process descriptions of each activity |
| • | Emergency activity meta: The activity meta involves the activities that are included in a plan. It can be a single task or an ontology plan. The activity meta is represented as nodes in a hierarchical planning system. If it is an ontology plan, it can be segmented by layers. When the plan is an execution process, the activity meta can be represented as a single task or as the subtasks that are involved; i.e., it is represented as an activity node (e.g., execution activity, object, or activity description framework). For example, consider the following activity meta: Act_id-x (transport objet from start to finish). The description of the frameworkfeature of the activity “transport” is reflected by “from” to “to”. The ontology objects “start” and “finish” should be defined before the activity is executed. Hence, the issue can be converted to an activity which is represented as a set of activity meta in the plan |
| • | Emergency resource: The emergency resources are classified as activity, consumable and application resources. The activity resources are the activity execution subjects, such as the emergency command center, firemen and medical staff. The consumable resources include energy, such as water and electricity and consumable equipment. The application resources include other resources, such as ambulances and fire trucks. Thus, a emergency resource is represented as the following: (resource name, class, subject, relevant attribute description: attribute, attribute value) |
| • | Activity meta constraints: These constraints include the limitations of the activity itself, the resources and the relationships among different activities. Therefore, the plan only contains the nodes that meet the requirements of the planning space. The constraints can be classified as key or subsidiary constraints and are represented as the following: (constraint class, constraint relationship, attribute condition in the description framework) |
| • | Environmental constraints: The environmental constraints concern the environment at the emergency site, such as the weather and the emergency status. These constraints can be modally represented as the following: <Type _cons: world-state, relationship: condition>((attribute object [attribute-qualifies]), value) attributes or attribute description. The value type can be defined as string, variable, activity, issue, number or symbol |
| • | Time constraints: The time constraints indicate the time required for the execution of each activity. Each activity in the emergency plan should be based on the exact time axis which can represent the activity relationship and the necessary activity execution times through either qualitative or quantitative time parameters. These constraints can be represented as the following: <Type_cons: temporal, relation: interval>intervals: (Act_id,(t_initial, t_final)) or temporal-relation: (Act_id-x, Act_id-y) |
| • | Emergency resource constraints: These constraints indicate the resources that should be used for the execution of a specific activity and can be represented as the following: <Type_cons: resource, relationship: resource-type>((resource object [resource-qualifier] [resource- range]), value) |
| • | Delegation constraints: The delegation constraints can be represented as the following: <Type _ cons: commitment, relationship: commit-type> ((Act _id-i, agent-j), true/false). It can also define additional constraints, such as preference constraints, conflict constraints, execution text constraints and permission constraints |
| • | Goal description: The emergency plan unit goal is described to attain all of the event statuses of the plan goals in the emergency status collection |
| • | Emergency plan: The emergency plan is represented as the following: Plan(O, p) = Uni=1plan(oi, pi), where, pi = (GD, PI, Actsets), GD is the goal description, PI is the plan issue and Actsrts is an activity description in the plan or the ordered activity meta set |
| • | Annotation information: This information is used to explain the information that is not easy to indicate in other parts of the framework, including the manually controlled decision information. An example of this information includes the addition or revision of certain decision information or basic planning information |
| Table 2: | Architecture of the emergency plan ontology |
The relationships between the concepts of the emergency plan EP-Relations represent the two-tuples collections between the emergency plan concepts. The key relations are the following:
| • | Paradigmatic relationships (composes) indicate that an emergency concept entity is composed of several other concept entities |
| • | Inheritance relationships (inherits) indicate that one of two emergency entities is part of a subclass and that the other forms part of the parent class such that the subclass inherits all of the attributes of its parent class. For example, the resource constraints are a subclass of constraints |
| • | One-way dependencies (implements) indicate that a subject and an activity of the emergency plan have an active and passive relationship, such as a subject plan and an event execution |
| • | Time sequences (follows) indicate the time relationship between two activities, such as input constraints, output constraints and time range constraints |
| • | Cause-and-effect relationships (affects) indicate a direct relationship between two actions by the resources that are required such that one activity generates another activity. For example, a cause-and-effect relationship, which is also a special time sequence relationship, is the combination of an input constraint and an output constraint |
| Fig. 3: | Description of relationships among emergency plan ontology concepts |
Figure 3 shows the relationships among emergency plan ontology concepts.
CONCLUSION
According to the urgent requirement of an emergency plan during a catastrophe, this study introduced the idea of ontology-based mechanism for a multi-subject collaborative plan. In addition, the study proposed an ontology-based framework for the emergency plan system. The framework comprehensively uses the domain knowledge in an emergency ontology knowledge base to plan and solve the emergency domain issue. Furthermore, the study introduced a formalized description of the construction of an emergency domain plan ontology notation to support the system’s operation.
An advanced intelligent planning algorithm and an emergency domain knowledge model were integrated in our method. This method made full use of their functions and advantages in the planning process. In addition, through the hierarchical segmentation of the emergency plan based on the type of decision problem, the relevant knowledge management was combined to identify the emergency task plan for the catastrophe. This framework design enables us to address different types of emergency management problems in a flexible manner. Furthermore, by providing a more professional, more intelligent and more humanized decision process to support the function, the system can assist the emergency personnel in solving the complicated domain plan issue. In addition, the proposed framework places lower cognitive burdens on the users because the users only need to identify the problem that should be solved and are not required to have broad domain knowledge or strong mathematical skills.
ACKNOWLEDGMENTS
This study was supported in part by Chinese Nature Science Found (No.91024028,91024031).