Checking Satisability of a Temporal Constraint Network Using

Get Complete Project Material File(s) Now! »

Tool Support for Coordination of a Disaster Response in Practice

We research in this paragraph the tools used in practice for inter-organizational co-ordination of activities in the disaster response by the disaster managers, such as police men and re ghters, within the SoKNOS project [DPZM09]. This will help us to unders-tand better their functionalities and limitations. The main aim of the SoKNOS project was to investigate technical integration of systems of di erent organizations in a disaster. Integration should facilitate exchange of information between di erent organizations to provide a better overview of the situation. The use case was a large-scale ood based on previous ood disasters in Germany. Many organizations have been involved in these disasters. The main integration technology was based on Service-Oriented Architectures (SOA) [Erl05] and Service Component Architectures (SCA) [MR09]. Within the SoKNOS project, several interviews have been conducted with partners in the project (e.g. Tech-nische Hilfswerk (THW), University of the Police, Dortmund Police, Fire Brigade of Berlin and Cologne [DKU+08]). A half-day workshop has been carried out in January 2009 with some of them (University of the Police, Fire Brigade in Berlin and Cologne) on the topic of inter-organizational collaboration in a disaster response. Inter-organizational collabo-ration does not only include public safety organizations, but also private organizations responsible for public safety (e.g. Deutsche Bahn or churches). This workshop helped us to better understand the limitations of inter-organizational collaboration involving human actors.
An important artifact for coordination of the disaster response is a plan [GH05, Qua86], which can also be understood as a \resource for action » [Suc87], i.e. reasoning and re ec-ting on it based on the situation faced [Bar97]. It is used by public safety organizations, humanitarian aid organizations or private companies. One major challenge for any res-ponse plan is that a disaster is by de nition something new and di cult to predict. This is contrary to the response procedures for an emergency, which can be planned in more detail. Going back to the motivational example, it is di cult to plan that the re ghters are injured or that the military has to provide sandbags for the re brigade. Several ele-ments of a disaster response plan based on the plans made available by disaster managers in the SoKNOS project are described in Table 2.2. This list is not exhaustive, because the available plans are not representative of all possible plans, but the list provides a suf-cient overview to understand the artifact. Disaster response plans are not detailed (cf. also [Suc87, Qua86]) and contain generic activities. There are few relations between acti-vities documented in plans, because they are subject to the concrete situation faced when using the plan [Dek03]. It is very costly to develop detailed plans for disasters that may never happen. Furthermore, there is still the risk that plans become too speci c, which may lead to the case that plans become rendered useless if the situation in a disaster is slightly di erent from the plan. This means they cannot specify all situations that may apply [Suc87]. It is impossible to anticipate every situation [Qua86] and adaptation as well as development of new plans can be necessary [Wei00, Suc87]. It would also be very costly to maintain detailed plans and adjust them to the object of risk of a disaster. For example, demographics of a community change and this a ects how the community can be evacuated. Another example is that the response procedures of other organizations can change over time. Some disaster response plans in the SoKNOS project were codi ed as law applying to several response organizations (e.g. several di erent re ghting organiza-tions in Germany, cf. FwDV 100 [fwd]) or that have been adapted by other organizations (cf. DRK-DV 100 of the German Red Cross [Rot00]). In this case, they deal with very generic aspects of organizational structure and response in disasters.
When activities are conducted then there needs to be a way to track their progress. For instance, the re ghter commander in the motivational example needs to keep track of the activities for protecting the residential area from the ood, for transporting injured re ghters and the activities of the military. Tracking is also used to monitor deviations between the plan and what has been done. Furthermore, other activities – not anticipated in the plan or performed by others – need to be described in order to be coordinated. Whiteboards [WPT06, GC10, BCSR07, MPBW07, Dra03] can be used for this purpose, when people need to share a common overview of the activities. New technologies allow sharing of Whiteboards over wide geographical distances using the Internet. Since it is a shared artifact, access to it needs to be managed to prevent it becoming useless. For instance, in the case of several people wanting to adapt the content of the Whiteboard to the situation [MPBW07]. Whiteboards only have an information sharing function, but do not provide any means to reason on the current situation. For example, it is not possible to display deviations from what was planned. The traditional non-electronic Whiteboard faces the problem of space limitations and its content cannot be easily communicated to others in di erent locations.
A Mission Diary [BLJ10, Bor92, MPBW07] or electronic log is used to record what has happened and when in terms of major events, activities or information exchanges with others. For example, the military can record which activities it has performed for the re brigade and this can be used for informing new sta after a shift changeover. The main aim of the mission diary is to understand the reasoning behind decisions, such as about speci c activities. It can also be used for funding purposes of the response by an organization, i.e. as a document to claim funding from the government for response actions. Other purposes are debrie ngs and providing relevant information to new stakeholders joining the response.
People need to exchange information about the situation with others to coordinate their activities. These other people can be found in their own social network. For instance, friends, colleagues or people of other organizations they have worked with in previous di-sasters or exercises. Going back to the motivational example, the re ghter commander knows the police commander from previous disasters and they can exchange informa-tion about the status of building a dam or evacuating the residential area. If stakehol-ders are situated in di erent locations, then di erent tools for communication are used [GC10, MPBW07, Dra03]. For example, phone, fax, e-mail or radio can be used. They di er in two important aspects : (1) Instant communication/feedback (e.g. phone or radio) vs. asynchronous communication (e.g. e-mail or fax) and (2) dominating communication paradigm, such as one-to-one, one-to-many or many-to-many. It depends on the organi-zation and situation faced, which of them is more adequate. Usually a lot of messages are exchanged and their relations are not clear. Recently, other tools have been used for com-munication in a disaster response, such as Internet social network services (e.g. Twitter or Facebook) [VHSP10]. However, they are currently predominantly used by organizations not specialized in public safety or by individuals. They are similar to the tools mentioned, but provide another communication channel with a potentially larger audience.
Communication can be based on pre-de ned templates, called structured situation messages [BLJ10, Bor92]. An example from the SoKNOS project for a structured situa-tion message is the \4-fach Vordruck » (four layer template, cf. Figure 2.5). It is also used for communicating commands and feedback via its content eld. It de nes time and date of a message. An important aspect is that the receivers of the message can be de ned. Prioritization of messages can be articulated. Finally, additional comments can be descri-bed (e.g. which communication tool to use). At the moment, this template is lled out mostly by hand. Although it is possible to de ne the receiver of a message or to forward it to other interested stakeholders, this is still a manual error-prone process. It is not possible to relate the messages to each other.

