INTRODUCTION

Workflow is a conception which can bring computerized facilitation or automation for a business process. It is concerned with the automation of procedures in whole or part. In the procedures, documents, information or tasks are passed between participants according to a defined set of rules to achieve, or contribute to, an overall business goal (WfMC, 1996). Workflow management technology has been widely used in the emergency response management (Zhan, 2008). In the ERS, an emergency response process requires to issue and execute a set of tasks that have specified order of seniority. The task-flow (or workflow) could be represented and managed in different ways. Currently, workflow modeling techniques are relatively more mature. Of the worldwide workflow products, IBM's MQSeries workflow, Action Technologies, Inc. Metro, FileNet’s Visual Workflow, Adobe's Adobe Workflow Server and PAVONE Espresso are the most famous. In addition to those commercial products, many universities and research institutions also contribute a lot in this area. For example: Exotica/FMQM (FlowMarkon Message Queue Manager) was developed by IBM's Almaden Research Center; Meteor (Managing end-to-end Operation) and WIDE (Workflow on Intelligent and Distributed Database Environment) were contributed by Organization of Computer Science University of Georgia. However, the workflow research has a relatively late start in China. One of the well-known researches is Qinghua University’s CIMFlow, based on the research on CIMS application by Wu Cheng, Professor Fan Yushun and Professor Shi Meilin. They also accomplished the workflow management system based on Web and CORBA (Fan, 2001).

An overview of Workflow Management: From Process Modeling to Workflow Automation Infrastructure (Georgakopoulos et al., 1995) and ACTA: A framework for specifying and reasoning about transaction structure and behavior (Chrysanthis and Rammaritham, 1990) identify some relatively mature technologies and workflow modeling methods. Modeling and Parsing of Web Based Visualized Workflow and Research and Achieve on visualization tools of Workflow modeling (Li, 2003) describe several visualization workflow modeling methods. Shahzad and Rashid (2005) proposed architectural framework of workflow management system for heterogeneous and distributed environment which incorporates web-enabled independent interface for clients to execute workflows. Zhu et al. (2010) proposed a routing-based dynamic workflow and introduce agent technology into workflow management systems. Some workflow models are presented for workflow management system (Owaied et al., 2011; Li and Du, 2009). However, one emergency response process often requires a number of organizations to participate. In this aspect, researches about cross-organization collaboration in emergency response includes making the use of Petri net theory to model the task and making up the collaboration model among organizations (Meng et al., 2011), modeling about emergency impact assessment, resource utility classification and mapping between impact and utility with a domain ontology (Sun et al., 2011). Some construction methods are proposed to obtain the process expressions of all kinds of Petri nets based on decomposition (Zeng, 2008), many analysis and algorithms for the modeling Petri Nets are also given and developed (Zeng, 2011; Cui et al., 2011; Du and Guo, 2009). Besides, Alfize (2002) studied the metrics evaluation for industrial OO Petri nets models. However, most workflow management tools are difficult to be directly applied to emergency response disposal process. On one hand, those tools only support workflow model under specific areas, lack of multi-task coordination mechanism which limits the representation power. On the other hand, they are imperfect in modeling and simulation. In this study, we create a visual management and monitoring tool for cross-organization emergency response process in ERS, monitoring task’s actions, such as issued and executed and controlling tasks cooperatively among organizations. Representing task-flow in different views facilitates task coordination among organizations.

THE PRINCIPLE OF CROSS-ORGANIZATION ERS AND THE TASK-FLOW MODEL

In ERS, every emergency response process involves several organizations to work together to complete a series of tasks. These tasks may need either one organization to proceed independently, or multiple organizations to cooperate and communicate mutually.

