Design challenges for an integrated disaster management communication and information system, A Meissner, T Luckenbach, T Risse, T Kirste

Tags: communication, disaster management, information flow, data management, requirements, applications, resource scheduling, Germany, site command posts, mobile devices, vital parameters, communications, hot spot, information system, data transmission, Government Authority WAN, mobile command posts, service information, medical devices, storage devices, the hot spot, body area network, fire department, dynamic network, IEEE 802.11 WLAN, local positioning system, Personal Area Network, voice communications, HQ, Sources of information, Command post, hierarchy levels, Communication Architecture, squad leader, wireless LAN, Firefighters, government authorities, System Architecture, squad leaders, Institute for Open Communication Systems, Information Systems Institute, scarce resource, Thomas Risse, Thomas Kirste, Integrated Disaster Management Communication, Global Task, National Digital Government Research Conference, Task Identification, task scheduling, task forces, Mobile Task Force, resource management, personal situation, integrated communication, Disaster response, local area network, geographic information systems, personal area networks, wireless personal area networks, network configuration, area networks, Holger Kirchner, Integrated Publication, Thomas Luckenbach, Institute for Computer Graphics, public emergency services, Fraunhofer, information management, global positioning system
Content: Design Challenges for an Integrated Disaster Management Communication and Information System Andreas Meissner 1, Thomas Luckenbach 2, Thomas Risse 1, Thomas Kirste 3, Holger Kirchner 1 {meissner, risse, hkirch}@ipsi.fhg.de, [email protected], [email protected] 1 Fraunhofer IPSI - Integrated Publication and Information Systems Institute, Darmstadt, Germany 2 Fraunhofer FOKUS - Institute for Open communication systems, Berlin, Germany 3 Fraunhofer IGD - Institute for Computer Graphics, Rostock, Germany
Abstract. Disaster response and recovery efforts require timely interaction and coordination of public emergency services in order to save lives anD Property. Today, IT is used in this field only to a limited extent, but there is a tremendous potential for increasing efficiency and effectiveness in coping with a disaster. In this paper we sketch requirements and innovative technology for an integrated disaster management communication and information system, addressing in particular network, configuration, scheduling and data management issues during the response and recovery phases. 1 Introduction Natural and man-made disasters, such as earthquakes, floods, plane crashes, high-rise building collapses, or major nuclear facility malfunctions, pose an ever-present challenge to public emergency services. In order to cope with such disasters in a fast and highly coordinated manner, the optimal provision of information concerning the situation is an essential pre-requisite. Police, fire departments, public health, civil defense and other organizations have to react not only efficiently and individually, but also in a coordinated manner. This results in the need for both intra and inter organization coordination at several hierarchy levels [1]. Since coordination requires current information, and such information must be communicated upstream and downstream within and between organizations in real-time, the need arises for an integrated communication and information system for disaster management that provides efficient, reliable and secure exchange and processing of relevant information. In this paper, responding to a call of the German federal government, we identify central design issues and architectural concepts for an integrated disaster management system, providing an infrastructure that allows for horizontal and vertical information flow from the officer or fireman on the scene up to the central operations staff by means of a multi-level wireless voice and data communication infrastructure, as well as integrated applications that reflect the currently selected organizational structure adequate to the rescue effort. At all levels, we must provide for recording and analysis of the current situation, semi-automatic data aggregation and de-aggregation, resource scheduling, and access to services and databases.
Networks include terrestrial trunked radio (as envisaged for the European public safety sector) or satellite technology for wide area communication, wireless LAN adhoc networks for disaster site hot spots, and personal or body area networks for frontline personnel, allowing them to act as data sources and sinks by means of smart connected devices, e.g. robust mobile terminals and sensors. Applications are to be designed around a flexible information and work flow concept based on templates for fast adaptation to modifications of the organizational structure due to situation changes. Distributed, redundant, and mobility adequate databases provide for information access even in unreliable or low bandwidth environments through pre-fetching and caching; service discovery and auto-configuration schemes reduce the need for manual administration in hectic situations. GIS and cooperative command environments aid operations staff in their facilities or vehicles. We devise "information environment portability" for added flexibility and mobile operations. While the focus of this paper is on disaster response (as defined by FEMA, the US Federal Emergency Management Agency [5]) and recovery, adequate preparation before a disaster strikes is vital. Selected topics to address in the pre-disaster phase include setting up simulations (such as evacuations of buildings) to be run with current data should a disaster strike, and identifying and linking data resources for seamless access during an emergency. In the most critical phase of a disaster (i.e. shortly before and while it happens) actions necessary for minimizing damage or saving lives should be performed, to the extent possible, automatically, e.g. closing safety valves, controlled power down of electrical systems, automatic opening or closing of emergency doors etc. Moreover, an integrated disaster management system must be able to provide relevant data for a post-disaster lessons learned analysis and for training purposes. The structure of this paper is as follows: Following this introduction, we analyze user requirements and give, in section 3, an architecture outline. Section 4 addresses applications and information flow. Section 5 describes in our vision for wide, local, personal, and body area networks, and section 6 discusses service configuration. Sections 7 and 8 address data management and resource scheduling, respectively. Section 9 concludes this paper.
The First IEEE Workshop on Disaster Recovery Networks (DIREN 2002), June 24, 2002, New York City, co-located with IEEE INFOCOM 2002.
2 User Requirements Analysis Fraunhofer Gesellschaft conducted a study on disaster and emergency management systems [11], asking experts in the field what technology they currently used and what they missed. Apart from communication and information management, the following areas were addressed: optimization and simulation, decision support, visualization, geographic information systems (GIS), and simulation and training. One of the findings is that, in the polled experts' opinion, maintaining communications is the "primary challenge" during a disaster. Commenting on the state of the art in communications and information management, experts stated that the following major requirements were not yet met in a satisfactory way: ·= Integration and linkage of information ·= Availability of communication, redundancy of links ·= Fast data access ·= Timeliness and updating of information ·= Standardization of information Extending the scope of the study from Germany to the United States, the impact of the 9/11 events on the priorities in disaster management was determined. Before the terrorist attacks, flooding, fire, earthquake and hazardous material accidents were considered to have "high priority", with a technological focus on local and mobile communication centers, simulation and training, whereas after 9/11, anti-terror efforts were assigned "maximum priority", adding cyber security, authentification, image processing, sensors, logistics, Knowledge Management, and training to the technological focus areas [11]. Additionally, we polled fire departments for this design study. We refer to MESA [10] for requirements and activities in the area of mobile communication standardization.
3 System Architecture Figure 1 shows a high-level view of the proposed communication architecture. Police, fire department and other services' headquarter (HQ) buildings are connected with each other and with government authorities, e.g. the state governor, by terrestrial and/or satellite networks. Likewise, when disaster site command posts are established, they are connected by terrestrial wireless or satellite links to the respective HQ. For "hot spot" on-site communications, a wireless LAN (infrastructure, ad hoc, or both) is set up. Firefighters and other personnel may be equipped with personal or body area networks, providing connectivity for sensors and terminal displays. The approach taken in [9] is similar, emphasizing rapid "last mile" deployment, lacking however the last "yard". The information flow of applications can be both horizontal, i.e. between peer entities, and vertical, i.e. along an organization's hierarchy and beyond; both push and pull information propagation are to be supported. 4 Applications and Information Flow In this section, we take a bottom-up approach and first describe how frontline personnel like firefighters or other rescue workers operating in difficult terrain may benefit from the envisaged system. Firefighters' equipment often includes sensors and detectors, e.g. for radiation or explosive gases. The readings are traditionally transmitted by voice communications to squad leaders. More immediate and reliable data transmission can be accomplished using smart sensors linked, via networks, to a computer in the squad leader's vehicle, where they are instantly analyzed and put in context. In some cases, data may be coupled to the location of the measurement using port-
Government Authority
WAN
Police Command Post
Hotspot WLAN
Information Flow Network Link Network Coverage
WAN Fire Command Post
Personal Area Network
Police HQ
Fire HQ
Disaster Site Hotspot
Fig. 1: Communication Architecture Sketch
Body Area Network
Body Area Network
able GPS receivers, so that, for example, danger zones can be determined more precisely. Moreover, the vital parameters of firefighters and the remaining amount of pressurized air can be continuously transmitted for monitoring purposes [10]. Thus firefighters are data sources in our system, but they are also data sinks: Messages, hazardous material warnings, maps, and data on missing persons may be transmitted to the robust mobile devices they are equipped with. Of course, offline operation capability is a must in difficult communication environments. In order to cope with a disaster, all organizations involved in the rescue effort need to interact closely at various levels. These hierarchy levels correspond to aggregation levels at which gathered data is analyzed, put in context, and transformed in reports (upstream) and instructions (downstream). At the same time, decisions often have to be taken in an ad hoc manner, which requires efficient access to information supporting such decisions, or, in some cases, an online "help desk". Thus, from squad leaders upward, our proposed applications allow collected data to be correlated with other information, to be aggregated or de-aggregated, and to be exchanged with others according to an information flow model deemed appropriate for the situation. Likewise, a workflow system that, by using templates and taking into account the involved organizations and the number of hierarchy levels, easily adapts to changing organizational structures, facilitates collaborative work within and across services. Staff in headquarters often have to perform a scheduling and coordination job, and they act as an interface to other agencies and to the public, so they are, due to their physical distance to the disaster site, particularly dependent on up-to-date information inflow. On the other hand, HQs usually have vast amounts of stored data, e.g. on hazardous materials, which may need to be accessed by on-site personnel. This calls for integrated applications building on wide area data links between the HQs and site command posts. If a disaster spreads, even HQs may need to be relocated, or operations directors may decide to move closer to the scene, so it is vital to provide a "portable information environment" ready for relocation. This places additional requirements on databases and cooperative environments provided for HQs. 5 communication networks In this section, we address wide area communications and local communication within a disaster site. If there are large or multiple separate disaster areas, the WAN also acts as a backbone linking several site hot spots. 5.1 Wide Area Communications Even in some heavily industrialized countries, such as Germany, the public safety sector still uses analog voice-
only radio systems that provide only a single broadcasttype channel per organization and region. Thus, radio data transmission is almost impossible today, and, due to the lack of prioritization or group call schemes, overload and "chaos in the air" make communication difficult and unreliable during major full-alert emergency situations. The use of commercial wireless telephone networks has often been proposed, but is viewed critical because these networks are beyond the organizations' control and tend to collapse during disasters due to overwhelming demand from private users, or due to infrastructure damage. Such networks are thus only acceptable for nonessential applications or as a backup for dedicated public safety systems. European countries are now in the final decision phase for the adoption of terrestrial trunked radio digital voice and data networks following the TETRAPOL or ETSI TETRA 25 standards operating at 380-400 MHz [12]. For the purpose of this paper, we do not need to distinguish between these competing systems, and we propose to use either of them as a WAN communication basis for our envisaged disaster response system. It will thus, for example, capitalize on TETRA's group call, prioritization, and encryption capabilities. However, due to the limited bandwidth (< 28.8kbps), data management has to be carefully designed. Satellites are a robust alternative particularly for high bandwidth applications, but (at least for two-way communications) their enormous costs discourage widespread use. Command post vehicles act as gateways between the WAN and hot spot site networks. 5.2 Hot Spot Communications Hot spot communication in disaster areas refers at least to two different types of locations which can be categorized into critical and communicative areas as follows: Most critical areas: these are the central places of danger and the focal points for stopping or controlling major parts of a disaster. Especially in these most critical areas frontline personnel involved in fighting against the disaster need to concentrate as much as possible on the source of the disaster and are obviously in the most dangerous and critical situation. Therefore they need to be informed immediately and without any delay in case the situation escalates and either environmental parameters approach critical thresholds or person-specific vital parameters become critical. Additionally they need to stay in contact with a supervisor team providing information gathered from sources not directly available to the frontline personnel. In any case all information has to be provided to these people without requiring them to manually interact with any kind of device. Information has to be provided automatically and partly speech-controlled via suitable display technologies, loudspeakers and other indicators.
Most communicative areas: these are the places where information from all relevant different sources have to be available, analyzed, combined or, in a general term, processed immediately. Sources of information might be static like local computer systems or measurement equipment, semi-dynamic like information received via connection based networks (telephone, Internet), or dynamic like mobile devices (e.g. PDA based computing or storage devices) moving in and out of the communicative hot spot. In order to gather, combine and process the information from different sources, mechanisms for dynamic, partly wireless ad hoc networking have to be developed and implemented for the different devices and networking technologies. In order to cover the challenging requirements resulting from the hot spot communication scenarios described above, not only existing or upcoming technologies like Bluetooth, 433/868MHz RF technology, or IEEE 802.11 WLAN should be used in order to set up wireless body/personal/local area networks, but also ongoing work like the IEEE 802.15 activities for wireless personal area networks (WPAN) and the IETF activities in the area of mobile ad hoc (MANET) networking should be considered, as well as e.g. the current work within ETSI on the development of wireless medical devices. Special emphasis should be given to the development and provision of a seamless networking infrastructure allowing to exchange information between body area networks (< 7ft), personal area networks within the direct environment of a person (< 30ft), and a local area network likely to operate in an ad hoc mode and being connected via gateways to "the rest of the world". Unfortunately there are currently two different regulations concerning the frequencies to be used for medical body area networks in the US and in Europe. An important aspect of the hot spot communication in the most critical areas will be the integration of the different networks and devices (including Sensor Networks) with each other and with position/location information derived either from a local positioning system to be installed ad hoc in the hot spot or from a Global Positioning System (like GPS) with a sufficient level of exactness. 6 Service and Device Configuration We have so far argued that the proposed system has to be able to manage vast amounts of data at all levels. Exchanging data in real time between the right entities is a key challenge. The information flow must be controlled in such a way that during the disaster the system is robust and ready to be extended or (re-) configured easily. This section shows that these requirements call for autoand self-configuration of the devices and services in the network.
6.1 Motivation for Auto-configuration Without proper configuration of hosts in networks, they are not able to find each other, or to communicate with each other. Device configuration is therefore of utmost importance. This can be done either statically or dynamically. Devices that are permanently connected to an administered network are usually assigned static network configuration parameters by administrators [7]. Other devices that are attached to administered networks can use dynamic network configuration. The devices themselves must be configured, i.e. all the necessary parameters must be assigned to the host (device) by a network configuration service. The network configuration service in turn also requires configuration. However, in a communication and information system aimed at disaster recovery, manual administration of network hosts is impractical or impossible. Hence, automatic configuration of the hosts is desirable. 6.2 Communication Spheres As previously suggested, there are three kinds of actors in the system with regard to their degree of mobility: ·= Stationary actors: Police, fire, etc. HQs, government authorities, and even foreign authorities or organizations (in case of disasters affecting several countries) ·= Semi-mobile actors: mobile command posts. ·= Mobile actors: frontline personnel, e.g. firefighters. The communication can be seen as structured in a "network in network" hierarchy as well. The mobile actors may have several sensors communicating with a handheld device. In essence, together the gadgets form a small wearable network, or body area network. The communication to the nearest mobile actors can occur in a personal area network. As discussed in section 5, the disaster site is covered by a WLAN, operated by semi-mobile actors. These, in turn, communicate with stationary actors through a WAN. 6.3 Configuration of Devices One aspect of the configuration of mobile devices is addressing parameters. Data sinks as well as data sources must know (i.e. be configured) with whom to communicate. The device interface must be configured with a unique address. Duplicate address assignments must be detected, and message collisions must be managed. Typically, a mobile actor will operate (either manually or automatically) sensor devices, which gather different types of data. Some data, like the amount of explosive gases in the air, is relevant both for him personally, as well as for the command post. Other data, such as positioning information, may not be crucial for the mobile actor, but rather for his superiors at the command post.
Similarly, the mobile actor may want to access a mapping catalogue at his own and/or another command post. Or, he may want to obtain readouts of the vital parameters of a fellow mobile actor. This scenario repeats itself throughout the whole hierarchy depicted above. In essence, there will be a large number of services available offering different kinds of information or connection possibilities. 6.4 Discovery of Services The discovery of these services can be managed in various ways. At the top hierarchy layers (stationary and semi-mobile actors), the service information management can be regulated using a stationary service trader. Actors offering services can register them in the service trader, as well as poll it for available services. For the mobile actors, a dynamic process for starting and operating a (mobile) service trader is an option. To cope with the extremely dynamic situation, services listed in this mobile service trader have a significantly lower registration lifetime, in order to correctly depict the network state. Alternatively, if the number of mobile actors currently in contact is beneath a certain threshold value, no service trader would be assigned at all. In this case, service information can be managed and exchanged through the use of multicast. As sensor devices are turned on and off and different actors come in and out of reach of each other, the list of available services for each individual actor will most probably constantly be changing. This fact, in conjunction with the amount of diverse information services involved, suggests a system that dynamically and automatically configures itself. I.e. the devices must on a stand-alone basis find out which services are available, which other actor to send its readings to, present and describe its own services to other devices in the vicinity, and so on. As much as possible of the configuration and managing of services must be automated, in order to facilitate the tasks of the various actors. The goal is to always present the right data to the right actor at the right time with as little human intervention as possible. Moreover, an auto-configuration-enabled system can also manage the load on the network, e.g. through directing traffic to alternative command posts. In this manner, communication "bottlenecks" can be avoided, which otherwise could prove fatal if occurring at the wrong time. We will come back to this issue in sections 7 and 8. 7 Data Management As mentioned in the previous sections, distributed applications for disaster management have to deal with unreliable communication environments, low data transmission rates, and different processing and storage capa-
bilities of the devices used. Hence quality guaranties cannot be given for the communication. On the other hand, decisions in the command posts are based on information received from people working in the critical area. Vice versa, people in such areas act on instructions given by the headquarters. For both sides it is hence important to get complete information, as incomplete information delivery can result in wrong decisions or actions. Furthermore, decisions have to be taken quickly. This means that information and instructions have to be delivered fast. Thus, as outlined in the following subsection, the main challenges for data management in mobile and unreliable environments, especially in disaster situations, are reliability and performance. 7.1 Challenges Reliability means that the user always receives complete information of the highest possible timeliness. Incomplete information has to be detected and, if possible, must be requested again. Otherwise the application or user has to be notified about the transmission failure. In less critical situations it might be possible to reuse information from previous transmissions. The second important factor is the performance of the system. Beside the application, the response time of the system depends on the bandwidth of the communication channel. Hence low transmission rates make it difficult to deliver e.g. complex maps within a short time. The data management has to guarantee the efficient usage of the communication channels. Moreover, the response time of the system should be largely independent of the number of communication partners in the system. Furthermore the data structures used for data exchange must be flexible in different ways. Sensors can provide their data in proprietary formats. Hence they have to be transformed at some point to the standard data structure. This can be done at the receiving device or, if the device is not able to do this, the data has to be encapsulated into a standard message and transformed at some other point. In addition, the compatibility of different versions of data schemas has to be handled. Data schemas can change over time if new versions of an application are developed, but it is important that devices with different application versions be still able to communicate. 7.2 Suggested Approach To overcome the previously identified problem, XML [3] should be used as a standard data interchange format. XML documents can contain all required information ­ from simple messages to complex maps. Furthermore it is flexible in the handling of evolving data structures. A disadvantage of XML might be long tag names and white space, increasing the document size. But the intel-
ligent selection of tag names in the design phase and compression will reduce the document size significantly. The efficient usage of communication channels is based on a continuous and balanced transmission of data to avoid communication peaks. Hence intelligent caching, pre-fetching and selection of XML documents are the core technology for the implementation of mobile data management. Caching allows for effective usage of communication bandwidth by avoiding retransmission of mostly static information. Intelligent pre-fetching and selection strategies are used for timely delivery of complex location related information, e.g. maps of buildings. The reliability of the system is increased by redundant storage of XML documents on different devices (peers) [6]. Hence information has to be replicated in a peer-topeer manner among nearby devices. This decreases the probability of information loss in the case of a communication failure because other devices can be used as an "information router". Vice versa, in this way it is possible to avoid the loss of important sensor information. For the proposed technologies data integrity and timeliness of information are important. A distributed transaction management, which is adapted to the special needs in disaster management, ensures that instructions or technical descriptions are completely transmitted to the receiver. Notifications of incomplete transmissions are necessary. The caching strategy has to take the timeliness level of information into account, e.g. static maps have to be updated less frequently than instructions. 8 Scheduling Disaster Management Task Forces We now shift the focus from communications and data management to resource scheduling and discuss how IT may help use resources efficiently to "get the job done." 8.1 The Challenge While prevention, preparation, detection and assessment of a disaster usually take place in stationary environments, reaction on a disaster requires to a high degree the coordination of mobile task forces that are dispatched on location for disaster management. An important challenge is the efficient utilization of the deployed (personnel) resources with respect to the question, where and when which resource is assigned to what task. This is the problem of resource scheduling, the question of resource allocation with respect to the current tasks, their priorities, and their mutual dependencies. Here, it is also necessary to supervise the task forces' progress with their assignment (task progress monitoring), in order to be able to update the resource planning (resource re-allocation) if necessary. The challenges are: ·= The current situation on location is perceived directly only by the task forces themselves.
·= Task forces must be allowed to adapt the priorities of their assigned tasks to the current situation in order to allow for a fast reaction on unpredictable changes. ·= Several independent organizations provide task forces, whose abilities to act effectively are mutually dependent, and whose availability is changing. Efficient scheduling of disaster management task forces based on timely on-site data is important for avoiding the following typical Problems: ·= Idling of resources because of lacking assignments ·= Inadequate prioritization of a task force's activity because of lacking situation data at the task force or at the coordination center (due to missing local or global data, respectively) ·= Idling of resources because of a long-winded coordination process on-site (who will do what, when?) ·= Duplicate work (due to lack of coordination) The goal is to overcome these problems by supporting the resource management and coordination processes with suitable IT infrastructures. Such a system must: ·= ensure a task force member's ability to act autonomously by providing local scheduling capability ·= provide personalized schedules for task force members that are adapted to their individual situations, based on the coordination center's global strategy ·= support monitoring and logging of the activities of a task force member, dynamic adaptation of his personal schedule, and propagation to the operation center for integration into the global strategy ·= allow for perception and recording of situation facts and action requirements by the on-site task forces, and for propagation to the operation center 8.2 Towards a Mobile Task Force Coordination Infrastructure While the concept of an IT-based coordination of disaster management task forces itself is not new, previous approaches such as [4] do not adequately address all or some of the challenges discussed above. In Figure 2, we give a sketch for a system architecture, supporting both local and global scheduling, as well as local acquisition of situation facts. On the architectural level, a challenge is the distributed maintenance of the different data repositories for facts, tasks, and schedules. Besides a system architecture, we need suitably concrete and yet generally applicable models for describing disaster situations, tasks, and situation facts. These models are a prerequisite for enabling (semi-)automatic (i.e., computer based, or computer assisted) schedule planning. Finally, the challenge of the man-machine interface has to be addressed ­ after all, the attention of the task force should be focused on the current relief tasks at hand, not on the interaction with the personal task scheduler.
We note that scheduling functionality is not only an important mechanism for effectively deploying disaster management task forces, but also for efficiently using the available IT infrastructure. A schedule supports the predictive allocation and moving of resources ­ especially, the pre-fetching of information: As said before, wireless network bandwidth is a scarce resource, especially if many task forces concentrate in the same area. Here, a schedule-based predictive pre-fetching of information a task force member will need for his next assignments allows us to evenly distribute bandwidth requirements across time, thereby reducing the effects of bottlenecks and network failures. This is where service configuration, data management and scheduling inter-relate. Our work on situation-aware personal mobile assistance and personal task scheduling [2] [8] suggests that local scheduling approaches can be made useful for supporting the effective action of personnel in typical disaster management situations. However, a substantial challenge for the future will be the development of models and architectures that support a truly distributed approach to task force scheduling.
Mobile Task Force
Local Task Identification
Local Fact Repository
Local Task Repository
Fact Acquisition (Sensors, User Entry)
Execution Monitoring
Local Schedule Planning
Operation Center
Global Task Identification
Global Task Repository
Global Fact Repository
Global Schedule Planning
Wireless Link
Local Schedules
Global Schedules
Fig. 2: Decentralized scheduling architecture
9 Conclusion and research agenda In this paper, we identified challenges and sketched an integrated communication and information system for disaster response and recovery, addressing in particular networking, service and device configuration, data management, and resource scheduling. In order to implement the described system architecture, several IT research disciplines need to work together to provide an effective, yet easy-to-use system that helps emergency services cope with disasters. To name only a few, networking needs to provide robust communications at WAN, LAN, PAN, and BAN level, integrating heterogeneous networks to allow the rescue effort to
proceed smoothly, with little manual administration, even in the most difficult communication environments. Data management must to provide static and dynamic data where and when it is needed. Security is a foremost concern necessitating solutions for encryption, authentification, data integrity, and non-repudiation. Devices and user interfaces must be tailored to hostile environments and to users who are often not computer literate. Application and information flow designers must consider fast-changing working environments, and resource management is a challenge given the chaotic nature of disasters. We are addressing these challenges in our work. References [1] Auf der Heide, E. (1989). Disaster Response: Principles of Preparation and Coordination, Mosby, ISBN 0801603854. Online Book: http://coe-dmha.org/dr [2] Chаvez, E., Ide, R., Kirste, T. (1999). Interactive applications of personal situation aware assistants. Computers & Graphics, 23(6):903-915, 1999. [3] eXtensible Markup Language, http://www.w3.org/XML [4] Farley, J. A., Hecht, L. G. (1999). Open computing technologies as infrastructures for disaster management. In GDIN Conference, Mexico City, May 1999. [5] US Federal Emergency Management Agency, http://www.fema.gov/ [6] Gribble, S., Halvey, A., Ives, Z., Rodrig, M., Suiciu, D. (2001). What can Databases do for Peer-to-Peer?, Proc. WebDB (Databases on the Web), June 2001. [7] Guttman, E. (2001). Autoconfiguration for IP Networking: Enabling Local Communication, IEEE Internet Computing, May/June 2001. [8] Kirste, T. (2001). Situation-Aware Mobile Assistance. In Earnhsaw R., Guedj, R., van Dam, A., Vince, J. (eds.) Frontiers of Human-Centred Computing, Online Communities and virtual environments, Springer, 2001. [9] Midkiff, S. F., Bostian, C. W. (2001). Rapidly Deployable Broadband Wireless Communications for Emergency Management, National Digital Government Research Conference (dg. o 2001), May 21-23, 2001, Redondo Beach, CA, USA. [10] Mobile Broadband for Emergency and Safety Applications: MESA Project, http://www.projectmesa.org/ [11] Gemeinsame Studie "Marktanalyse Katastrophenund Notfallmanagementsysteme" (in German), Fraunhofer ITWM, IGD, CRCG, IITB, UMSICHT (eds.), Kaiserslautern, February 2002. [12] Saupp, H. (2002). The German Public Safety (BOS) timetable for implementing a digital radio communication network, http://www.pilotprojekt-digitalfunk-aachen.de/beitraege.htm#The

A Meissner, T Luckenbach, T Risse, T Kirste

File: design-challenges-for-an-integrated-disaster-management-communication.pdf
Title: Microsoft Word - DIREN2002_final.doc
Author: A Meissner, T Luckenbach, T Risse, T Kirste
Published: Fri May 3 16:45:27 2002
Pages: 7
File size: 0.22 Mb


, pages, 0 Mb

AdolfHitler, 6 pages, 0.52 Mb

Achilles and the Caucasus, 66 pages, 0.68 Mb

Art and knowledge, 10 pages, 0.19 Mb
Copyright © 2018 doc.uments.com