Concept diagram of computers / avionics system | Computer Systems Workgroup | Forum

Here is a concept diagram I produced today of how the insides of one of our talked about "avionics boxes" may look:

Basically it consists of 6 single-board computers (netbook internals, BeagleBoards, something like that), each with a dedicated function, all connected on a gigabit ethernet network.  The computers are (in no real order):

1. A Control and Instrumentation Computer.  This is hooked up to the LCD monitors and speakers in the cabin, and any joysticks, keyboards and switches in the cabin.  It relays information to the astronaut via the monitors and speakers, accepts control signals from the various sources and passes control information on to either other computers or directly to hardware.
2. A Navigation Computer.  This is hooked up to various navigation hardware (GPS receiver, IMU, etc).  It performs Kalman flitering (or equivalent) on all the input to make position and velocity estimates.  These are stored locally on a CF disk or the like.  Other computers can ask the navigation computer at arbitrary times for the latest estimates over the network (maybe implemented a very simple CGI program running on a minimalist web server like thttpd).
3. A Storage Computer.  This is hooked up to a redundant array of solid state drives, and either stores or fetches data for the other computers at their requests (maybe implemented by NFS).
4. A Communications Computer.  This is hooked up to a USRP (or equivalent) and handles all communications issues – it takes data from other computers and sends it to Earth, and it authenticates telecommand packets from Earth and passes the instructions to other computers.
5. A Telemetry Computer.  This is hooked up to a huge array of sensors in the interior and exterior of the spacecraft and constantly formats raw data into telemetry packets to forward to the Communications Computer.  It also detects any patterns in the sensor data which are problematic and notifies the Interface and Control Computer, which can put up visual/audio warnings.
6. A Media Computer.  This is hooked up to microphones and cameras in the interior and exterior of the spacecraft, and is constantly encoding data from these sources, sending all of it to the Storage Computer for recording and some of it to the Communications Computer for transmission.

These 6 computers and the various other items of hardware involved (GPS, IMU, USRP) could easily all be fit into a fairly compact case, just like a desktop computer.

An individual one of these cases is not at all redundant, so redundancy would come from having 2 or 3 of these cases on board.  A set of switches would control which of the 3 cases was connected to shared resources (i.e. the I/O devices in the cabin, the antenna array, etc).  If all 3 cases were running at once, these switches could basically hand off "active duty" from one case to another arbitrarily (e.g. if one of the case's computers crashes due to radiation interference).  The case which is currently on "active duty" could also make use of the "standby" cases by asking them to duplicate crucial calculations (majority voting to make sure an answer is correct) or by getting additional navigation data from them.  A simple computer running a "heartbeat" program could monitor all the cases simultaneously and operate the switch bank which controls active duty.

Does this seem sane to others?  If we do go down this route, I feel like with a bit of money we could see pretty quick progress on one of these cases.  It would be quite easy to test one rather thoroughly in a car: just fit the car with a few webcams, some cheap telemetry sensors from SparkFun or the like, set up the USRP to transmit not on S-band but on VHF or some such from a fairly standard antenna, use a USB protable hard drive as a stand in for a RAID array of solid state disks, etc, and the car is basically an Earth-bound version of the CM, from an avionics perspective.  This would at least be enough to test all the high level functionality.

Rocket-To-The-Moon said:

I think that this would be a highly educational and fun project for someone in the IT area to work on. It would be quite the accomplishment to build a 6+ node network within the confines of a standard ATX sized enclosure.

Extremely true.  I'm actually starting to realise that we can do a lot more useful work on avionics at this stage of the project than I anticipated, and it seems not only really fun but fairly easy (the software side of it, at least – it would be easy to simulate a physical 6 node cluster with 6 virtual machines on a virtual LAN, and sensors etc. could be easily simulated by e.g. Markov chain models with random noise).  I might need to revise my ultimate involvement plan to include navigation and this. :)

Sorry for not getting back to you sooner on this, Clicker, thanks for your comments.

With regards to data: we have not yet really done a rigorous analysis of storage requirements (we definitely should, though, and if you want to take some initiative on kicking this off, please feel free).  My intuition is that numerical data storage (like navigation data, etc.) will not pose too much demand, but multimedia data storage will.  We will want to record video and audio from the entire flight as well as lunar EVA.  It probably isn't necessary for the in-flight cabin video to be particularly high resolution, since it will just be someone sitting in a seat for a few days, but when it comes time to actually walk on the moon we're going to want absolutely the best video quality that we can manage.  I don't really have a good feel for how much space high quality video takes up, but over the length of the entire flight I would not be at all surprised if our total data storage requirements were on the order of 100G or even higher.

The VM idea is interesting and deserves consideration.  To be clear: did you intend that at any one time only one physical computer would be "on duty", with the 5 virtual computers inside it sharing the work, or something more flexible, where all 3 computers are "on duty" simultaneously and the work is dynamically spread amongst the pool of 15 virtual computers?

As for the media computer – well, something has to encode the raw data from cameras and microphones into suitable formats for storage (avi, jpg, mp3, whatever – I don't know enough about multimedia to say what is best.  Also I suppose it would be in the spirit of our open contract to use open formats like Ogg etc. where we can).  I don't really know how much grunt this requires, a dedicated computer may be overkill.  This diagram was just supposed to be a rough outline.

It is probably time we got a little more serious about thinking this stuff through.  We need to think more clearly about what likely failure modes are and how to adapt to them.  One thing that is entirely absent in this first diagram of mine is any kind of voting system, which is something I think we will almost certainly have to implement to guard against errors in computation resulting from "Single Upset Event" problems caused by radiation.