The principle of cross-organization ERS: In a functional perspective, a typical cross-organization ERS consists of one command center and multiple emergency response organizations. The command center is responsible for creating emergency task-flow, issuing task commands to all organizations and monitoring the task’s actions during the emergency response process. The organizations execute the tasks following instructions from the command center. During the execution, different organizations may be interactive about the task information. During or after task execution, each organization can feed back task statuses to the command center. Figure 1 shows the principle of cross-organization ERS. During emergency response process, the interactions and dependent relations among organizations can be divided into three categories:

The task-flow model of cross-organization ERS: This section presents the formal models of task and workflow in cross-organization emergency response process.

Definition 1: In cross-organization emergency response, each task is defined as a six-tuple:

Task = <Name, State, Organizations, MessagesReq, MessagesSent, PostTasks>, including:

Fig. 1:	The principle of cross-organization ERS

According to Definition 1, for a task t₁, the name of t₁ is denoted as t₁, so are the other properties. The number of elements in set S is denoted as |S|, e.g., the number of elements in Organizations of t₁ is indicated as |t₁. Organizations|. The state of t₁ has a single value from a finite set, i.e., t₁. State ε {"Unissued", “Issued”, “Signed”, “Implementing”, “Completion”, “Revoked”}. And we constrain that t₁.Organizations ≠ ø.

Definition 1 implies three possible task coordination modes in organizations O₁ and O₂:

Definition 2: An emergency response process can be represented as a directed acyclic graph, denoted as a two-tuple V(process), E(process). Specifically, V (process) is the node set representing tasks, denoted as V(process) = {t₁, t₂...t_i...} in which t_i is a task as defined in Definition 1. E(process) = { t_i, t_j... t_m, t_n...}({t_i, t_j, t_m, t_n...}⊆V(process)) is the arc set representing the binary relationship between tasks.

By Definition 2, one emergency response process can be modeled as a directed acyclic graph. The sequence relationship between tasks can be derived from task’s PostTasks property. In the model, if there is a directed path from the vertex i to vertex j, then the vertex i is the precursor of j; j is the successor of i. If <i, j> is an arc in graph, i is the direct precursor of j; j is the direct successor of i.

In particular, the start node and end node in workflow of emergency response are defined as t₀ = 'Root',",ø, ø, ø, postT and t_end = 'End',", ø, ø, ø, ø , where, t₀.postTasks = postT is a set of t_i which satisfies the following conditions: t_iεV(process) and ∀t_jεV(process), t_j.PostTasks. In addition, in the workflow of emergency response, if ∃t_kεV(process, t_k.PostTasks = ø), then make t_k.PostTasks = t_end.

For example, Table 1 shows a process of cross-organization emergency response.

We use a model similar to Fig. 2 to model an emergency response task-flow, where, the rectangle node in Fig. 2 represents a specific task, start node and end node are presented with two circles, respectively.

Fig. 2:	An emergency response task-flow

Table 1:	A process of cross-organization emergency response

Fig. 3:	Task-flow of cross-organization

As shown in Fig. 2, the tasks which are issued by command center and their relationships form a task-flow model, can be expressed as process = V, E, where, V = {t₀, t₁, t₂, t₃, t₄, t₅, t₆, t_end}, E = {<t₀, t₁>,<t₀, t₂>, <t₀, t₃>, <t₁, t₄>, <t₂, t₄>, <t₄, t₅>, <t₄, t₆>, <t₃, t_end>, <t₅, t_end>, t₆, t_end}.

Figure 3 shows the task models formed in the organizations when carrying out tasks, respectively after receiving the mission from the command center. A rectangular region is called a swimlane meaning one organization scope. This term will be used directly in the following sections.

THE ARCHITECTURE OF VISUAL MANAGEMENT AND MONITORING TOOLS AND FUNCTIONS

Architecture: In order to monitor the execution of task for cross-organization emergency response intuitively and clearly in ERS, we construct a visual management and monitoring tool. Figure 3 provides a logic description of its structure. In this tool, the integrity of a particular emergency response process can be solved as atypical task-flow, because of the series of standardized task sets if formed. Therefore, task-flow library is a set which stored some examples of the emergency response process, all these typical task-flows have its own type and level.

