Project Plan

Project Name: Disaster Management Information System

Focus Area: Kanlaon Volcano
Version 1

Prepared By: Marc Steven D. Aguilar

Project Risk Management Plan Version Control
Version Date
Author
Change Description

Contents
PROJECT DESCRIPTION.................................................................................................................................. 1
OBJECTIVES ................................................................................................................................................ 1
ASSUMPTIONS ............................................................................................................................................ 2
RESOURCE AND BUDGET ............................................................................................................................... 2
DMIS FRAMEWORK..................................................................................................................................... 3
INTERACTION WITH THE CHARTER ..................................................................................................... 5
LOCAL COMMUNITY AND INDIVIDUAL USER EXAMPLE ........................................................................... 6
SCIENTIFIC AND EDUCATIONAL USER EXAMPLE .................................................................................... 7
PROJECT TIMELINE ....................................................................................................................................... 8
PROJECT PLAN APPROVALS ........................................................................................................................... 9

Project Plan

PROJECT DESCRIPTION
The development of Kanlaon Disaster Management Information System (DMIS) will provide
an effective monitoring and hazard-warning system that will generate timely and accurate
identification of the hazards and provide mechanisms to inform people so that they can take
action to mitigate the impact of the hazardous phenomena.

OBJECTIVES
Refer to Project Charter
Any truly effective disaster early warning system must include the following elements in
place and working in combination:
1. The primary delivery method for warning signals must be wireless (R/F), point to
multipoint.
It is imperative that the warning signals be sent and received in real time and over
systems that will be the most robust and most reliable during large scale disaster
events. Landlines (Public Switched Networks) do not have real time capacity or
robustness required for directed real time warnings to large numbers of users during
disasters. Internet related (Ethernet) systems are subject to overload, power
failures, and significant latency (delays) during disasters.
2. Receiving devices must be always capable of receiving early warning transmissions.
Receiving devices must always to receive a signal and initiate immediate mitigation
responses. R/F signal must have priority access over other transmissions with priority
overrides and/or short burst packets. Receivers must have battery power capability
during times of power interruptions.
3. The System must include a wide variety of receiving devices capable of generating
both human and automated responses.
Different disasters require different levels and types of responses. Some disasters
such as earthquakes have very short warning times requiring completely automated
responses between sensors, activators, and a hierarchy of controlling computers to
properly mitigate damages without human intervention. With quick twitch short
warning period disasters such as earthquakes, human responses need to be backed
up with pre-programmed responses from devices to act when human responses are
not available, reliable, or effective.
4. The System must perform real time data collection and pattern analysis for all
types of natural and manmade disasters to enable effective early warnings for all
potential threats.
This creates an All Hazard Warning capability and provides a single delivery source
to prevent duplication of hazard warning devices for users and standardized
responses for more effective human interface.

Version Number: 1.0

Issue Date: March 18, 2011

Project Plan

5. The System must eliminate false warnings.

Elimination of false warnings maximizes authenticity of warnings when
received. Effective warnings require those warned to have a high degree of certainty
that their life and/or property are in danger so that warnings are not ignored. When
warned, they respond. Warnings must be sent only to those users in actual danger
from a disaster event in progress.
6. The System must eliminate failed warnings.
Early warnings must always be given when needed. An effective early warning
system requires users to have a high degree of certainty that warnings will always be
issued when danger is present. This requires:
Real time knowledge of the magnitude, location, speed, and direction, of all
disaster events.
Real time knowledge of location information (long/lat) for all system users.
Every type of hazard must be analyzed.
Real time processing capability must be available to determine all users, and
only those users, in actual danger from a disaster event before impact to
users.

ASSUMPTIONS
Delivery Assumptions
Deliverables will be subject to no more than a specific number of review cycles.
Equipment order lead times are known and can be expected to be met.
Environmental Assumptions
No industrial action will be taken that will affect the project.
Issues will be resolved in a timely manner.
The project organization described in the project plan will be put in place.
Systems components will be capable of being integrated with minimum rework.
Budgetary Assumptions
The statistics used in preparing the estimates are accurate within a given percent.
No outside consulting will be required or Outside consulting will be limited to a
specified number of days at a specified rate per day.
Functionality Assumptions
The scope of the project is limited to that described in the project charter.
Formal charter and scope change procedures will be followed.

RESOURCE AND BUDGET

Refer to Project Resource Plan

Version Number: 1.0

Issue Date: March 18, 2011

Project Plan

