Disaster Guidance System
1 like277 views
The document provides a high-level logical description of a proposed disaster management system. It outlines several key components: nodes that could be requisitioned during an emergency, such as cellphone provider servers; entities involved, such as scenarios, zones, victims, and relief teams; events that could trigger changes, like recognizing the disaster scenario; different types of messages that could be sent; locations that need to be tracked; and phases of testing, initial deployment, and ongoing operations. The goal is to design a system that can automatically respond to disasters by coordinating responses across agencies and using existing electronic infrastructure to minimize human errors.
Disaster Guidance System
- 1. Logical description of a disaster management system - at high-level Logical description involves : ● Overview ● Nodes ● Entities ● Events ● Messages ● Locations ● Phases – test, runtime (initial, middle, end) Disclaimer : Initial only and subject to peer review
- 2. Overview 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.
- 3. Basic approach 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.
- 4. Nodes 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..
- 5. 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.
- 6. Entities The entities are randomly listed as below. The root entity is “Scenario”, whose current state drives most other things. ● Scenario ● Hospital ● URL ● Role ● Priority ● Zone ● ReliefCamp ● Task ● Approval ● Epicenter ● Volunteer ● Message ● Department ● Victim ● Doctor ● Event ● Team ● Perpetrator ● Nurse ● Workflow ● Action ● Shelter ● BloodBank ● Rule ● Message ● Aftermath ● Police ● Exception ● Summary ● Aftershock ● Fire ● Rollback ● Question ● ● MedSuppy ● ● Answer ● ● FuelDepot ● ● ● ● PowerStation ● ● ● ● Driver ● ● ● ● Crane ● ● ● ● ● Entities need to get commonalized and grouped. Local data gather is needed before any fine-grained design.
- 7. Events 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 Events are to be locally designed. Esoteric unlikely events deaden the system.
- 8. Messages 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. Information architecture is the basis of information processing.
- 9. Locations 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. Disaster managemnt systems are probably best designed by a combination team of local people and military experts...
- 10. TBD Create scenario descriptions Start on KISS basis Simulated test descriptions Architecture work and reviews Design work and reviews Pilot implementations Final implementations Contracts with providers Allocation of capacities Data collection and periodic updates Field trials Periodic dry runs Ideas are nothing. Implementation is everything.
- 11. Thanks Made by : Kinshuk Adhikary http://me-plumber.blogspot.com www.sentimap.com Ideas are nothing. Implementation is everything.