Spacecrafts' Operating Systems, Topic about Spacecrafts' OS Options

[hal_9000]

I want to know more about Spacecrafts' OS!
How to work a OS in a spacecraft?
What OS work in Mars Rovers?

[jamescanvin]

I want to know more about Spacecrafts' OS!
How to work a OS in a spacecraft?
What OS work in Mars Rovers?

Google is your friend, try it.

For instance,

Searching: MER Mars operating systems

Top hit is:

http://www.space.com/businesstechnology/te...ter_040128.html

which says:

"[JPL] needed the tools to be able to develop their mission software on a system from someone with a proven track record," explained Steven Blackman, director of business development for aerospace and defense for the software company Wind River. The Alameda, California-based company developed the VxWorks real-time operating system used in aboard the MER rovers, as well as other NASA and European Space Agency missions.

Easy!

[hal_9000]

Google is your friend, try it.

For instance,

Searching: MER Mars operating systems

Top hit is:

http://www.space.com/businesstechnology/te...ter_040128.html

which says:
Easy!

This VxWorks works in Navy Helicopters!?!?
I think so....

[Guest_Richard Trigaux_*]

They do not send bad stuff in space. It has to be proven reliable. A well known operating sysem would never go in space. And a weel known "free" competitor of the previous no more. VxWorks... is it possible to buy it and install on my PC?


The languages too are an important issue. When I worked in the domain I knew that the old C was not allowed, due to memory management problems, well known from C designers who are sometimes confrontated to "unexplainable malfunctions".

As explained in the article, radioactivity too is a major problem. I remember have seen big TO3 transistors destroyed with just one ion, or a SPARC microcontroler (sun stations) sending strings of errors from radiations.

[chris]

The languages too are an important issue. When I worked in the domain I knew that the old C was not allowed, due to memory management problems, well known from C designers who are sometimes confrontated to "unexplainable malfunctions".

Richard,

The "memory management problems" in C are generally a result of badly written code. Bugs related to allocation and freeing of memory still occur, of course, but nowadays there are numerous sophisticated tools to help.

Remember that Unix systems are written in C, and are generally considered to be very secure.

Chris

[Bob Shaw]

I want to know more about Spacecrafts' OS!
How to work a OS in a spacecraft?
What OS work in Mars Rovers?

HAL:

Surely you already know all about spacecraft OS?

Pity about the error-trapping in the AE35 unit!

