Abstract: In the cross-organization Emergency Response System (ERS), some tasks may depend on the coordination between various organizations in the disposal process of an accident. So monitoring and commanding the task-flow during the process is needed. In this study, firstly, we analyze the basic principles and define task-flow model in cross-organization emergency response system. Then we design and develop a visual tool to manage and monitor cross-organization workflow, tasks operations and cooperative control relationships among different organizations. The study introduces the architecture and the basic functions of the tool in detail and illustrates the feature technologies, such as the synchronization mechanism between different workflow editors, multi-view representations of workflow, workflow recommendation and dynamic monitoring over tasks’ execution statuses, etc. Finally, the study shows the significance and value of the tool in the emergency disposal process of a coal mine accident instance.
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:
| • | Some tasks of one organization must follow other tasks of another organization |
| • | Several organizations participate in the same task |
| • | There are message deliveries between organizations during the task’s execution |
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:
| • | Name: The name of the task can be used for identification |
| • | State: The current implementation status of the task |
| • | Organizations: The set of the organizations which participate in the task. It should not be empty |
| • | MessagesReq: The required message collection from other tasks during the execution, the collection can be empty |
| • | MessageSent: The sent message collection to other tasks during the execution, the collection can be empty |
| • | PostTasks: A collection of tasks following the current task. In other words, the tasks in PostTasks would be fired until the completion of the current task. When the set is empty, it means the current task is the last task |
| Fig. 1: | The principle of cross-organization ERS |
According to Definition 1, for a task t1, the name of t1 is denoted as t1, 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 t1 is indicated as |t1. Organizations|. The state of t1 has a single value from a finite set, i.e., t1. State ε {"Unissued", “Issued”, “Signed”, “Implementing”, “Completion”, “Revoked”}. And we constrain that t1.Organizations ≠ ø.
Definition 1 implies three possible task coordination modes in organizations O1 and O2:
| • | The sequential mode: For two tasks t1 and t2, if t2 ε t1.PostTasks, t1.Organization = {O1} and t2.Organizations = {O2}, then t1 and t2 is in sequential mode |
| • | The task-share mode: For a task t1, if there are two organizations O1 and O2 satisfying O1εt1.Organizations and O2εt1.Organizations, then t1 is the shared task of O1 and O2 |
| • | The message-exchange mode: For two tasks t1 and t2, if t1.MessagesReq∩t2.MessagesSent ≠ ø, or t2. MessagesReq∩t1.MessagesSent ≠ ø and O1εt1.Organization and O2εt2.Organization, then t1 and t2 is in the message- exchange mode |
Definition 2: An emergency response process can be represented as a
directed acyclic graph, denoted as a two-tuple
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 t0 =
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
=
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:
| • | Task detail: View the details information of selected task |
| • | Add task: Add a new task, take the selected task node as a precursor task |
| • | Edit task: Edit the selected task, only be available for the task nodes whose property of state is “Unissued” |
| • | Assign task: Issue the selected task to the relevant organizations, only be available for the task nodes whose property of state is “Unissued” |
| • | Revoke task: Revoke the selected task node |
| • | Attention: The color of the task nodes vary from the task states in the view. Different node colors indicate different task states |
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 t4 in organization1 is following task t1 and task t2, t1 has completed by organization1 and organization2 together, so only the task t1 in organization2 is displayed according to the shielding mechanism.
| Fig. 5: | Monitoring coordinate relationship among organizations |
The value of property MessageSent set is {Message1, Message3} in t3, the value of property MessageReq set is {Message1} in t1, the value of property MessageReq set is {Message3} in t6. 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:
| • | Copy a single task: Select a task node of the typical task-flow, copy it to emergency response task-flow, under a certain task node which is the precursor task of the coped task node |
| • | Copy task-flow fragment: In the typical task-flow, select the task-flow fragment (some task nodes with order) you want to add to the emergency response task-flow, perform the operation of "copy task-flow fragment" and then copy it in the emergency response task-flow, under some one node, task-flow fragment |
| • | Add precursor relationship: Select two task nodes in the emergency response task-flow, perform “add precursor mission” operation, you can set the task before and after relationship between the two selected nodes. The precursor relationship can not be repeatable set. If there were cycles in task-flow after adding precursor relationship, then the relationship can’t be created, too |
| • | Remove the precursor relationship: Select two task nodes with the sequence relationship in emergency response task-flow, perform “remove the precursor relationship” operation and you can delete the sequence relationship between two nodes. If the task has no predecessor tasks after the operation, this task will be automatically added under the root node in the task-flow |
| • | Task details: View the details information of selected task |
| • | Add task: Add a new task, take the selected task node as a precursor task |
| • | Edit task: Edit the information of selected task |
| • | Remove task: Remove the selected task and its follow-up tasks |
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:
| • | Task detail: View the detail information of the selected task |
| • | Sign-up task: This option is only available for the task nodes whose property of state is “Issued”. Select “Sign-up”, fill in the dialog with the name, indicating receipt of the task. Then organization could proceed with the task |
| • | Start task: This option is only available for the task nodes that do not start after assigned. Select this option to fill in the dialog with his/her name, then you can start the selected task |
| • | Feedback task: Transmit the message of task situation to command center. Select the option, the feedback window popped up, completing people’s information and the feedback content, judging whether it is urgent. Feedback person in the window is the one landed the system by fault. After completing the information, it can be fed back to the command center |
| • | Application for completion task: This is available only for the executing task. Select the option, a window popped up, fill with the applicant’s name (the one landed the system by fault) and finish feedback information. After that, it can be transmitted to the command center, and then it is up to center commanders whether end this task |
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 t1 and t8 in organization2. 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 = |
| 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 = |
| 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 |
| Step 3: | Take tiεtaskList (0<i≤j) in turn, determine whether
there is tpreεtaskList (0<pre≤n) to make |
| • | The organizational view of task-flow monitored by center commander is displayed as follows: First, get the set of all organizations involved in emergency response, remove reputation, display the view in swimlane style; then, analyze all tasks’ organizations property, find the task in which swimlane, add the task nodes to their swimlanes; next, analyze the tasks’ PostTasks property, find the relationship among them and add the connection; finally, add the start node and end node in each organization’s swimlane, all nodes without predecessor tasks are connected to the start node, all nodes with no successor tasks are connected to the end node. Eventually, the organizational view of task-flow monitored by center commander is shown. |
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 |
| Step 9: | If j<n, go to the end; otherwise, j = j+1, go to Step 6 |
| • | In the cross-organization communication view, when adding a task node in swimlane, we need to not only analyze the dependent relations of tasks but also compare with the swimlane of the successor task nodes. If the successor task nodes are in the same swimlane with the current task node, then abandon them; Otherwise add the current task node in its swimlane, add the successor task nodes which are not in the same swimlane in their own swimlanes and add the connection between them. The above process combines the Step 7 and Step 8 in Algorithm 1 into the following ones: |
| 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 |
| 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.
| • | The view from typical task-flow in library is displayed as follows: First, get all task-flows from the task-flow library to form a list. Then extract the properties of one task-flow from the list to from a typical task-flow model; at the same time, get the properties of all tasks in emergency response to from an emergency response task-flow model. Finally, the typical task-flow model and the emergency response task-flow model are displayed in the view together, center commander can editor and monitor the emergency response task-flow through the view operation button, on the basis of the typical task-flow |
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.
| • | Typical task-flow recommendation: In ERS, the current emergency incident has specific type and level, the typical task-flows in task-flow library also have their own type and level. First, extract the type and level of current emergency incident; then find the typical task-flows which have the same type and level with the current emergency incident; finally, the recommended typical task-flows are showed in the view as a tree list. The realization of the process is shown in Fig. 11 |
| • | Follow-up tasks recommendation: After center commanders selecting one typical task-flow, they can see the typical task-flow and the emergency response task-flow together. According to the comparison of two task models, the recommended follow-up tasks are shown in the typical task-flow |
Specific algorithm “Recommend (taskFlow, schemeFlow)” is as follows:
Algorithm 2:
Input: The task set of current emergency response taskFlow = {t1,
t2,...,tm}, the task set of selected typical task-flow
schemeFlow = {t1, t2,...,tn}.
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 |
| Step 1: | Let i and j are iterators of taskFlow and schemeFlow, initialize that i = 1, j = 1 and initialize a set of recommended tasks recomList = ø. |
| Step 2: | Take tiεtaskFlow. |
| Step 3: | Take TjεschemeFlow. |
| Step 4: | If ti.Name = Tj.Name, go to Step5; otherwise, j = j+1, go to Step 6. |
| Step 5: | RecomList = RecomList∪Tj.PostTasks. j = j+1. |
| Step 6: | If j>n, then i = i+1, go to Step 7; otherwise, go to Step 3 |
| Step 7: | If i>m, taking trεrecomList in turn, display tr in the view with a particular color, the end; otherwise go to Step 2 |
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).