Pervasive Emergency Response Process Management System

J6m Franke, Cedric Ulmer

Public Security SAP Research Sophia Antipolis

Mougins, France {joern.jranke,cedric. ulmer}@sap.com

Abstract-One problem during an emergency for the teams in the field and the command center is to get an overview about who is doing what and how it is related to other activities. Current approaches for developing such an overview, for example, email, phone or radio are message-based and do not highlight dependencies between activities, do not support a sophisticated update mechanism of already exchanged activity information (e.g. state changes) and do not support awareness of what other activities people do. People in the field do not have any support for getting such an overview and rely on messages from the command center. In this article we propose a pervasive emergency process management system that is able to support modeling, execution and monitoring of ad-hoc response activities in the command center and different teams in the field. This system is able to exchange these activity information with other people in the field and even other organizations which can integrate these activity information in their processes. We discuss problems associated with this exchange and how it can be implemented using existing standards. Finally, we provide an overview of related work and our future research.

Keywords-pervasive; emergency; process; management; sys­tem; activity

I. INTRODUCTION

Disasters, such as Hurricane Katrina, are receiving more

and more attention, because of the growing awareness in an

inter-networked world. An important problem for responders

is cross-organizational emergency process management (cf.

[1 D. Our research has shown that emergency processes

are different from business processes and require different

solutions [2]. They also have a higher pervasive nature,

because teams in the field or command centers of different

organizations are highly independent, but need to align their

activities [3]. The goal of this paper is to provide a system

for pervasive process management in the disaster response

to address this issue. We introduce a use case for this system

in the next section. In the third section we describe the

requirements for this system based on the use case and other

research. We describe the design of the pervasive emergency

response process management system in the fourth section.

We compare our approach with related work in the fifth

section. Finally, we give an outlook on further research.

978-1-4244-5328-3/10/$26.00 ©201O IEEE 376

Fran�ois Charoy

LORIA Universite de Lorraine, UHF, LORIA

Nancy, France charoy@loria.jr

II. USE CASE

This use case has been derived from a larger scenario

within the SoKNOS project [4]. It is based on true flood

disaster cases and end user (e.g. fire fighter or police)

interviews. In the paper's case two organizations, police and

fire fighters, are responding to a flood. This is illustrated

in figure 1. On the strategic or command center layer,

illustrated in the upper part of the figure, the police chief

and the fire fighter chief exchange information regarding

the status of their strategic activities. The police has the

strategic activity to evacuate the residential area, if the area

is about to be threatened by the flood. The fire fighters

have the strategic activity to protect the residential area

from the flood. In the field we find several operational

activities, for example, the police has to warn the people in

case of an evacuation, has to transport the people etc. The

fire fighters in the field have to build a dam to protect the

residential area from a flood or have to transport sandbags

to build the dam etc. All these activities have dependencies

between them. The activities in the field are dependent

on the corresponding strategic activity. For example, if

the activity "Transport Sandbags" fails then the strategic

activity "Protect Residential Area from Flood" has to be

canceled. There are also dependencies cross organizations.

For example, if the activity "Build dam" of the fire fighters is

interrupted then the police has to execute the activity "Warn

people" to warn the people that the residential area might

have to be evacuated. Our research has shown that these

dependencies are temporal dependencies between different

states of activities. The problem is that such an overview

of activities and their dependencies does not exist [3] and

that those information are usually written on whiteboards or

paper and are not linked on the cross-organizational level or

even cross team level. It is also difficult to integrate emerging

activities. For example, if one or more police men get injured

during evacuation then their colleagues will rescue them

first before they evacuate other people. In this example it

is difficult for the command center to know what is the

current status of activities, because the information arrives

from different communication channels (e.g. radio, phone

or e-mail) without any connection between the transmitted

Communication

Strategic Activijies (Police)

Figure 1. Use Case

infonnation. This scenario is a pervasive scenario, where we

have different distributed entities (e.g. in this use case we

have command centers of police and fire fighters and several

teams in the field). We have to link these entities to create

a common consistent picture of the activities. A centralized

solution is not accepted by the organizations, because of

several reasons, e.g. controls and regulations. For example, it

is not possible that the police give access to their systems to

other organizations. In the following sections we describe the

requirements for a solution addressing the issues mentioned.

III. REQUIREMENTS

We derived from this use case and several other research

studies we did [2] (e.g. interviews/workshops with end

users in the SoKNOS project, literature review and case

studies) the following requirements for a pervasive process

management system:

1) Modeling of activities and dependencies: Activities

can be created ad-hoc (e.g. by people in the field

or command center), because new activities, which

have not been done before, may occur. Different

types of activities, such as decision-making activity or

operation in the field, need to be modeled differently,

because there is a different management process for

them. It is important to define the accountability and

responsibilities in the management lifecycle of an

activity. There can be a temporal dependency between

the management lifecycles of different activities. This

is the result of our research and currently this is not

377

supported adequately by process management systems.

2) Shared activity workspace: Modeled activities and