The overall structure is shown in Fig. 4, a visual management and monitoring tool consists of the two major components, i.e., the command center monitoring task-flow and the organizations monitoring the task-flow.

The part of the command center monitoring task-flow is the visual environment after center commanders logged in the system, including the task-form editor and task-flow editor. The task-form editor displays the tasks included in the emergency response process in table format, for the sake of supervision and adjustments. The task-flow editor is divided into several sub-environments and is used to monitor and schedule the current emergency response process. When monitoring task-flow in emergency response process, we can refer to typical task-flows stored in the task-flow library, visualize them and make adjustments to the current situation.

The part of the organizations monitoring task-flow is a visual environment after organizations staff logged in the system. In this environment, each organization could do some operations on tasks issued from the command center, or exchange message with other organizations that have task-flow relationships, or feed back related information to the command center.

The command center monitoring task flow: The environment of command center monitoring task-flow includes the task-form editor and task-flow editor. The following will introduce the functions about the two editing environment.

In the task-form editor, emergency response tasks are listed in a table. Buttons on the table are associated with different operations, including task inquiry, creation, edition, assignment, withdrawal, completion and so on.

Fig. 4:	The structure of visual management and monitoring tool

Center commanders can quickly define the properties of new tasks, add them to the table; also can carry on related operations to selected tasks using the appropriate action buttons on the table. Finally, all operations are showed in the emergency response task-flow.

The task-flow editor can be divided into four parts: monitoring the overall task-flow, the command center monitoring the task-flow of organizations, monitoring messages exchanging among organizations and the visualization of typical task-flow in task-flow library.

Monitoring the overall task-flow: In this part, the command center manages and coordinates the overall task-flow rather than tasks distributed in specific organizations. The operation on the task node will synchronously affect all the participating organizations’ task-flow in this emergency response. For those “Unissued” tasks, we can view details in the task-flow, add a follow-up tasks, edit, issue, revoke; while for those issued ones, we can only do the operations of viewing details, adding follow-up tasks and removing the task.

The command center monitoring the task-flow of organizations: In this part, center commanders can monitor the task-flows of different organizations. The operations include:

Monitoring messages exchanging among organizations: Throughout the emergency response process, each organization executes its task-flow independently. In other words, the statuses of internal tasks within one organization can be shielded in the emergency response, only remaining interaction information such as coordination messages and task dependent relations between different organizations. The shielding mechanism both ensures the privacy of the task-flow within the organizations and simplifies the coordination of the relationship among organizations.

For example: in Fig. 5, the task t₄ in organization₁ is following task t₁ and task t₂, t₁ has completed by organization₁ and organization₂ together, so only the task t₁ in organization₂ is displayed according to the shielding mechanism.

Fig. 5:	Monitoring coordinate relationship among organizations

The value of property MessageSent set is {Message₁, Message₃} in t₃, the value of property MessageReq set is {Message₁} in t₁, the value of property MessageReq set is {Message₃} in t₆. Figure 5 also shows the message exchange of tasks among organizations. So, it is not only to ensure the independence and security operations within the various organizations but also monitor the link among organizations in a whole perspective.

The visualization of typical task-flow in task-flow library: People in command center can extract typical task-flows from task-flow library, visualize them and monitor the emergency response task-flow based on the typical task-flow. When importing typical task-flows, the system can recommend the best match task-flows according to the type and level of the current incident. After center commanders select one typical task-flow, the system will load the related follow-up tasks based on the existing task-flow structure.

The operations of management and monitoring include:

The organizations monitoring task-flow: The functions of this part consist of two parts: The first one is that, the person in organization can perform some operations for the task-flow in this organization listed in the next paragraph; the second one is that, monitoring the task interacting with other organizations.

Fig. 6:	Visual environment for organizations staff

View of the structure shown in Fig. 6. The monitoring operations in task-flow for organizations including:

As shown in Fig. 6, in the part of organizations monitoring task-flow, except for monitoring the task-flow in one’s own organization, people can view the communication with other organizations by some tasks. In the task-flow, if there are some tasks’ predecessor tasks or successor tasks in other organizations, people can view the detail information of predecessor tasks or successor tasks but can not edit them, such as t₁ and t₈ in organization₂. It is more convenient for people in one organization to control the task-flow in their own organization, when they can realize the communication with the tasks in other organizations.

TECHNICAL FEATURES OF VISUAL MANAGEMENT AND MONITORING TOOL

The visual management and monitoring tool employs several featured technologies including synchronization between different task editors, multi-view representation, task-flow recommendation and dynamic monitor.

The synchronization between task-form editor and task-flow editor: The task-form editor and task-flow editor in command center monitoring the task-flow are synchronous. The synchronization can be achieved from the three levels of view-logical control-model. The view level consists of task-form editing environment and task-flow editing environment. The logic control level is used to control show effects of both environments. The model level is mapping the task node model of emergency response. For example, the center commander adds a new task in the task-form editor, the following steps procedure could achieve the synchronization with task-flow editor:

Step 1:	The user adds a new task in the task-form editing environment, gives the name, the participant organizations and the successor tasks of the new task, respectively
Step 2:	The new task information is transmitted to logic control part of task-form, the name, the participant organizations, and the successor tasks are defined as namei, organizationsi, posttasksi
Step 3:	To build a new task instance ti, the properties are set as statei = 'not issued' and MessagesReqi = MessagesSenti = ø by default, that is ti = namei, 'not issues', organizationsi, ø, ø, posttasksi. To set a flag changeflagi = true for ti
Step 4:	In the logic control part of task-flow, to read all task instances and their flags, if the flag of the task instance tk is changeflagk = true, then display the task node with a particular color in the task-flow editing environment

Similarly, if the center commander modify some task’s information in the task-flow editing environment, the changes also can pass by the logic control part of task-flow, task node model and the logic control part of task-form, finally appear in the task-form editing environment.

The synchronization of task-form editor and task-flow editor is shown in Fig. 7.

The multi-view visualization of task-flow: In Fig. 8, multi-view visualization is fulfilled in two ways: on one hand, according to the roles of the people logged in ERS, the system presents different views; on the other hand, it represents different views based on the different requirement of center commander.

The visual environment of the tool is set to two different parts in accordance with the roles of landing people, one is the task-flow monitoring environment used by center commanders, the other is used by organizations staff. During the user’s login process, the system will verify the user’s role and assign corresponding authority according the account number. Center commander will be directed into the command center monitor environment, while organizations staff will be directed into organization monitor environment.

After center commander logged in, he can monitor and manage the task-flow in four kinds of views, i.e., the overall view of task-flow, the organizational view of task-flow monitored by center commander, the communication view of cross-organization and the view from typical task-flow in library.

Fig. 7:	Synchronization of task-form editor and task-flow editor

Fig. 8:	Multi-view visualization of task-flow

The overall view of task-flow is displayed as follows:

Step 1:	Read the task set of emergency response, denoted as taskList = {t1, t2, ...,tn}, initialize the start node t0 = 'Root', ", ø, ø, ø, ø and the end node tend = 'End', ", ø, ø, ø, ø
Step 2:	Take tiε taskList (0<i≤n) in turn, according to the information of task ti to establish a task node, if the node is not in view, then turn to take tpεti.PostTasks (0<p≤|ti.PostTasks|), if there is no corresponding task node of tp in the view, add it and add a directed arc tj, tp
Step 3:	Take tiεtaskList (0<i≤j) in turn, determine whether there is tpreεtaskList (0<pre≤n) to make tpre, ti appearing and determine whether there is tpostεtaskList (0<post≤n) to make tj, tpost appearing. If tpre is not existed, add a directed arc t0, tj; if tpost is not existed, add a directed arc tj, tend

