Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Space

Operating Systems Used In Space? 24

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?
This discussion has been archived. No new comments can be posted.

Operating Systems Used in Space?

Comments Filter:
  • 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....
  • Well, I know that the Hubble was just recently upgraded to 386 status, a project that cost US taxpayers somewhere in the neighborhood of three billion dollars. Imagine that just to insert a $5 processer!

    Considering that most all of what the Hubble has to do is to collect data, send it to a satellite, and to re-position the lens, NASA most likely has written a little code in straight assembly instead of using an OS, so you're probably right about that. Satellites themselves just collect and receive data, so again, that's relatively simple. Shuttles, however, perform a wide variety of tasks, so the probablity that they have an OS on board is higher.

    Assuming that NASA will use Linux becase of "no budget" is ridiculous. NASA's budget has been reduced, not truncated to zero. The price of any OS is just a fraction of the costs of any of their equipment, so I don't see any reason there to use Linux.

    Also, assuming that they would use Linux because a lot of NASA employees are contributors is equally ridiculous. More likely, the reason that many NASA employees contribute to the various Linux projects is because of their level of intelligence and the fact that they personally use Linux. After all, they couldn't possibly get everything done in Window$ that they would need to do.



    Brad Johnson
    --We are the Music Makers, and we
    are the Dreamers of Dreams
  • 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.
  • by Anonymous Coward
    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.
  • Actually, Google search for '"linux +in space"' gives some interesting results. Try it out (no actual link because of goatse syndrome).
    --
  • Free is nice but Linux is starting to become more popular for ground based systems at NASA because of its reliability. Most people at NASA don't care what operating system is used for a system, as long as it works reliably and doesn't screw up the schedule or budget.

    Most spacecraft use custom operating systems or real-time executives in ROM. I think JPL has used VRTX on some of their spacecraft. You don't want to use a hard disk on a spacecraft.

    NASA's concept of reliability is different than Microsoft's. Some of the people I talk to at NASA have become disillusioned with Windows NT due to bad experiences with it in deployed ground systems, such as crashing or not working properly under high loads.

    There is also the problem that commercial hardware and software has a short life cycle in comparison to many government computer systems. This makes it difficult to support older systems when you can't get replacement parts and the software is not supported. It isn't unusual for some of these systems to be in use for 15-20 years before they are replaced. Many systems are being retired early because of hardware and software support issues.

    One of the ground systems that I worked on uses OS/2 and ISA I/O cards. Those were the best choices when the system was developed. Today it is a problem. There isn't much support for OS/2 and ISA slots are disappearing from commodity PCs. If I designed a system today, with Windows 2000 and PCI I/O cards, how many years would it take before I was in the same situation?

  • 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 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.
  • by BitMan ( 15055 ) on Sunday July 23, 2000 @07:20AM (#912682)

    [ Note: I was a Software Engineer at Coleman Aerospace [crc.com] 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 [doe.gov] (according to various public documents from about a year ago, Bendix development is still located at the DoE's Kansas City Plant [kcp.com]). 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 [windriver.com]'s VxWorks RTOS [windriver.com]. 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 [redhat.com] group) product called Tornado [windriver.com] (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

  • In case you're interested in eCos, here's the homepage URL (forget to include it above):
    http://sources.redhat.com/ecos/ [redhat.com]

    -- Bryan "TheBS" Smith

  • by BitMan ( 15055 ) on Sunday July 23, 2000 @07:34AM (#912684)

    Here's the direct URL:
    http://www.wrs.com/products/html/jpl.html [wrs.com]

    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

  • 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:

    1. Ultra-low power
    2. Ultra-low response times

    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:

    • Telemetry support systems -- a heavily SGI-driven market of "soft" real-time UNIX systems. As we all know, SGI is going Linux so this is a development focus for them.
    • CIL/HWIL systems -- Computer-in-the-loop, hardware-in-the-loop is a very important set of pre-flight verification simulations. Again, SGI has quite a market here.
    • CFD computing clusters -- Linux clusters are 10x the bang for the buck versus shared memory systems for Computational Fluid Dynamics (CFD). CFD is a design-time simulation tool and it scales extremely very linerly over a cluster of systems (i.e. it is idea of clusters) because it is 98% computation, 2% data traffic (before/after simulation).

    -- Bryan "TheBS" Smith

  • 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.
  • Check out this Slashdot Article, [slashdot.org] it references this CNN Article [cnn.com] which gives decent information on the ISS LAN and some associated systems. Hope it helps!
  • "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?"

  • >Rad-hardened memory isexpensive 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)

    Which is why just about any mission critical device uses ECC memory - takes care of those single bit errors without a delay... but only if that area is read before a second bit gets corrupted. Hence RAM scrubbing (RW all of the memory over a period of time, cleaning out any single bit errors. Good stuff.
  • I recently did quite a bit of work with VxWorks on palmtops and it seems to be pretty widely used in the space industry. Remember the Martian Rover that had software problems after it landed on mars? That was running VxWorks (I read a paper describing the software problem as being related to compiling VxWorks incorrectly. It had to do with leaving priority inversion on/off (I can't remember which one) and creating a Race Condition).

    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).

  • 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.
  • by BigBlockMopar ( 191202 ) on Monday July 24, 2000 @12:30PM (#912693) Homepage

    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.

  • 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.
  • Dont you mean:

    10, 9, 8, 7, 6, 4.99999999876...

    Houston, we have a pentium floating point problem.

    Baz
  • No.

    a) The counter circuit would still display 5, even if 5 was really 4.whatever -- it'd just be wrong.
    b) The floating-point bug was in the insignificant bits, so there'd be a lot more 9's.
    c) It's fixed now.
    d) Pentium is a proper noun and a trademark of Intel, so you should have labelled it as such.
    e) The problem would have effected Linux also.
    f) Okay, so it was still kinda funny.

  • Yes! This is a worthwhile book. I got to hear Dr. Tomayko speak in the early 1990's when he was an ACM traveling speaker. He clearly demonstrated why they use "old" and "outdated" systems for spaceflight - because they are "known" quantities.
    It appears that the book is indeed out of print. But some form of it appears to be on the web at NASA. [nasa.gov]

    -karl.

He has not acquired a fortune; the fortune has acquired him. -- Bion

Working...