dependencies are stored and displayed on a shared

activity workspace, so that people can collaboratively

work on a model.

3) Execution of activities: Execution is described as state

change of activities. State changes of all activities take

place concurrently, because in reality all the activities

are running in parallel. Each state change may violate

dependencies and this needs to be managed by the sys­

tem (e.g. by visualizing them). This facilitates better

understanding of the disaster response processes.

4) Monitoring of shared activity workspace: Each user

can visualize the activities and their dependencies

differently, e.g. by providing a map of activities or

an activity matrix. This requirement results from the

fact that each organization has already means for

monitoring of the response processes and they are used

to them.

5) Pervasive characteristics: Some of the activity and

dependencies infonnation can be exchanged between

different shared activity workspaces within and out­

side the organization. Exchange always takes place

between people based on prior private or work-related

contacts and not between organizations. Subsequent

state changes of the exchanged activities need to be

propagated to all shared activity workspaces the activ­

ity has been exchanged with. People need support for

getting aware of activities of other people. We found in

our interviews that people exchange infonnation about

activities and integrate this in their processes.

IV. PERVASIVE RESPONSE PROCESS MANAGEMENT

SYSTEM

A. Overview

In this section we describe how emergency processes are

modeled and executed. Emergency processes differ from

business processes and need different approaches to reduce

the complexity of the process models. Afterwards, we de­

scribe how emergency response process infonnation can

be exchanged and integrated in the processes of different

organizations or teams (Le. shared activity workspaces) in a

pervasive scenario.

B. Modeling

1) Overview: Our emergency response process modeling

approach supports the following model elements: activity

types, activities and dependencies between states of different

activities. Activities have an activity type (e.g. "field opera­

tion" or "decision-making"). Different activities may have a

different activity type. All activities are running in parallel

(Le. state changes can happen in parallel). Dependencies can

be established between states of activities. We support ad­

hoc modeling of the model elements: They can be created

before and during execution (see subsection execution). The

activities and their dependencies are modeled on a shared

activity workspace. Each organization or team has may have

its own workspace. We describe the model elements in the

next paragraph. Afterwards, we give an example for our

modeling approach.

2) Meta Model: An activity type atd = (SA, f, G) is

described as follows:

• S is a finite set of activity states

• S A � S is a subset of activity states for the activity

type

• f : SA -+ SA is a transition function defining the

possible transitions from one state to another for one

activity type

• G = {9a, 9r, 9c, 9i} describes four governance roles

and their transition functions for changing an activity

state. The idea is that depending on the role only a

certain subset of transitions can be made.

9a � f is the transition function of the accountable

role for the activity. Accountability describes who

decides on the activity and also the governance

arrangements.

9r � f is the transition function of the responsible

role for the activity. Responsibility describes who

executes the activity.

9c � f is the transition function of the consulted

role for the activity. Consulted describes who

should be consulted prior a state change.

9i � f is the transition function of the informed

role for the activity. Informed describes who is

informed after a state change.

An activity ai = (uid, name, cs, ad, G A) is defined as

• uid is a unique identifier of the activity

• name describes the activity

• cs E SA is the current state of the activity

• ad EAT = (atl, .. , atn) one activity type in the set of

activity types

• G A = P x G describes the assignment of governance

roles to participants

• P is the set of assigned participants (users)

The activity specification can be extended with further

important data (e.g. resources or geographical location).

A dependency can be established between states of two

different activities. We distinguish thirteen different depen­

dencies (see figure 2) between states based on Allen's pro­

posed thirteen time interval relationships [5]. These temporal

relationships are exhaustive, distinctive and qualitative. It

is not necessary to provide concrete time information (e.g.

at 5 p.m. or in 5 hours). It should be noted that not all

activities needs to be connected via dependencies and that

dependencies can be created and removed at any point in

time. The created models need to be verified every time a

dependency is added. Several properties need to be fulfilled

378

Pre-cedes

Equals SI:;ed

Meets Over- Finished Con-

laps by lains Starts

Figure 2. Thirteen temporal dependencies between states of activities