DMIS FRAMEWORK
The DMIS framework outlines a system that will provide uniform storage and easy access to
Earth observation data and information. Such a system will provide uniform access to
services that allow the end-user to process this data, as well as advanced computing
facilities for creating useful information. The aim of the DMIS framework is not to develop
new computing, storing, or data providing facilities, but to integrate existing Earth
observation technologies, computing, and storage facilities in a uniform fashion.
Figure 1 presents a general overview of the architecture of DMIS. It is composed of three
different layers. The first layer is the interface layer and contains the interface tools that are
employed by end-users to interact with the system. These can be web-based tools on webenabled devices (e.g. desktops or mobile phones), GIS-based tools, broadcast tools for early
warning, or other specific tools to interface with governmental organizations.
The second layer is the access layer. It provides access to the services of the system and is
responsible for creating the content that is sent to the users through the interface tools.
This layer is composed of the content provider, the service provider, and the notification
server. The content provider creates the content requested by the user via an interface tool.
One of the important features of the system is that it is able to select different degrees of
detail and complexity of information, depending on the users needs and technical skills. It
allows many different users to access the information in a straightforward manner. For
instance, the crew of an aircraft only needs to know how ash plumes are moving in the
airspace and how they can avoid them. Scientists, on the other hand, require data that has
as much detail as possible to study volcanoes. The service provider implements the different
functionalities provided by the system. This component coordinates access to the resources
managed by the DMIS. The notification server is responsible for providing notifications to
users concerning specific set of events that are detected by the system.
The third layer is the processing layer and contains the external systems and architectures
that provide uniform input that is integrated into the overall DMIS framework. This layer
standardizes and unifies specific data formats and specific access procedures for other
systems. It is composed of the data provider, the knowledge provider, the storage
provider, and the computing provider. The data provider ensures uniform access to the
external systems that provide raw data. For example, the external data providers can
include organizations such as PHIVOLCS. The knowledge provider uses various mechanisms
to create information from the raw data. To do this, capabilities of other systems (e.g. the
NASA Distributed Active Archive Centers and the ESA Earth Observation Service) will be used
as well. These mechanisms can be specific tools, methods, or algorithms for data processing.
The computing provider and storage provider supply computing and storing facilities to the
system and end-users. Similar to the previous components, these providers unify access to
the infrastructures.

Version Number: 1.0

Issue Date: March 18, 2011

Project Plan

Figure 1: Architecture of DMIS

Version Number: 1.0

Issue Date: March 18, 2011

Project Plan

INTERACTION WITH THE CHARTER

One of the goals of a DMIS is to improve information flow between all the entities involved
when a volcanic event happens, including the Charter. The flow diagram in Figure 2 shows a
possible interaction between the Charter and the proposed DMIS. The system can act both
as a user of the Charter and as a knowledge provider. Once a volcanic event occurs, the
Charter can be activated in two different ways: by an Authorized User through the DMIS or
by a DMIS administrator that will act as an Authorized User. When the Charter is activated,
the DMIS will provide information to the on duty operator, the emergency on-call officer,
and the program manager, and will deliver value added information directly to the local
authorities and emergency crews on the ground.

Figure 2: Interaction between the Charter and DMIS

Version Number: 1.0

Issue Date: March 18, 2011

Project Plan

LOCAL COMMUNITY AND INDIVIDUAL USER EXAMPLE

A simple example of interaction between a VIDA system and a local community or individual
user is described in Figure 3. Information is provided to the local user at two different levels:
near-real-time information, and monitoring and forecast information.
The top of the diagram shows schematically the data acquisition, both from ground stations
and from space assets. The provided data are converted by the DMIS into an open source
standard; this is value added data. At this point the knowledge provider can interact with
the user at different levels.
The bottom left of the diagram shows the early warning alarm issued by the notification
provider of the DMIS. The early warning alarm can be communicated by SMS, e-mail, or RSS,
as well as through a web portal. The information has a defined scope to allow local
authorities to make an informed decision on how the local population should react given
the impending volcanic event.
On the bottom right, the DMIS knowledge provider interacts with the user by means of
different technologies (web-based, specific tool interfaces, etc.) and supplies information
useful to follow ongoing volcanic activity and anticipate possible hazards. The information
accessible is in the form of images and maps of the area of interest, as well as information
provided by other users of the system (e.g. the scientific community).

Figure 3: Interaction between DMIS and local community users

Version Number: 1.0

Issue Date: March 18, 2011

Project Plan

SCIENTIFIC AND EDUCATIONAL USER EXAMPLE

A DMIS will provide the scientific and educational communities with a set of different
services and tools, as shown in Figure 4. According to the defined framework, the scientific
community will interact with the DMIS in two different ways: as an end-user with access to
all the services and tools available, and as a data provider, introducing into the system data
that will be available to the whole scientific community. Different tools and services provide
the user with different types of information: near-real-time information, monitoring
information, and forecast information.
The DMIS will include a notification service to provide the scientific community in areas
surrounding volcanoes (e.g. volcano observatories) with an early warning alarm about a
detected hazard by means of SMS technology, e-mail, or RSS services. All the available data
related to this hazard will be automatically sent to them. They will also have access to a
communication tool with the identification of the relevant authorities. The scientific
community will have access to GIS and web-based tools to interact with other users sharing
data and knowledge, to visualize the data, and to conduct interactive experiments with
other scientists.

Figure 4: Interaction between DMIS and the scientific community

Version Number: 1.0

Issue Date: March 18, 2011

Project Plan

PROJECT TIMELINE

Version Number: 1.0

Issue Date: March 18, 2011

Project Plan

PROJECT PLAN APPROVALS

Prepared by Marc Steven D. Aguilar _________________________________
Project Manager
Approved by

Steve Lowrie
Project Sponsor

_________________________________

Version Number: 1.0

Issue Date: March 18, 2011