Logical description of a disaster management
system - at high-level
Logical description involves :
● Phases – test, runtime (initial, middle, end)
Disclaimer : Initial only and subject to peer review
The system is intended to :
- respond to a “scenario”, by
- propagating structured messages
- in response to events
- to the correct entities
- at the correct locations
- using the relevant nodes
- minimizing confusion (noise)
- with role-based manual overrides.
The system uses commonly available electronic infrastructure, like :
- cellphone networks
- SMS/MMS/Voice and in-built cameras
- police and fire wireless systems
- radio taxis
- locational systems
Less of human control and command. More of distributed centers.
All Indian systems fail because they are top driven.
A Brit time hangover. Or a “joint-family” hangover.
Surivival and disaster management are local issues – but need a
command-and-control guidance which can be highly machine driven
Creating “procedural manuals” and “pages to read” in this day and age is
just too nutty. It is asiinine. No one reads anything anymore.
Guidance is electronic. Logic can be “served” over networks just like
data. For a demo see http://www.sentimap.com/Thumbmetrics/
During an emergency, cell phones with abilities to send clear video
footage (some of my friends have made nice ones) – and a complete or
partial takeover of the cell providers bandwidth and normal operations,
can be a great asset.
It is so easy to build good modern systems. All it needs is money and two
domain experts and five good software experts ! Just 5. Not 10000.
The following nodes may be requisitioned :
- local DM center server (if any)
- police and fire department servers
- cellphone provider servers
- FM and radio broadcast servers (maybe TV)
- client devices – cellphones, wireless, radio
During an emergency, the following progressive events may result in
increased acqusition and control over the nodes :
- the first unqualified alert
- identification of epicenter and locational zones
- tracking of resources and team aggregations
- tracking of resource movements and additional requisitions
- blanketing of noise messages in affected areas
- other workflows driven from top or bottom
E.g. during an emergency, a cell phone can only dial the numbers 0-9 .
Too much unregistered peer-to-peer noise is curtailed..
A different view of nodes (mix of logical and physical)
Agencies Stores Transports Content
Bandwidth providers Data store Cell bandwidth Single button
Security providers Logic store Secure wireless Short text
Medical providers Workflow store Public broadcasts Pictures
Transportation providers Medical stores Vehicles Taped voice
Human controllers Equipment stores Odd vehicles Real voice
? ? ? ?
Any local DM center needs to do inventory and preparedness checks
along these lines.
The entities are randomly listed as below. The root entity is
“Scenario”, whose current state drives most other things.
● Scenario ● Hospital ● URL
● Zone ● ReliefCamp ● Task
● Epicenter ● Volunteer ● Message
● Victim ● Doctor ● Event
● Perpetrator ● Nurse ● Workflow
● Shelter ● BloodBank ● Rule
● Aftermath ● Police ● Exception
● Aftershock ● Fire ● Rollback
● ● MedSuppy ●
● ● FuelDepot ●
● ● PowerStation ●
● ● Driver ●
● ● Crane ●
● ● ●
Entities need to get commonalized and grouped. Local data
gather is needed before any fine-grained design.
Events - drive the transitions - that ultimately result in a
change in state of the system, other events etc.
Some key events are :
- The very first cry for help
- Recognition of scenario
- Recognition of zone and epicenter
- Message send completion to resource entities
- Acknowledgement receipt for action messages
- Takeover and requisition of a transport provider
- Noise threshold exceed
- Count threshold exceed
- Non-event occurrence for expectedEvents
- Human override request
- Human override
Events are to be locally designed. Esoteric unlikely events deaden the system.
Messages are usually pushed to a Recipient. Or received by a Subscription to
a Channel. e.g. any victim is a channel to whom a relief person can subscribe
to. Some key personnel/bradcasters are also channels. Some messages are
They are of several types :
- Informational point-to-point
- Informational broadcasts
- Action requests with optional acknowledgement
- Action requests with mandatory acknowledgement
- Subscription requests to a Channel
- Minimal “I am here” type of single-key messages
A human recipient has a MAX number of each message type, to prevent
information overload. Design objective is to maximize machine messages and
derive summarizations before human delivery
The <more> link can be a part of some messages.
Information architecture is the basis of information processing.
Locational information and good routing logic can save minutes.
Locations are “determined” via cell location or GIS or human
Zones can be several types – not just one or multiple epicenters,
but also zones of supplies, relief etc.
For disasters in congested areas, any non-congested area and
the route thereto is determined from the logic store.
The “logic store” and the “data store” are key to many things.
People should not have to think, that is the idea.
Disaster managemnt systems are probably best designed by a
combination team of local people and military experts...
Create scenario descriptions
Start on KISS basis
Simulated test descriptions
Architecture work and reviews
Design work and reviews
Contracts with providers
Allocation of capacities
Data collection and periodic updates
Periodic dry runs
Ideas are nothing. Implementation is everything.
Made by : Kinshuk Adhikary
Ideas are nothing. Implementation is everything.