Slashdot Mirror
Operating Systems Used In Space?
tik asks: "I'd be really thankful if anyone could tell me what OS's are used in Space (i.e. ISS, MIR, Space Shuttle, Satellites). I have tried finding out myself, but alas have not been able to locate anything worthwhile. Since I am realy curious on the subject I'd appreciate any comment or help." Which operating systems have braved the final frontier and how well did they fare?
The whole idea with all the computer systems on the shuttle, mir, hubble, etc is for them to be as simple and proven and reliable as possible. Intel still makes "radiation hardened" 386's for them, so I'd assume whatever's up there can run on a 386. I know in the past they always took (of all things) an HP 47cv calculator up with them, and that's what did a lot of the work(!).
If you think about what their actual needs are, it's mostly in the area of controls and communications equipment. Stuff that's most reliably done by narrowly designed programming for proprietary hardware, not necessarily full-blown os's. But you can bet that when they get around to using full os's to run the show, Linux will be on top of the heap of candidates, based partially on the fact that they have no budget anymore and partially on the fact that so many of the brightest Linux contributors today actually work for NASA....
A while back IBM gave NASA one of their ThinkPad laptops to try out in space (I expect there was some useful reason, too, but it escapes me...) It might even have been one of the little 701 'Butterfly' ones where the keyboard folds out... Someone correct me? It ran OS/2 and worked fine, AFAIK.
As someone who maintains onboard software for a satellite - I can tell you that we have written our own software/OS that runs on the hardware we designed. The OS is pretty simple - but the satellite software is doing a specific task and therefore doesn't need to be flexible - in our case something like Linux would be a huge overkill. Rad-hardened memory is expensive and the more RAM you have the more likely you are to experience SEUs (Single Event Upsets - where radiation flips a bit in RAM causing corruption) therefore most satellites don't tend to have that much RAM - which obviously reduces the space you would have for something like the OS. Think of it like this - if your computer was designed to only run one program - then there would be very little point in having a large OS.
VXworks from Wind River systems (I don't have the URL) was used in the Mars Pathfinder. My university teaches VXworks using robot control systems and the Tornado cross-development system.
--
Jesus died to meet you.
A latent existence
A book that explores in depth the computers used on most of NASA's spacecraft (atleast up until 1994, which makes it dated on the recent stuff, such as the recent shuttle upgrades, but still pretty interesting historically) is Computers In Space by James E. Tomayko.
ISBN is: 1-56761-463-9
Sadly, I believe the title is out of print, but if you can find it, it it's pretty detailed.
WRCT Pittsburgh, 88.3FM
[ Note: I was a Software Engineer at Coleman Aerospace for 3 years ]
Many of the early computers in ballistic missiles and space probes borrowed heavily from the military. Much of the gyros and computing systems were produced by Bendix for the Department of Energy (according to various public documents from about a year ago, Bendix development is still located at the DoE's Kansas City Plant). In case you aren't familiar with how the government works, the DoE was and still is the non-military, government agency tasked with the creation of numerous components of our nuclear arms technology (as well as their normal energy details, a natural tandem role). Looking at their "most advanced computer" in the early 1980s (the Bendix 930 in the Pershing II MRBM), you essentially had a 16-bit CPU and database with 64KB of memory on various cards in a wire-wrapped backplane. And, yes, all the target code for these machines are done in assembler.
Today, both the military and NASA contractors "better, faster, cheaper" attitude of using off-the-shelf hardware, tools and software revolves mainly around the VME architecture (usually for 68300 and, increasingly, PowerPC boards -- military spec/hardening) with WindRiver's VxWorks RTOS. VxWorks is heavily BSD 4.3-based OS with response times in the tens of microseconds (on a 40-50MHz processor). Development is done using GNU development tools using a customized Cygnus GNUPro (now under RedHat's services group) product called Tornado (customized for WindRiver by Cygnus) so it can target various VxWorks architectures with Linux, Solaris and Windows being the most popular host development platforms. [ I personally found Windows to be a real pain if you also install Visual Studio on the same system because which tries to take over your system -- have to be careful you run the right make, etc... binary ].
A well-known 68K/VxWorks-based mission was the Mars Pathfinder. Today, the combo is used in a wide variety of launch and space vehicles. At my former employer, we used it for our ballistic target and booster vehicles for the military and LEO (low earth orbit) launch vehicles for NASA (and they continue to do so). A future mission to the outer planets will be PPC/VxWorks-based, all written with the GNU development system. [ Since Linux nor most other general-purpose OSes cannot guarantee such "hard" real-time response times (let alone no Windows platform can seem to deliver even deliver any "soft" real-times either), it is my hope that Cygnus' (now RedHat's) eCos takes off and cuts into VxWorks' market in the next 5 years). ]
Which brings me to my final point: I think people get caught up with the whole this OS versus that OS issue when the argument should be GNU development versus Microsoft Visual development for "mission critical" purposes. The GNU cross-compilers and tools allow you to target dozens of platforms and massive code reuse whereas Microsoft changes its Visual Studio products on a whim. I mean, it's really harder to port Windows code just for a version change than it is to port to another, completely different architecture with GNU. I personally don't see why Windows developers put up with it because Cygnus makes some damn good IDE and tools for development.
Personally, I think the best remedy for the whole DOJ v. Microsoft trial would be to force Microsoft to support GNU-based development tools for the Windows platform (both target and host) -- and set a time-frame in which they would have to drop their current, non-GNU-based Visual product (e.g., 5 years). This would do several things: actually force the documentation of the API, thus increase overall stability of the Windows platform, finally address multi-user ignorance as the main problem with Windows security (98% of even Microsoft's own applications are multi-user ignorant!), and many, many other benefits to the developers as well as the consumer. Of course no one in the trial has the forsight to see this as the best remedy, and I seriously doubt we will see any discussion of it either.
-- Bryan "TheBS" Smith
-- Bryan "TheBS" Smith
Independent Author, Consultant and Trainer
In case you're interested in eCos, here's the homepage URL (forget to include it above):
http://sources.redhat.com/ecos/
-- Bryan "TheBS" Smith
-- Bryan "TheBS" Smith
Independent Author, Consultant and Trainer
Here's the direct URL:
http://www.wrs.com/products/html/jpl.html
This JPL mission really set the "standard" on what COTS hardware and software could do. It is the main reason why VxWorks was so widely adopted by the rest of the Aerospace industry.
-- Bryan "TheBS" Smith
-- Bryan "TheBS" Smith
Independent Author, Consultant and Trainer
Again, I think people are making this out to be too much of an OS issue. It's not. The fact of the matter is that many space vehicles don't have an OS and the use of a RTOS for multitasking has only been around for 3 years (forget even using a general purpose SO). So, again, it's a development tool issue and GNU is here and Windows is no where.
Space vehicles have a two fold requirement:
These are the extremes of the extremes. Although Linux can get sub-ms response times, you need a fast processor to get there (as with any general OS). Since low power is an even greater consideration, you're not going to get that speed. As such, you'll need to use a small, RTOS to get those response times on slower processors. [ I hope everyone here knows Microsoft is quite out of their mind when they say Windows CE is a RTOS -- it is NOT! ]
Where Linux comes into the space program (other than the engineering workstation/development systems themselves) is in the support systems. Several examples:
-- Bryan "TheBS" Smith
-- Bryan "TheBS" Smith
Independent Author, Consultant and Trainer
I read a press release a year or so ago saying they just finished fitting a space shuttle with Debian Linux. I also think that it said all the other shuttles were set to be fitted with Linux eventually. As far as Mir and other international space projects I have no idea.
Bendix's Kansas City Division (and the rest of Bendix) became part of AlliedSignal, and currently Honeywell International, after various mergers and acquisitions.
Mea navis aericumbens anguillis abundat
Check out this Slashdot Article, it references this CNN Article which gives decent information on the ISS LAN and some associated systems. Hope it helps!
"Don't you know you're going to shock the monkey?"- Peter Gabriel
"Houston, we are go for launch."
"10, 9, 8, 7, 6, 5, 4, ignition start, 2, 1..."
<shuttle rises above the launch platform, then abruptly the engines shut down>
"OH, <beep>! And why is the screen blue?"
VxWorks is a POSIX operating system with Real Time abilities. I would also imagine some other POSIX RTOS's have been used (PSOS is probably up there). But as far as RTOS goes VxWorks was the largest RTOS out there when I was developing under it. In case anyone cares, its a joy to develop for, uses GNU tools and has a wonderfull debugger/profiler. The tools work well under both Solaris and Windows. I recommend using it if you have any needs for a RTOS (I've used quite a few).
I thought someone said there was going to be free beer!
Watching a MIR/Shuttle mission a couple years ago on live NASA TV (I was REALLY bored) I caught them walking an astronaut through an NT reboot sequence. I was quite amused.
-- Periodically spray diskettes with insecticide to prevent system bugs from spreading.
Okay.
I work for a major American defense contractor, and I therefore speak with some authority. Note that nothing I'm going to release is a trade secret or a federal secret.
A lot of mission-critical stuff a few years ago was based on the Texas Instruments TMS9900 CPU chip, which is an old 16-bit processor that is basically a Texas Instruments TI-99000 minicomputer scaled down to a single 64-pin DIP. The most common place that you will find a TMS9900 these days, however, is in a TI-99/4A home computer sitting around in someone's closet.
Lots of other older stuff used Z-80s. In fact, the control system for the NRX reactor (now decommissioned) at Canada's Chalk River Nuclear Laboratories was using a Z80 processor and core memory due to its relatively minimal vulnerability to the effects of ionizing radiation if something went wrong.
Our more recent mission-critical stuff around the office uses either Motorola 68000s or Intel i960 processors, both of which are used as embedded processors running machine language off ROM chips. All the mission-critical (ie. radar, etc.) stuff appears to be written in assembly language, then (of course) assembled to machine language.
That's not to say that a lot of stuff these days is written for Linux and other operating systems, but not with the stuff that I see on a daily basis.
Besides, with the efficiency required to run a lot of the older processors that you have to use (because of their availability in industrial and military temperature ratings), all OS code must be lean and tight, generally written specifically for the application. Fault tolerance and real-time operation with a processor that people would laugh at having on a desktop are not an option, they are a requirement.
Let's face it, if you're at war and the guidance computer in a cruise missile you've just fired goes down, you could blow up your allies, not your enemies.
Fire and Meat. Yummy.
Mostly on target except: 1) Pathfinder was RAD6000 not M68K. 2) Tornado is a Wind River Product, with a GNU based toolchain, not something we got from Cygnus. 3) The VxWorks network stack is BSD based, but the kernel is not. RTOS != UNIX. RTOS has strict priority based preemption, low interrupt latency, etc. Disclaimer: I am a Wind River employee ... but of course not a spokesman.