Coordination of Activities in Dynamic Situations

We present in this section four di erent categories of approaches related to coor-dination of activities in dynamic situations : process-based coordination, artifact-based coordination, rule-based coordination and combinations of them. Process-based coordina-tion is used to make relations between activities explicit by specifying their control- ow. Artifact-based coordination can be compared to coordination of activities mediated via a business artifact (cf. also [Bar98, Bar00]), i.e. the relations between activities are mode-led explicitly between activities and an artifact (e.g. an invoice). Rule-based coordination is used for de ning relations between activities implicitly as a set of rules that should be followed during execution of activities. Finally, all these approaches can be combined together in several ways.
We categorize di erent technical solutions according to their main focus. All the ap-proaches are illustrated via an example from the business domain, because they have been developed primarily for supporting business operations. We discuss advantages and limi-tations of these approaches from the perspective of coordination of activities in dynamic situations given the disaster response context presented in the previous chapter.

Process-Based Coordination

Process-based coordination can be seen under the umbrella of business process ma-nagement [vdAtHW03]. The discipline of business process management is broad [Ham10, vBR10, LD98] and the focus here is its technical dimension. The activities in business processes can be managed and coordinated using a business process management sys-tem (BPMS) or work ow system [DHL01, vdAtHW03, OAWtH10]. The scope of these systems are operational routine business processes that have few predictable exceptions during process execution and the execution frequency of one process is high [DvdAtH05]. Examples for these types of processes are administrative processes, such as travel booking or approval processes.
Processes are fully speci ed in these systems from a control- ow, resource and data perspective. The control- ow makes the dependencies (relations) between activities expli-cit by describing activity sequences, e.g. activity \B » follows activity \A ». Each activity of the business process is part of a sequence. These sequences or parts of them may also be executed in parallel. Furthermore, alternative sequences can be described. A business process has a clear start and a clear end. The control- ow describes a full speci cation of all possible activity sequences of a business process. The resource perspective de nes who is supposed to execute an activity. The data perspective describes the data that is processed by activities. A work ow system or process management system can support the coordination of a business process by executing automated activities in the process, assigning human resources to activities (asking them for input) and keeping track of the current execution state (what activities are currently executed and have been executed) according to the prede ned business process model. More precisely, the process is enfor-ced by the system without possible deviations. The process models need to be correct, otherwise they cannot be coordinated properly by a work ow system.
Recently, the Object Management Group (OMG) published the Business Process Mo-deling Notation (BPMN) standard version 2.0. This standard describes how business processes could be modeled and executed within a work ow system [bpm]. Figure 3.1 illustrates an example for a process modeled using this standard : the loan management process. A customer requests a loan from the bank. The bank clerk enters some data about the loan. A decision is made, if there is a need for an extra check of the loan based on the data of the loan. An extra check means that a background check and history check of previous loans of the customer is initiated. This check is done by the credit bureau. In any case, the manager decides to approve or not approve the loan. The bank clerk has to nalize the loan application in the end.
However, the standard work ow approach is not seen as very exible and drawbacks have been identi ed in di erent work contexts (cf. [BBS95, Gri00, BR10]). For example, the process model describing the relations between activities cannot be changed once the process has started. Furthermore, the process is enforced by the system. This makes coordination supported by work ow systems unsuitable for dynamic situations. This led to the development of a variety of approaches to support exibility in the coordination of a process, but still based on the same idea of a fully speci ed process model describing sequential relations between activities (cf. Figure 3.1). These approaches may provide exibility from a control- ow, data and resource perspective.