The process used the algorithm:

Algorithm 1:
Step 1:	Get the task set of emergency response, denoted as taskList = {t1, t2,..., tn}, initialize the set of organizations orgList = ø, i, j is the iterator of taskList, k is the iterator of orgList and set that i = 1, j = 1, k = 1
Step 2:	Take tiεtaskList, if ti.Organizations ⊄ orgList, then orgList = orgList ∪ ti.Organization, i = i+1
Step 3:	If i>n, go to Step 4; otherwise, go to Step 2
Step 4:	Take orgkεorgList, draw the swimlane in the view, and named orgk. k = k+1
Step 5:	If i>|orgList|, go to Step 6; otherwise, go to Step 4
Step 6:	Take tjεtaskList, according to the task information to create a task node
Step 7:	Take Omεtj.Organization(0<m≤|tj.organizations|) in turn, if Om = orgh(0<h≤|orgList|), add the task node in orgh
Step 8:	Take tpεtj.PostTasks(0<p≤|tj.PostTasks|), if the task node of tp has been in the swimlane, then abandon it; else, create a task node according to tp, take Oaεtp. Organizations (0<a≤|tp. Organizations|) in turn, if Oa = orgh (0<h≤|orgList|), then add the task node in the swimlane orgh and add a directed arc tj ,tp
Step 9:	If j<n, go to the end; otherwise, j = j+1, go to Step 6

Step 1:	Take Omεtj.Organization(0<m≤|tj.Organizations|) in turn, p is the iterator of tj.PostTasks and set p = 1.
Step 2:	Take tpεtj.PostTasks, if the task node of tp already exists in the swimlane, then abandon it; otherwise, take Oaεtp.Organization (0<a≤|tp.Organization|) in turn, if Oa = Om, abandon tp, if Oa≠Om, create the task node of tp in the swimlane Oa and add a directed arc tj, tp.
Step 3:	If p>|ti.PostTasks|, go to Step 9 in Algorithm 1; otherwise, p = p+1, go to Step 2.

Thus, the final view shields the task-flow within the organizations, leaving only the task nodes and relations among different organizations.

Realization of the process is shown in Fig. 9.

The recommendation of task-flow: When center commander manages and monitors the emergency response task-flow by using the typical task-flow from the task-flow library, the system can recommend some typical task-flows based on the type and level of the current emergency incidents. After the center commander chooses one typical task-flow, the system can recommend some follow-up tasks based on the current situation of emergency response task-flow. Recommended methods are shown in Fig. 10, including typical task-flow recommendation and follow-up tasks recommendation.

Specific algorithm “Recommend (taskFlow, schemeFlow)” is as follows:

Algorithm 2:
Input: The task set of current emergency response taskFlow = {t₁, t₂,...,t_m}, the task set of selected typical task-flow schemeFlow = {t₁, t₂,...,t_n}.

Output: The recommended task set recomList from schemeFlow.

Fig. 9:	The view from typical task-flow in library

Fig. 10:	Recommendation of task-flow

Fig. 11:	Process of typical task-flow recommendation

The process of follow-up tasks recommendation is shown in Fig. 12.

Fig. 12:	Process of follow-up tasks recommendation

Fig. 13:	Dynamically monitoring of task status

Dynamic monitoring of task execution status: During the emergency response process, the statuses of node tasks in the task-flow follow the change of organizations. Under the view of the visual management and monitoring tool, people can monitor the change of task execution status dynamically.

The initial status of tasks created by the center commander is “Unissued”. The task status will become to “Issued” or “Revoked” if tasks are issued or revoked. Only the issued tasks can be operated by the organizations in the visual management and monitoring environment, the task state will change to “signed” or “implementing” after the task sign-up or start operation. If the command center approves all the applications to apply for completion of all the related organizations, the task states will become to “completion”.

