Logical description of a disaster management system - at high-level

Disclaimer : Initial only and subject to peer review

Logical description involves :● Overview● Nodes● Entities● Events● Messages● Locations● Phases – test, runtime (initial, middle, end)

Overview

Less of human control and command. More of distributed centers.

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

Basic approach

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.

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.

Nodes

E.g. during an emergency, a cell phone can only dial the numbers 0-9 . Too much unregistered peer-to-peer noise is curtailed..

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

A different view of nodes (mix of logical and physical)

Any local DM center needs to do inventory and preparedness checks along these lines.

Transportation providers Medical stores

Human controllers Equipment stores

Vehicles Taped voice

Odd vehicles Real voice

? ? ? ?

Bandwidth providers Data store

Security providers Logic store

Cell bandwidth Single button

Secure wireless Short text

Medical providers Workflow store Public broadcasts Pictures

Agencies ContentTransportsStores

Entities

Entities need to get commonalized and grouped. Local data gather is needed before any fine-grained design.

The entities are randomly listed as below. The root entity is “Scenario”, whose current state drives most other things.

● Scenario● Zone● Epicenter● Victim● Perpetrator● Shelter● Aftermath● Aftershock● ●

●

●

●

●

● Role● Priority● Approval● Department● Team● Action● Message● Summary● Question● Answer● ●

●

●

● URL● Task● Message● Event● Workflow● Rule● Exception● Rollback●

●

●

●

●

●

● Hospital● ReliefCamp● Volunteer● Doctor● Nurse● BloodBank● Police● Fire● MedSuppy● FuelDepot● PowerStation● Driver● Crane●

Events

Events are to be locally designed. Esoteric unlikely events deaden the system.

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 - Arrivals- Departures

Messages

Information architecture is the basis of information processing.

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 peer-to-peer.

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.

Locations

Disaster managemnt systems are probably best designed by a combination team of local people and military experts...

Locational information and good routing logic can save minutes.

Locations are “determined” via cell location or GIS or human information.

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.

TBD

Ideas are nothing. Implementation is everything.

Create scenario descriptionsStart on KISS basisSimulated test descriptionsArchitecture work and reviewsDesign work and reviewsPilot implementationsFinal implementationsContracts with providersAllocation of capacitiesData collection and periodic updatesField trialsPeriodic dry runs

Thanks

Ideas are nothing. Implementation is everything.

Made by : Kinshuk Adhikary http://me-plumber.blogspot.comwww.sentimap.com