Figure 3. Example for an activity type: operation in the field

by a model, e.g. the dependencies should not form a cycle.

These properties can be validated in linear time based on

standard graph algorithms. Thus the system is able to react

in real-time.

3) Example: Activities can be created by users on a

shared activity work space at any point in time, because we

don't distinguish between a separate design, execution or

monitoring phase. Activities are based on activity types as

mentioned before. Each activity type has its own lifecyle.

In figure 3) we illustrate an activity type "operation in

the field". Different roles are assigned to the transitions

between lifecycle states. For example for the activity type

"operation in the field", only the roles accountable and

consulted are allowed to change from the state "Plan" to the

state "Execute". Figure 4) illustrates two activities and one

dependency between the state "Execute" of each activity.

The dependency says that both activities have to be in

the execution state at the same time. Dependencies can be

established between states of activities at any point in time.

C. Execution

1) Algorithm: Execution is about changing the state of

an activity and managing the dependencies between them.

We describe the execution only briefly here, because it is

not the scope of the paper. The algorithm works as follows:

1) State change of an activity is requested (by human or

machine)

I I

----------­Transpor1 Sandbags

" . I' . . � .EHc:ute ___ equals __ �Ex.aJt ...

Figure 4. Example for modeling activities

2) If state change is allowed by governance role continue

with execution

3) Create a list of dependencies which are violated by

the state change

We use automata representing the dependency to detect vio­

lation of them. These automata have state changes as inputs.

Depending on the state change the automata turns into the

state violated or neutral. The system has three choices to

manage the violation of dependencies: Not allowing the

state change (enforcing the dependency), visualization of the

violation of dependencies (support) or trigger the required

state changes of other activities to fulfill the dependency

(automation). The treatment of dependency can be modeled

in our system together with the dependency.

2) Example: Figure 5 illustrates an example for execut­

ing two activities. This example is based on the previous

modeling example. In the first phase, both activities are in

the state "Plan". The dependency is not violated, because

no activity is in a state described in the dependency. The

responsible role for the activity "Build dam" switches to

the state "Execute" in phase 2. The systems warns the

participants in the shared activity workspace that there is a

dependency conflict, because if the activities "Build Dam"

switches into the state "Execute", the activity "Transport

Sandbags" has also to switch into the state "Execute" and

vice versa. In the third phase, the responsible role for

the activity "Transport Sandbags" switches into the state

"Execution" and the conflict is resolved.

D. Decentralized Exchange

1) Overview: In this subsection we describe how our

approach works on the pervasive level. The basic idea is

that we do not have globally defined processes, because this

assumption usually does not hold in emergency scenarios,

where it is not exactly known in advance with which other

people one will work and what activities will be executed.

People exchange process information ad-hoc on a person­

to-person basis (e.g. based on personal work-related and

private contacts ) and integrate them in their own processes.

We describe a protocol for this exchange based on current

practices in emergency management in the next paragraph.

379

1)

2)

3)

--------------Transport Sandbags

" .

---------­Build Dam

" .

.Execute ______ ....... Elte<;1.lte .

� -------------­

Transport Sandbags

, •

.Eltec:l.lte_ - - - --

Fini�

Transport Sandbags

Build Dam

" .

Build Dam

_____ �EI(lKute

Figure 5. Example for executing activities

-I Plan

Afterwards, we give an example for this exchange and

describe challenges associated with it. 2) Protocol: In this section we describe how actIvI­

ties and dependencies can be exchanged between different

shared workspaces. Each exchange follows the following

steps:

1) Participant p of shared activity workspace X sends se­

lected activities Ai and dependencies Di to participant

m of another shared activity workspace Y 2) Participant m receives the activities Ai and the depen­

dencies Di 3) Participant m decides which activities ASi � Ai and

dependencies DSi � Di he/she wants to add to the

shared activity workspace and adds them to the shared

activity workspace

The exchange does not have an effect on the execution

of activities. Violated dependencies are managed locally

in each shared activity workspace. Different dependencies

can be established to the exchanged activities and not all

dependencies might be exchanged. State changes of an

already exchanged activity are propagated in the same way. 3) Example: Figure 6 provides an example for exchang­

ing activities and dependencies between different shared

activity workspaces. Activities are represented as circles

and dependencies as lines between circles due to space

reasons. In this example the police exchanges activities and

Exchange 1) ,------;;;-S ha-red-:-:Acc:cti.-::-o 'y----.

Wor1<space(Police)

• • • • • .. �

Update (Change State) 2) �redAd� �fedActlvity

