Columns

One of the single most affecting quotes about computing I ever read was from a Space Shuttle software engineer called Bill Pate: "If the software isn't perfect, some of the people we go to meetings with might die." I wish all developers had the same attitude.

My interest in the whole computers-in-space thing has been, er, re-ignited of late in anticipation of the Phoenix Mars lander rocking up to the red planet and attempting to get to the surface in one piece. The seven-minute landing sequence will be completely automatic - Mars is a minimum of three light-minutes from Earth, so real-time control is impossible.

The Phoenix lander is unusual in comparison to recent missions since it's not just going to plummet to the surface and use air bags to cushion the blow. It's going for a controlled touchdown using thrusters. That might not sound so terribly tricky, but it's one hell of a software and engineering problem. For a stark illustration, take a look at the videos on Armadillo Aerospace's website (www.armadilloaerospace.com). Armadillo is the group headed up by iD Software programming supremo John Carmac, focused on producing a winning entrant in the Northrop Grumman Lunar Lander Challenge. The Challenge is an earth-bound one and consists of building a lunar lander-type vehicle to take off vertically, travel 50m and touch down again, all under computer control using rocket thrusters. Read the history and watch the videos

ADVERTISEMENT

of disasters to get an insight of how difficult it is to set something like that up, even when you've got a team of people standing right by to nurse it through, repeat failed runs and swap bits out when they break.

A Mars lander has not these luxuries. And the racks full of ultra-powerful computers available to the likes of the robots in the DARPA Grand Challenge (www.darpa.mil/grandchallenge) aren't an option on a spacecraft where every gram of mass counts and every watt of power consumption is a scarce resource.

Spacecraft computer systems must be designed and engineered around the absolute imperative of working without the possibility of direct human intervention. Granted, the software can be modified by re-uploading via radio link, but that's no use if the system's completely hung or a component has failed.

So, cutting-edge exotic hardware is off the menu. The Phoenix has a simple, proven, single-board computer called a RAD6000, running nothing more exotic than a PowerPC CPU at 33MHz. The RAD6000 consumes a maximum of about 20W of power. It could probably just about manage Windows 95 if you really wanted it to, although it's not x86 compatible so Mac OS 9 might be a better bet. The only thing that's special about it is its radiation hardening, designed to cope with space-borne emissions normally absorbed by the atmosphere down here on Earth.

Funnily enough, though, space probes don't run Windows. Phoenix uses a variant of the VxWorks real-time operating system, which doesn't need a whole load of computing power; in fact I'm reliably informed that some Canon cameras run the same basic OS. The essential thing about VxWorks is that it's a hard-real-time operating system, able to respond to events in a fixed, predictable timescale. Sometimes a late response is as good as no reponse at all - you don't want your drogue parachute deploying two minutes after you ask it to - so a real-time OS is a must. It's also the reason you won't tend to find Windows running a nuclear power station.