Design of a distributed disaster relief system
Katrina is big. Too big. By Katrina I don't mean the storm, but the overall situation. I feel like I did almost four years ago, unable to help or even understand much but realizing that our disaster services simply aren't up to the task. Sitting in California with sunny weather I wait, watch, and wonder what I can do.
Well, for starters, donate some money. Sun (my new employer) will match 100% anything I donate. I just got some money from a class action settlement against Allstate. I hate class action suits on principle and normally opt out of them but somehow still ended up on the list for this one and won some cash. So that's going out right away to the Red Cross. I'm also chipping in more money of my own to up it to 500$, which will equal 1k with Sun's matching. I'm also scheduling a blood donation appointment at Stanford. Still, I feel I must do more.
As I read (probably too much) about the chaos in New Orleans I think back to the time four years ago when we faced a similar problem. There was at least a functioning city around the twin towers, so that helped, but one thing that stuck out was the abundance of resources available, but in the wrong place, or the wrong kind of resources. Our top down system of disaster relief doesn't seem to be very dynamic. It can handle largescale disasters, especially unexpected ones like 9/11 or a Cat 5 hurricane that submerges an entire city. So what to do?
Well, since I've got time to fret, how about applying the one thing I'm good at, designing software, to the problem at hand. If I was going to design a disaster relief system, how would I do it?
Designing a Dynamic Disaster Relief System
Disaster relief in unexpected situations like this boils down to getting the right relief resources to the right place at the right time. By resources I mean food, temporary shelter, gas and power, communications systems, and most importantly educated people. Anything you would need to address a current need, but often a partially unknown need. This means the system must dynamically adjust to the circumstance, switching the kinds of supplies delivered, where they come from, and where they go too. As a software person this type of system should look very familiar: TCP/IP.
TCP/IP chops network traffic into discrete packets and routes them around to the desired destination, using the network resources on hand. If the network itself changes the packet traffic will adjust to the new demand. It is very resistant to damage in the network and has proven to be quite future proof. Something similar would be very useful in disaster relief.
It shouldn't be surprising that TCP/IP has such useful qualities, however, since it was originally designed to withstand a huge disaster like nuclear war. I think we could apply these same design ideas to a local disaster relief with a simple system I call Componentized Relief Trucks or CRTs. Here's what it would look like:
The Componentized Relief Truck or CRT
A basic CRT is a truck, larger than a pickup but smaller than tractor-trailer. Something that can be built out of a large commoditized SUV platform. This truck has a large container on it's back that serves as hotswappable unit of storage, supply, and any other necessary resources. Imagine the typical vending truck with hotdogs and icecream. That's what I'm imagining.
The container would be human usable space that can be filled up with both required and optional equipment:
Standard on all CRTs and always loaded:
- large tank of gasoline that can feed the engine, power the generator, or be used to resupply others. (not always kept full, though). Should be at least 100 gallons.
- gasoline generator
- basic medical supplies
- basic repair and construction tools (typical homedepot stuff)
- wifi basestation around the truck and sat/cell uplink
optional modules that can be installed and removed quickly (under 10min). Must use standard power supplies:
- a medical unit: refridgerated box can keep food and medical supplies cold along with dry medicine and basic medical equipment.
- a food supply unit: canned foods, dry goods, drinkable water, divided in to small groups for easy distribution.
- a lodging unit: a bunch of tents each w/ blankets and small kit of useful tools (hatchet, knife, firstaid kit, water purifier).
- a flood unit: a bunch of small inflatable motorized rafts capable of rescuing people and pets in flooded areas.
The container itself should be removable by a group of men (say 8) or with simple machinery like a winch (cranes aren't an option). The containers can be attached and modified by hand. Once emptied of their supplies the containers canb e used to construct a base camp with supplies and personel, and have the truck immediately drive somewhere else as needed (say back to safe areas, while holding refugees).
Distributed geographically and politically
Now here is the important part. These CRTs should be small, relatively cheap (the cost of a decent SUV plus the onboard supplies), highly mobile, and *widely distributed around the country*. We have a big country but not that big. You can drive anywhere in 72 hours if you have two drivers. (I've done it by myself in that time, so I know it's possible).
If all of your CRTs are in the same place then they risk being attacked, being blocked by physical obstacles, or simply being too far away. By distributing them around the country you ensure that there is always some relief nearby, no matter where the disaster occurs. Players of the classic game Civilization know this very well. Distribute your defending armies throughout your territory and move as needed via highspeed transport.
Another important detail of the CRTs is that they are politically and financially distributed as well. If there is a national secretary of CRTs then they risk having their budget cut, or being designed by a single vendor, or of running out of supplies quickly. These CRTs should be owned and staffed by the local municipalities and interested organizations. That will make the system fluid and dynamic. Orders may come from the top, but the supplies and support come from the bottom. Action on the ground is what matters.
Open Source it
Finally: make the system be open source and use existing standards. Meaning there is a standard but anyone can and should implement it. Indivdual vendors can design their own versions, either from scratch or by assembling standard pieces from other vendors, but the spec itself is open for all to see and use. Highschoolers could even build a vehicle as a class project. Anyone who would like to donate time and money could do so to their local CRT organization. (Perhaps in conjunction with the fire or police department.)
The CRT should use existing standards wherever possible. No custom solutions. Gasoline and 110 power are standard and cheap. Because of Walmart the shipping world has implemented a bunch of standard sizes for pallets, packaging, etc. Reuse these standard shapes and sizes wherever possible. This will make the CRTs cheaper to build and keep supplied by small groups.
We should encourage lots of groups to build/buy their own CRT. It should be a point of pride if a small city of 1000 people has their own CRT. Just as individuals take part in a volunteer firefighting force, learn CPR, and other public duty services, it should be a point of pride to train with and maintain your small piece of the CRT system.
CRT system would never replace dedicated organizations like the Red Cross or the National Guard, but they would certainly help in the short term by getting food and supplies to those who need it immediately, and be getting everyone else out of the area as soon as possible.
I'm not saying that this system is the solution to all disaster relief, but it would address the issue of getting the right resources to the right place at the right time. And it would allow people from around the country to have a direct and ongoing effect in the safety of not only those around them but of everyone else in the country.
A unified and distributed system of disaster relief makes sense to me on many levels. What do you think?
Posted September 2nd, 2005