I Wor1c.space (Police) II" - '" IJVQrkspace (Fire Fighter)

"'%! " • •

I • I ",.: I L · �

Figure 6. Example for exchange of activities and dependencies

dependencies with the fire fighter in step 1. The fire fighters

integrate them in their shared activity workspace and create

new dependencies to their own activities in step 2 and

exchange state updates with the police.

4) Challenges: We identified several challenges with this

decentralized exchange:

• Group/people awareness: People may enter and leave

one or more groups (i.e. shared activity workspaces)

working on a specific set of activities (e.g. police is

interested activities related to evacuation). Other peo­

ple/groups needs to be aware of this, because they may

exchange activities, dependencies and state changes

with them (e.g. fire fighter needs to be aware that

protection of the area is related to warning of the people

in this area).

• Change propagation: Activities can change their state

and this needs to be propagated to all people/groups

who have received a copy of the activity from other

people (e.g. police need to know when protection of the

area fails to execute the activities related to evacuation).

These problems also occur currently in emergency responses

without any sophisticated IT support. The problems are of

pervasive nature and are also relevant in other domains, such

as business networks with ad-hoc activities. Both challenges

are related to the architecture of our pervasive system.

In the area of group/member awareness there is a research

need on publishing/querying group/member and activity

information in a decentralized scenario. In an emergency

scenario this is done via personal exchange (e.g. the fire

fighters talk with the police men in the field and they

may refer to the military, which is interested in the same

activities). This problem can be also found in other domains,

such as large scale software projects [6]. In these domains

they use a centralized approach for managing awareness (e.g.

mailing lists), which is not applicable in our decentralized

scenario. We investigate how we can leverage current prac­

tices of personal exchange in emergency management to

380

publish/query awareness information.

In the area of change propagation we are working on a

protocol for propagating changes of activity states, which

is based on existing work in state machine replication to

different distributed systems (e.g. [7]). This work has to be

extended, because it does not cover state conflicts, where

it is only known somewhere in the future which state is

the correct one. This can happen, for example, in situations

where there is unreliable communication or re-occurring

disastrous events (e.g. multiple earthquakes in short time).

In these cases different persons might have a different view

on the current process (i.e. what the state of activities is).

It should be ensured that at some point in the future these

faults or state conflicts can be resolved.

We are currently investigating how we can leverage the

eXtended Messaging and Presence Protocol (XMPP) [8] as

the foundation for our architecture. It supports our scenario

of decentralized personal exchange and is approved by

the Internet Engineering Task Force (IETF) as a standard

for instant messaging. We plan to implement an extension

for group activity awareness. This requires definition of

groups across different servers and mechanisms for pub­

lishing and querying activity information (e.g. who else is

interested/could be interested in an activity or where are

violations when executing activities). Another extension will

deal with cross-organizational change propagation, which

relies on the previous extension, because changes have to

be propagated to the right people/group. XMPP has been

applied to an emergency response scenario [9], but without

considering the challenges of cross-organizational process

management. Finally, we plan to investigate the scalability

of our approach together with our end users in different

emergency exercises.

V. RELATED WORK

We describe in this paper the technical concept for

pervasive emergency processes based on the sophisticated

research and model in [2]. Several work has been done in

the area of standardizing messages for creating a common

operational picture (e.g. [iO]). We are investigating other

problems in a highly decentralized scenario: (1) how can

one be aware of the interested receiver(s)/groups of ac­

tivities and dependencies and vice versa (2) how can we

correctly update the exchanged activity information stored

at different sides with unreliable communication. We aim at

reusing these standardized message formats for describing

exchanged activities and dependencies. Related work can

also be found in the area of flexible business process

management systems (BPMS) (e.g. [11], [12], [13]). These

systems address operational business processes [14] and not

emergency response processes, which have different require­

ments. For example, in emergencies we have dependencies

between activity states and not information and sequential

dependencies between activities like in operational business

processes. This can be modeled only very difficult using

operational business process models and leads to much more

complex models as our end user interviews have shown

[2]. These approaches do not provide support for cross­

organizational aspects. Our approach cannot replace BPMS

and can be seen as complementary to them, because our

point of view are cross-organizational ad-hoc activities in

critical domains, such as emergency response management.

For example, our approach works not very well for highly

standardized repetitive administrative processes. We find

also related work in the area of cross-organizational and

pervasive workflow systems (e.g. [15], [16], [17]). They

require that the organizations, which are involved in the

inter-organizational process, share and accept a common

