Tuesday, July 1, 2014

VOS Design Theory

I don't know if I linked to this paper before.

Web servers for embedded systems control

If you are interested, this paradigm is the primary reason I changed my notion of the way VOS should work between 2002 and 2005. After I began to understand it I realised just how powerful a single server can be and how easily the rest of a control network can be provided with nearly anything at hand.

If the server is designed to be one integrated unit with very few failure points (usually as a result of linking to external systems like an SQL database, for example) then all you have to do is to keep the server running and the whole system will stay running forever.

Over the years, I had scaled down my requirements again and again from dedicated military PCs to smaller PC/104 compatibles … but once I realised you can burn the server code onto nearly any thin client, I realised about 2011 that all the hardware for VOS you could ever need would be available as $1.00 surplus thin client devices, many of which have superior MTBF to military grade embedded boards.

My book on VOS (which is the only thing I will charge money for) will essentially assume everyone is building their control system on thin clients and I may even have several chapters on how to set up the most common devices like the ubiquitous Compaq 1100. If you spent more than $2.00 on VOS by the time you got it running, you probably spent too much money. Most of my monitoring sensors I now know how to connect to USB, CANBUS, serial and parallel ports would simply be parts stripped off cars, which there should be a big supply of after TSHTF.


Mex Arcane said...

But will it run in 128 mode?

Russell said...

I wouldn't say I get giddy when you post about VOS, but I am interested.

The other advantage that web servers give is asynchronous and stateless communications. Granted, it isn't a panacea, there are very valid reasons why you'd want synchronous state-full comms, but for a lot of tasks, a web server backend is perfect.

In fact, you've inspired me to try my hand at something similar, I've been prototyping on a Raspberry Pi and Padrino. The basic management piece is easy to design and implement using a web server, html, jquery and slqite. The Pi has more than enough power for something like that.

Of course, I lack any sort of connection to monitoring sensors, that's a future project, assuming the end doesn't happen before then.

Prof. Vault said...


I'm trying to understand how the tech equipment will be stored / function in an EMP / multi-EMP (such as a lasting war) scenario.

Will the whole shelter be a Faraday cage? Will the tech equipment be stored in individual Faraday cages? Will there be any remote sensors or radio antennae outside of the shelter?


Here are some links for your audience that I've found:

Texas Arcane said...

@Prof Vault

When the components are simple, discrete and modular they all fit into Faraday cages and easily avail themselves of EMF and EMP shielding in various forms, including optical.

So I foresee in the worse case, discovering that not only the server but the terminals as well have all been burned out, you just pop the lid of your steel trash can and pull out all the replacements. A couple steel buckets like this in your shelter and your system would be zero maintenance and even in the worst catastrophic failure, plug'n'play new components.

The important thing is to keep the necessary hardware in simple, discrete components that can be protected in various ways : server, terminal, ethernet router. You would keep one of each as replacement parts, assuming you had a loss where you knew your equipment was melted, not just shocked.

If the primary connections between everything are Ethernet, power-over-ethernet and CANBUS, you can baffle these connections with optical isolators. I have a whole box of them I purchased at $4.95 each. No matter how powerful the EMP surge, if you are off-grid there is no way an induced current is going to damage an optically isolated circuit.

Texas Arcane said...


I am far closer to a release version of VOS than anybody knows. I could upload to Github tomorrow a working version. I just need to add some more basic functionality to turn it over for testing by other people.

Yes, everything in VOS is RESTful with the exception of websockets that use ASN binary transfers. The rest of it is always stateless and uses OAUTH for calls to get sensor controls through AJAX.