Wednesday, February 6, 2008
Vault Operating System : Some Field Notes
I'm going to list some of the basic requirements for the features to be present in the Vault OS V1.0 running on an XT compatible machine, let's say 512K RAM at startup, we'll assume no fixed media other than a floppy drive, monochrome display EGA, no battery, a single Ethernet card of some kind. This is about as elementary as you can get. You can find laptops like this thrown out in the garbage or at a garage sale for a few dollars. Most of the time, the clock battery will have to be present in order to maintain your BIOS setup, but keeping laptop batteries maintained is a real pain, so pull it out and we'll say that 12 volt laptop converters power all the machines off the common shelter voltage.
This will not include fixed media storage of database and configuration files. We'll leave this to specify later.
VAULT OS V1.0 BASIC FEATURE LIST :
1. Connected to a multiuser, multinode LAN Ethernet
2. Inventory management (with specific filtering for things like "due for rotation")
3. Personnel Data (including contact information, skill set and notes)
4. Medical Data (Listing basic medical info and ordinal sets of data like radiation exposure)
5. Scheduler (calendar for given week, month & year)
6. Job manager (linked to schedule, define tasks, periodicity, specifics)
7. Diagrams (maps, floorplans, locators, technical graphics)
8. Peer-To-Peer Communications (alerts, email and realtime chat with other terminals)
9. Sensors (Display of states and detectors ... hatch open, temp, water levels, batteries, etc.)
10. Controllers (Turn stuff on and off, like lights, fans, antenna riser, water pump, genset)
11. Logger (track all history and operations with review available, possible manual entries)
We'll assume a small embedded device connected to the Ethernet handles all the hard work collating and dispatching sensor information in a true multithreaded system. So something like the "Vault-Pad" I have a prototype running for would take in all kinds of sensor feeds, either analog, digital, switches ... then package this up as an Ethernet message "to whom it may concern" at regular intervals and send it out. This hardy and reliable device runs all the time, whereas any given terminal running the Vault OS can be on or off, working or broken. Although this small device schedules and controls devices automatically like air conditioning or fans, it could also be sent messages over Ethernet as overrides, like "turn on the fans now irregardless of temperature" and other control messages. It might be possible to write a PC compatible program that turns any PC into this "Vault-Pad" by configuring it correctly and using the standard interface ports (or A/D interface cards) to read in data and control devices.
If the small embedded workhorse called the "Vault-Pad" runs 24/7, then we could postulate a central server for the database (we'll say it's a very simple ISAM database) we'll call the "ThinkBoy" that serves up data from the central base and dispatches it at request. This "server" could also "think" about the ramifications of the data, like telling people that water levels are low and calculations show that with the water demands of 8 people, the water will run out in six months. In my case I'll probably use my military embedded PC board. In any other installation it might run off a decent quality 200mhz 486 portable with a hard drive. Any terminal can talk to "ThinkBoy" by name and request database information including conclusions about things like food and water, medical supplies and aboveground radiation hazards. It would be good if a single configuration switch in the Vault OS .ini file could tell a terminal (if it has the correct capacity) to take over for the Thinkboy until it comes online again. So any terminal could operate as the server if needed. This might be as simple as diagnosing the server as faulty, pulling out it's "brain" (a compact flash memory card) and then plugging it into a terminal and configuring it to become the "Thinkboy" the next time it boots up.
The population of sensor data will be looked for circulating on the Ethernet but this won't stop anything else from working. Sensor data could consist of anything we can hook up to the "Vault-Pad" via serial, parallel, I2C or other device communication protocol. If sensor data is empty for a terminal (no recent Ethernet messages) the last timestamp of sensor data is available in the sensor monitoring screen.
What kind of maintenance would ensue if a terminal failed? Go find another cheap, zero grade junk laptop or other machine, pull the "brain" (flash card) out of the defective terminal and plug it into the new one. Minimalist Ethernet installation with the OS configuring simple check for availability when the program starts.
The design goal would be a mini-internet inside the shelter which could consist of one or a thousand terminals, all with fairly similar capabilities.
Any feedback greatly appreciated. I am really trying hard to hammer out most of these details before I start work on the new version. I will have time in coming months to work on this regularly at night so I plan to get this working as soon as possible, for my own use initially and then anybody else who wants it. I'm not going to try to make any money off this operating system, it will absolutely be freeware when I have it running inside my own shelter.
EDIT : Arachne Web Browser, 16 Bit DOS HTML Browser Desktop ... could this be the base client operating system for a WATT-32 16 bit TCP/IP local network?