fixed public business process model, which is not the case

in emergency management as our end user interviews have

shown. Contrary, in our approach, we exchange activities

and dependencies ad-hoc and do not require a centrally

defined fixed process. The process system developed in the

European WORKPAD project [18] describes an emergency

process management system. It does not deal with cross­

organizational process challenges described here.

VI. CONCLUSION

We propose a pervasive emergency process management

system based on a process modeling and execution approach

that takes into account the requirements of pervasive emer­

gency response processes. Activities can be monitored using

different visualizations, e.g. on a time line or on a map.

Our process approach is complementary to existing business

process approaches and aims at ad hoc cross-organizational

activities in dynamic domains, such as emergency manage­

ment. It is based on an activity and human/social centric

view on the crisis, which can be extended by further

situational information (e.g. resources, positions etc.). We

implemented the system, but the exchange mechanisms

are subject to further research. Two challenges have been

identified and discussed: Awareness of dynamic groups

interested in activities and propagation of changed activity

information. An open issue is the scalability of our approach

from an organizational and technical point of view. We plan

to investigate this during crisis exercises with our end users.

ACKNOWLEDGMENT

The research was partially funded by the German Federal

Ministry of Education and Research under the promotional

reference OlIS07009. Another part was funded by the

French Agence Nationale de la Recherche (CIFRE). The

authors take the responsibility for the content.

REFERENCES

[1] T. Wachtendorf, "Interaction between canadian and american governmental and non-governmental organizations during the red river flood of 1997," Disaster Research Center, University of Delaware, Tech. Rep., 2000.

381

[2] J. Franke and F. Charoy, "Design of a collaborative disaster response process management system," in 9th International Conference on the Design of Cooperative Systems, 2010.

[3] K. Weick, Making Sense of the Organization. Blackwell, 2000.

[4] Soknos project, http://www.soknos.de. retrieved 03.06.2009.

[5] J. F. Allen, "Maintaining knowledge about temporal inter­vals," Communications of the ACM, vol. 26, no. 11, pp. 832-843, 1983.

[6] C. Gutwin, R. Penner, and K. Schneider, "Goup awareness in distributed software development," in ACM Conference on Computer Supported Cooperative Work, 2004.

[7] A. Doudou, R. Guerraroui, and B. Garbinato, "Abstractions for devising byzantine-resilient state machine replication," in 19th IEEE Symposium on Reliable Distributed Systems (SRDS'OO), 2000.

[8] "Xmpp standards foundation, http://xmpp.org!, retrieved 20.09.2009."

[9] "The capital wireless integrated network (capwin), http://www.jabber.comlmedia/JabbecInc._CapWIN_Case_ Study.pdf, retrieved 20.09.2009."

[10] F. Henriques and D. Rego, "Oasis tactical situation object: A route to interoperability," in 26th ACM Conference on Design of Communication, 2008.

[11] W. van der Aalst, P. Barthelmess, C. Ellis, and J. Wainer, "Proclets: A framework for lightweight interacting workflow processes," International Journal of Cooperative Information Systems, vol. 10, no. 4, pp. 443-481, 2001.

[12] W. van der Aalst and M. Pesic, "Decserflow: Towards a truly declarative service flow language," in Web Services and Formal Methods, 2006.

[13] P. Dadam and M. Reichert, "The adept project," Computer Science - Research and Development, vol. 23, no. 2, pp. 81-97,2009.

[14] M. Dumas, W. M. P. van der Aalst, and A. H. ter Hofst­ede, Process-Aware Information Systems. Wiley, 2005, ch. Introduction, pp. 3-21.

[15] W. van der Aalst, "Process-oriented architectures for elec­tronic commerce and interorganizational workflow," Informa­tion Systems, vol. 24, no. 8, pp. 639-671, 1999.

[16] I. Chebbi, S. Dustdar, and S. Tata, "The view-based approach to dynamic inter-organizational workflow cooperation;' Data & Knowledge Engineering, vol. 56, pp. 139-173,2006.

[17] F. Montagut and R. Molva, "Enabling pervasive execution of workflows," in 1st IEEE International Conference on Collaborative Computing (CollaborateCom), 2005.

[18] T. Catarci, M. de Leoni, A. Marrela, M. Mecella, G. Vet­ere, B. Salvatore, S. Dustdar, L. Juszczyk, A. Manzoor, and H. Truong, "Pervasive and peer-to-peer software envi­ronments for supporting disaster responses;' IEEE Internet Computing, vol. 12, no. 1, pp. 26-37, 2008.