(It always amuses me that 'Athena' was chosen as the generic MER package name, after Arthur C Clarke revealed in 'The Lost Worlds of 2001' that HAL 9000's name was originally Athena (though in that incarnationa a bit less homicidal))

Bob Shaw

[Guest_Richard Trigaux_*]

Bugs related to allocation and freeing of memory still occur, of course,

I is THIS what I was understanding with "memory management problems", and it is THIS which forbad C to be used in high reliability applications.


You may think that if people write bad code, it is not the fault of the language. Indeed it can be, if the language contains ambiguities such as signs wich effect vary depending on implicit context paradigms, or if the language does not contains built-in protections against subtle confusions by the writer. From my own experience, I know that it is very difficult to guess what is goodly written code in C. Of course there are alway people who come and tell you that your code is bad, but it seems that nobody never went with a code good enough to pass reliability tests. As for me, the only piece of flight software I ever wrote was in assembler for a small microcontroller, so it really depended only on me to have the memory properly managed, the result did not depended on mysterious functions which correct working depends on many implicit parametres.

[chris]

I is THIS what I was understanding with "memory management problems", and it is THIS which forbad C to be used in high reliability applications.

(snip) From my own experience, I know that it is very difficult to guess what is goodly written code in C. Of course there are alway people who come and tell you that your code is bad, but it seems that nobody never went with a code good enough to pass reliability tests.  (snip)

I still maintain that C is not the problem. Memory leaks can occur in languages that do memory management for you - I have recently seen a nasty leak caused by a subtle classloader problem in Java. Testing is the key to this, of course, as well as good tools. I was using an early version of Purify 15 years ago to help fix a memory problem, and I'm sure the tools have advanced a great deal in the intervening time.

Want proof that reliable applications can be written in C? How about this:

"Each rover has 256M of flash memory, with 227M available for files, plus 128M of RAM. Certain blocks are reserved for dedicated program buffers. The JPL team last week was preparing to reformat Spirit’s flash memory. The programming team also has become aggressive about deleting files from the flash memory of the second rover, Opportunity, Klemm said.

Most of the code is written in C, running under the VxWorks 5.3.1 operating system from Wind River Systems Inc. of Alameda, Calif. A few files are in assembly language, and one module is in C++. "

from here

Chris

[Guest_Richard Trigaux_*]

Chris, If I were naughty, I would reply that the MER precisely had memory management problems...


But I rather prefer to thing that the C was bettered, not the language syntax itself, but the compiler which is responsible of writing a correct memory management. Back to ten years ago, when I was working in the domain, there was a suspicion against the C. But if the MER design team estimated that they could do with C, it is that they were confident enough (at least they have more experience than me) that the compilers and OS they used were good enough and would not do some bad trick. So it is a good new after all. Just wanted to know what compiler they used, certainly not the standard compilers used on PCs, but a specific one for VxWorks, which enjoyed a special care for reliability, fitting the reliability level of VxWorks.

I was often angry, writting in various languages of using many softwares, to alway find many bugs and everybody seems to look at such a situation as a normal state of things, lefting software users and programmer spending hours and days to try to guess what is the correct spelling of a command. Of course nobody can pretend to do zero-bug, but the least and first thing to do is, when a bug is found, to recognize it as a bug and try to find a fix without further charge, in place of starting a psychoanalysis of the user.

[mike]

In my experience with programming, the language (compiler, really) is almost never the source of any bugs. And in my experience any compiler bugs result in an abortion of the compiling process altogether, and so you never get any executable code anyway.

The real problem is that the compiler cannot 'magically sense' what it is you are trying to make it do, and so if you mess up on some small step or another, it will happily produce the code you request and the code will inevitably crash later.

C and C++ do require the programmer to clean up after himself as far as dynamic memory allocation goes, but I much prefer that to Java and C#'s (and others..) method of just cleaning up at some indefinable point in the future, often with much thrashing of CPU (and disk, usually, since all this unused memory has inevitably been paged onto your hard drive).

As far as a real-time device like a rover is concerned, I imagine the team is very concerned with making things happen only when they want them to happen, and they test the software like crazy, which is the REAL solution to quashing bugs, not in building in eight million and one 'magic nets' that are supposed to somehow know what you REALLY meant to do, despite what you told the computer to do in the first place..

[garybeau]

Regardless of what operating system or compiler you are using, there is no substitute for testing. You must make sure every line of code gets executed during a rigorous testing that pushed the parameters to the extremes. Two rockets that were brought down because of simple bugs that should have been caught are Mariner 1, because of a missing comma and the maiden voyage of Arien 5 trying to put a 64 bit number into a 16 bit register. Most likely those line of code were never executed during testing.

[Guest_Richard Trigaux_*]

Yes sure, there is no substitute for testing. But it is very difficult to perform extensive testing of complex systems, so some cautions must be taken from the very beginning.

I remember to have written a soft for a microcontroller, in C with some interuption routines in assembler. It was finished and worked fine, except for some rare random crashes. I spent a day to find why, doing hundreds of times the same manoeuvers, ending to find that the C was using a register that I too used in an assembler routine. This simple example shows us that memory management has to be complete and 100% logical, and not "this situation must be very rare so we do not account for it" or "it is unlikely that the programmer will write a code that way". And memory management has to be done from the very beginning, OS and compiler. If these two do not work 100% error free from the beginning, it cannot be further corrected by a programmer.

In the case of the C, the programmer is partially responsible of the memory management, as there is no protection against variable overflow (if a 8 bit number takes a 16 bits value, the program writes the two bytes in the memory, crushing the adjacent variable) and this was the cause of many errors. This alone makes C writing difficult, but I think there was other problems the programmer could not cope with. If I was responsible of selecting which OS and compiler to use for something like the MER, I would choose something which does not arise such complex issues.

So no "probabilities" in flight software, and extensive testing. A little bit of this philosophy would be fine too in commercial software we use on our PCs.

[tty]

Some notes on how reliability is handled in the aerospace world for flight safety critical software.

Redundancy (three or four independent channels, which "vote" on what to do)

The code for each channel is written by a separate group working independently but to the same specification, if possible using different programming languages and/or compilers.

Use well tried and mature hardware and software ONLY. Until quite recently ruggedized 80486 and Motorola 68000-series were the processors of choice (and at least one of the world's most advanced aircraft is actually flying around using CP/M as OS for some embedded processors)

Test the hell out of the code.

AND KEEP IT SIMPLE

tty

[Guest_PhilCo126_*]

Other than a reliable OS, the spacecraft need good ( radiation-hardened ) processors. The MRO, on its way to Mars now, uses a RAD750 space flight computer produced by BAE Systems of Manassas, VA.

[Guest_Richard Trigaux_*]

Other than a reliable OS, the spacecraft need good ( radiation-hardened ) processors. The MRO, on its way to Mars now, uses a RAD750 space flight computer produced by BAE Systems of Manassas, VA.

When I was working in the domain one of the main concerns was radiations. Just a tasty salad of remarks:

-To radiation test integrated circuits or power transistors takes several years, leading to often led to use ancient components. This is certainly the reason why a specially designed circuit was produced, such as the RAD750.

-A single radioactivity event, one particule, can destroy a power transistor (used in converters, motor drivers...)

-radioactive events in computers can produce "latch-ups" (the chip is locked in a state where it consumes a lot of current, which can lead to destruction by overheating, and it can recover only with cutting off the supply current) or upsets (a logical bit or memory bit changes state. Often there are several upsets in adjacent places).

-to fight latchup, a monitoring of a chip supply current is required

-Upsets can produce anomalous behaviours of a software. To fight this, cautions are required, such as a whatch dog (a memory space in which the computer must regularly write in, overwhise it is considered into an anormal state and reset).

-Upsets can produce mistakes in a calculus, or in the memory. To fight this, the bits of a given byte of data must be physically separated. And we can imagine many cross-checks of data or calculus results.

-the software programmer must take cautions such as alway reserving a default value in choices, as any unexpected value can come.