System Architecture

The basic workflow for this system is like this:

1. In case of a disaster, groups of rescue workers / relief workers go into the disaster area. Each team carries a CrisisCommunicator.
2. A user of the CrisisCommunicator can see where they are, just like a GPS, and can see where others are also.
3. The user enters data on their device (for example, the road is down here). Interface works so that they have very few clicks to do this.
4. Data is saved as a record to the database on the user's machine.
5. The Database Sync daemon on their machine formulates the new record into an APRS message (as below), and puts the message into a transmit queue.
6. Another program (to be written) takes messages from the queue and transmits them across the network. This is not part of this challenge.
7. Another program (to be written) listens to the network, and writes down the messages it hears and puts them into a receive queue. (also not part of the challenge).
8. The Database Sync daemon monitors the receive queue, and inserts messages from it after validating (see the Database-Sync-Daemon page).

So the system is made of a few different components:

• Hardware Device (a micro computer with touchscreen, input devices, radio, etc, TBD)
• A "website-like" application, running in a server on localhost, displaying in a browser, and saving to a local database. This is the main part of the challenge.
• A Database Sync Daemon which ensures that new records are duplicated to the network, and records on the network are duplicated to the local DB. This is a bonus part of the challenge.
• A network interface program (APRS, already exists).

Database Schema

The following design is no way intended to be a complete design of the database. It is provided to be a reference to the developer.

Global ID Table

Disaster-wide Message ID (GID) | Internal ID | Has Response? | CSV of update GIDs

Why is this table necessary? Basically, each message that is entered onto a CrisisCommunicator is communicated to the others by radio broadcast (or whatever database synch method is finalized on). Therefore, it is necessary to have a unique message ID for every message across the whole disaster area. This is accomplished by giving each device it's own ID, and using that ID to generate disaster-wide unique IDs for each device.

"Has response" is a boolean, which enables other disaster response personnel to add information to a record.

Updates are broadcast as complete messages, but are stored as updates in the database.

Comments Table

Internal ID | CSV of Comments

Comments can be added by communications operators to any of the messages. This provides a kindof Facebook-like functionality, but it's meant for serious stuff, not trivial smileys. :)

Person

Internal ID | Person ID (pid) | Name | Age | Gender | .....

Depending on the situation, PIDs may be generated (similar to the disaster-wide message ID, GID), or may use government identifier numbers, if available.

User

Internal ID | pid | Role

Missing Persons Table

Internal ID | pid | source_camp | missing_since | ...

Refugees

Internal ID | pid | ...

Refugee Center

Internal ID | Center ID (cid) | Name | GPS Location | no_refugees | capacity | supplies_available_for

Center IDs Can be generated or named

Deceased

Internal ID | pid | time | ....

Supply

Internal ID | cid | Type of resource | Location | Description

Alerts

Internal ID | crid | Type | Location | Refugee Center | Description

Map specific tables

The software is expected to have maps functionality built into it, which would have a schema of its own. We're not experts in this, I expect that you know more than we do! One thing is definitely needed, that's the geo-coordinates.