The visual environment will update the monitoring page dynamically, that is to reread each property of emergency response tasks from time to time and rebuild task-flow model in the view. Under the visual management and monitoring environment, in order to let users monitor the change of the view process, the task node model will show different colors according to the difference of the property “state”. The realization is shown in Fig. 13.

In addition to the information of the task status, the change of other property information of tasks can be reread and refreshed in the current visual environment.

Therefore, after the operation for emergency response tasks, the people in organizations can monitor the task status and the change of each property in the visual environment without re-login. If the task status changes because of the monitoring operation, the center commanders can get the task information in time in the current visual environment by refresh from time to time.

AN INSTANCE UNDER THE VISUAL MANAGEMENT AND MONITORING TOOL

Taking the rescuing process of a coal mine accident in ERS as an example, we use the visual management and monitoring tool to monitor the process of this emergency response.

Once the incident named “Gas Explosion in No.1 Mine” is reported to ERS, the center commander will issue a series of sequential tasks in task-form editor or task-flow editor. The specific tasks are shown as in Table 2.

When the center commander enters the visual environment, they can operate the tasks in four views: The overall view of task-flow, the organizational view of task-flow monitored by center commander, the communication view of cross-organization and the view from typical task-flow in library.

Table 2:	The task list of “Gas Explosion in No.1 Mine”

Fig. 14:	Monitoring the overall task-flow

They can do operations such as task creation, deletion, edition, assignment and feedback.

The interface used for the command center to monitor issued tasks is shown in Fig. 14 and the color of node implies the task state; the interface used for the command center to monitor inner task-flow of one organization is shown in Fig. 15 and 16, displays the relations of tasks among monitoring organizations without concerning inner task-flow process.

Figure 17 shows the interface that the command center imports the typical task-flow of “Gas Explosion” from the task-flow library and visualizes it.

Fig. 15:	Command center monitoring the task-flows in organizations

Fig. 16:	Monitoring the communication among organizations

Fig. 17:	Editing task-flow in emergency response by typical task-flow

Fig. 18:	Organizations monitoring the task-flow in own organization

The center commanders can edit the task-flow of “Gas Explosion in No.1 Mine”, on the basis of the typical task-flow of “Gas Explosion”.

After the center commanders creating the task-flow on the basis situation of “Gas Explosion in No.1 Mine”, the organizations staff enter the visual environment and monitor the task-flow in their own organizations.

The interface shown in Fig. 18 is the view that people in “Production Section” organization enter the visual environment. People can operate the task nodes in the swimlane of “Production Section”, also can view the communication with other organizations.

In the whole rescue process of “Gas Explosion in No.1 Mine” accident, the command center and the organizations keep real-time communication, it is of great value for the rescue work.

CONCLUSIONS

This study introduces the management and monitoring tool in cross-organization ERS, shows the benefit of the tool for monitoring task-flow and, respectively illustrates the different operations for center commanders and organizations staff. According to the task model and typical task-flows, it puts forward a method for recommending the typical task-flow and emergency response tasks. There are some inadequacies in the recommending methods. We will further consider updating the algorithm in calculating the similarity of task-flow models, and the emergency resources scheduling mechanism in task-flow model also deserves a deep study in the future.

ACKNOWLEDGMENTS

This study is supported partly by the NSFC (61170079 and 2009BAG13A02); Sci. and Tech. Development Fund of Shandong Province of China (2010GSF10811); Specialized Research Fund for the Doctoral Program of Higher Education of China (20103718110007), Sci. and Tech. Development Fund of Qingdao (10-3-3-32-nsh), Excellent Young Scientist Foundation of Shandong Province of China (BS2009DX004 and BS2010DX009); the Research Foundation of Shandong Educational Committee (J08LJ77); Natural Science Foundation for Distinguished Young Scholars of Shandong and SDUST (JQ200816 and 2010KYJQ101); Research Project of "SUST Spring Bud" (2010AZZ177 and 2010AZZ069) and Graduate Innovation Fund of SDUST (YCA100339).