Flexible Process Management Systems

The ADEPT approach supports a wide range of extensions to address the limitations of the standard work ow approach [Rin04, DR09]. For example, it allows adding, removing or skipping activities during process execution. The main goal of this approach is to ensure data consistency when performing these operations. Another goal is that the process model remains syntactically correct (e.g. does not contain deadlocks) after performing these operations.
Grigori et al. optimize the scheduling of activities by anticipating which activities can be already executed given their preconditions [GCG01, Gri01]. Thus, it weakens the strict sequential order of activities by supporting overlapping execution of activities. The processing of data streams using a work ow system is similar [BP07, Bio08]. Although the main focus of these approaches is the data perspective, they allow more exible de nition of the relations between activities and can deal to a limited extent with shifting goals. For instance, it is already possible to review a document due to a deadline, although the document has not been completed.

Table of contents :

Chapitre 1 Introduction
1.1 Contributions
1.2 Thesis Outline
Chapitre 2 Context
2.1 Introduction
2.2 Coordination of Activities by People of Dierent Organizations in Dynamic Situations
2.2.1 Motivational Example : Coordination in the Disaster Response
2.2.2 Background : Disaster Response Management
2.2.3 Summary
2.3 Research Problems and Contributions
2.3.1 Problem Statement
2.3.2 Research Questions and Method
2.3.3 Publications
2.4 Conclusion
Chapitre 3 State of the Art
3.1 Introduction
3.2 Coordination of Activities in Dynamic Situations
3.2.1 Process-Based Coordination
3.2.2 Artifact-Based Coordination
3.2.3 Rule-Based Coordination
3.2.4 Integrated Approaches
3.2.5 Summary
3.3 Coordination by People of Dierent Organizations
3.4 Conclusion
Chapitre 4 Framework for Coordination of Activities
4.1 Introduction
4.2 Modeling Coordination of Activities
4.2.1 Activity Type
4.2.2 Activity
4.2.3 Temporal Dependency
4.2.4 Summary
4.3 Verication
4.3.1 Translation of a Model into a Temporal Constraint Network
4.3.2 Checking Satisability of a Temporal Constraint Network Using
4.3.3 Performance Considerations
4.3.4 Summary
4.4 Detecting Deviations from the Model and How Activities Are Executed
4.4.1 Tracking Execution of Activities
4.4.2 Dependency Violation
4.4.3 Unsynchronized Dependencies
4.4.4 Summary
4.5 Example
4.6 Related Work
4.7 Conclusion
Chapitre 5 Inter-Organizational Coordination
5.1 Introduction
5.2 Sharing Activities between Organizations
5.2.1 Activity Workspace
5.2.2 Example for Sharing of Activities
5.2.3 Replicating Shared Activities in Dierent Activity Workspaces
5.2.4 Summary
5.3 Verifying an Activity Workspace Containing Shared Activities
5.3.1 Problem Statement
5.3.2 Requirements for Verication
5.3.3 Discussion of Requirements
5.3.4 Protocol for Verication of an AW Containing Shared Activities
5.3.5 Summary
5.4 Detecting Deviations from the Model and How Shared Activities Are Executed
5.4.1 Tracking the Execution of Shared Activities
5.4.2 Conicting State Changes of the Same Shared Activity
5.4.3 Conicting Views on the Causal Order of State Changes of Dependent Shared Activities
5.4.4 Detecting Violation of Temporal Dependencies Involving Shared Activities
5.4.5 Detecting Unsynchronized Dependencies Involving Shared Activities
5.4.6 Incomplete Propagation of State Changes of a Shared Activity
5.4.7 Summary
5.5 Related Work
5.6 Conclusion
Chapitre 6 Implementation
6.1 Introduction
6.2 Main components
6.3 Integration into Google WaveTM
6.3.1 Preliminaries
6.3.2 Extension – Architecture
6.3.3 Extension : Persistence of ActivityWorkspaces and Replicating Shared Activities
6.3.4 Gadget – Graphical Modeling Tool
6.3.5 Robot – Distributed Coordination
6.4 Conclusion
Chapitre 7 Evaluation
7.1 Introduction
7.2 Interviews
7.2.1 Selected Comments
7.2.2 Discussion
7.3 Design of an Experiment
7.3.1 Design Details
7.3.2 Data Sources
7.3.3 Validation of the Experiment Design
7.3.4 Discussion
7.4 Conclusion
Chapitre 8 Conclusion and Perspectives
8.1 Contributions
8.2 Perspectives for Future Research
Annexe A Case Study Prototype
A.1 Modeling of Activities
A.2 Modeling of Dependencies
A.3 Sharing of Activities
A.4 State Change of Shared Activities and Dependency Violation
A.5 Concurrent State Changes of the Same Shared Activity
A.6 Verication
Bibliographie

GET THE COMPLETE PROJECT