Operating systems used in spacecraft?

Derek Lyons wrote:
(Greg) wrote:
|
|And since this was originally about OS.. a quote from the above paper:
|For example, this paper is being written on a Pentium PC using Word 7
|under Window s 95. We have found that a typical spread of software
|use on this system exhibits a defect every 42 minutes on average,
|with a serious failure around every 5 hours.

So, how DO they define a defect? Is there some hardware setup in the
background that is constantly DMA'ing memory and looking for parity
mismatches? Or checksum errors?

|Which suggest more than anything, they have flakey hardware or serious
|(non-MS) software issues, and/or an extremely incompent system
|administrator.

You think there'd be fewer problems if it were some other program than
'Word?' Or fewer problems with some other hardware setup?

|That's not to say Win95 is completely innocent, but a failure rate that
|high is well out of family.

How did you come to that conclusion?

|All too often Windows takes the blame for things not entirely it's
|fault.

Even being *partially* at fault, will ultimately lead to a system crash.

Matthew Montchalin wrote:

Derek Lyons wrote:
(Greg) wrote:
|
|And since this was originally about OS.. a quote from the above paper:
|For example, this paper is being written on a Pentium PC using Word 7
|under Window s 95. We have found that a typical spread of software
|use on this system exhibits a defect every 42 minutes on average,
|with a serious failure around every 5 hours.

So, how DO they define a defect? Is there some hardware setup in the
background that is constantly DMA'ing memory and looking for parity
mismatches? Or checksum errors?

A good question indeed.

|Which suggest more than anything, they have flakey hardware or serious
|(non-MS) software issues, and/or an extremely incompent system
|administrator.

You think there'd be fewer problems if it were some other program than
'Word?' Or fewer problems with some other hardware setup?

I think you'd discern my opinion if you read what I wrote.

|That's not to say Win95 is completely innocent, but a failure rate that
|high is well out of family.

How did you come to that conclusion?

Fixing too many bungled installations of Windows (from 3.1 on up) and
migrating many installations to properly configured hardware. No one
that I know with a properly installed and maintained Windows box has
problem at the rate described above.

D.
--
The STS-107 Columbia Loss FAQ can be found
at the following URLs:

Text-Only Version:
http://www.io.com/~o_m/columbia_loss_faq.html

Enhanced HTML Version:
http://www.io.com/~o_m/columbia_loss_faq_x.html

Corrections, comments, and additions should be
e-mailed to , as well as posted to
sci.space.history and sci.space.shuttle for
discussion.

On 10 Nov 2003, Keith F. Lynch wrote:
| Doesn't the Shuttle have three computers all running in parallel, with
| majority vote ruling? That sounds like a good system. Two machines
| would have to have the same bug for anything to go wrong.
|
|Kevin Willoughby wrote:
| Alas, multiple machines with the same bug is common, since four of
| the Shuttle's computers are running identical code.
|
|Oh. I guess that redundancy is only meant to protect against hardware
|failures. The right thing to do would be to have them run completely
|different code.

Either that, or the same code on completely different hardware; if -
as it appears to be - they are running anything other than assembly
language code, it actually makes sense to have them compile their
code for execution on completely different kinds of processors.

|Of course the code would have to all be written from the same
|specification, and that specification could contain bugs.

Unforeseen errors in specifications can hardly be guarded against,
just tested for, and looked for. If they can find errors in the
specifications, then the specifications can be changed. But you
are right, code ought to be given the same level playing field if
it is to be expected to perform as predicted.

| The fifth Shuttle computer is running very different code written
| from a very different specification, to minimize the chance of
| common-mode bugs.
|
|When does the Shuttle rely on that fifth computer, and ignore the
|other four? Obviously it will never win a majority vote, unless
|three of the other four all simultaneously go berserk in different
|ways, which seems unlikely.

Insofar as statistics go, is it possible that Stein's Paradox figures
in here? -Introducing completely unrelated information into a balancing
equation actually produces a better and more perfect fit than if the
unrelated information is withheld, or isolated. If this is the case,
it would be a mistake to isolate the output of a 'fifth' computer
when four other computers are busy processing the data and churning
out results.

||When does the Shuttle rely on that fifth computer, and ignore the
||other four? Obviously it will never win a majority vote, unless
||three of the other four all simultaneously go berserk in different
||ways, which seems unlikely.
|
|Insofar as statistics go, is it possible that Stein's Paradox figures
|in here? -Introducing completely unrelated information into a balancing
|equation actually produces a better and more perfect fit than if the
|unrelated information is withheld, or isolated. If this is the case,
|it would be a mistake to isolate the output of a 'fifth' computer
|when four other computers are busy processing the data and churning
|out results.

In hierarchical quandaries where

A beats B
C beats D
D beats E
E beats A

it makes plenty of sense to incorporate the judgment of a "rogue"
processor whose judgment is wholly out of line with the others.
This is one of the more practical ways of applying Stein's Paradox
in statistics to real world situations like that of the above.

Matthew Montchalin wrote:
||When does the Shuttle rely on that fifth computer, and ignore the
||other four? Obviously it will never win a majority vote, unless
||three of the other four all simultaneously go berserk in different
||ways, which seems unlikely.
|
|Insofar as statistics go, is it possible that Stein's Paradox figures
|in here? -Introducing completely unrelated information into a balancing
|equation actually produces a better and more perfect fit than if the
|unrelated information is withheld, or isolated. If this is the case,
|it would be a mistake to isolate the output of a 'fifth' computer
|when four other computers are busy processing the data and churning
|out results.

In hierarchical quandaries where

A beats B
C beats D
D beats E
E beats A

it makes plenty of sense to incorporate the judgment of a "rogue"
processor whose judgment is wholly out of line with the others.
This is one of the more practical ways of applying Stein's Paradox
in statistics to real world situations like that of the above.



I'm a little bit puzzled by how you see statistics or hierachical
quandries applying to the computer votes. I don't see a hierarchy at
all, and statistics aren't usually applied to a single vote.

Computers A,B,C, and D are expected to form a consensus, and
non-consenders (someone will tell me the real word) are considered
broken. The only purpose of the 4 multiple computers is to make sure
a broken computer is detected. My experience with FT systems was that
they were in lock-step on the bus cycle; I'm not sure if that is the
case with these, but they do run the exact same code.

The fifth computer, as described in a previous post (JRF or MG, IIRC)
does not do the exact same computation. Instead, it does a more
limited computation using different code. The idea is that when
you've lost A, B, C, and D that you're willing to give up the optimum
solution for *a* solution. Someone has pointed out that E only
controls the vessel when the crew has selected it.

Now perhaps Stein's paradox pertains to finding good ways of doing
N-version programming, but they hadn't reached that conclusion when I
was studying SWEng. Perhaps you could make the connection more clear?

/dps

(Derek Lyons) wrote in message ...
(Christopher M. Jones) wrote:

The Space Shuttle uses different
control systems which back each other up but the software is very,
very closely related to each other (the backup is a stripped down
version of the original) and it all runs on the same hardware.

Um, no. The BFS and PASS are utterly unrelated other than the share
the same set of basic specifications and run on common hardware.

Correction noted. Though, as you note, they are very similar in that
they are "low level compatable" by design in a way that would be
difficult for any usual choice of hardware / software infrastructure
(processors, busses, OSs, etc.) Besides which the budget for
development of the Shuttle software is roughly two or three King's
ransoms, give or take.

(Derek Lyons) wrote in message ...
(Christopher M. Jones) wrote:

The Space Shuttle uses different
control systems which back each other up but the software is very,
very closely related to each other (the backup is a stripped down
version of the original) and it all runs on the same hardware.

Um, no. The BFS and PASS are utterly unrelated other than the share
the same set of basic specifications and run on common hardware.

Correction noted. Though, as you note, they are very similar in that
they are "low level compatable" by design in a way that would be
difficult for any usual choice of hardware / software infrastructure
(processors, busses, OSs, etc.) Besides which the budget for
development of the Shuttle software is roughly two or three King's
ransoms, give or take.

I can understand TMR with spare - what is TMR/simplex?

From: http://66.113.195.245/history/history_docs/sp-
8070/ch2/2p5/2p5p1_redundancy.htm

A substantial reliability increase over simplex operation can be
achieved by reorganizing the TMR system to switch out one of the two
remaining good modules, as well as the failed one, in the event of a
malfunction (ref. 78). As a result, one or more modules may operate
simplex while the remainder operate TMR (the "TMR/Simplex" curve in
fig. 8).

OK. That seems to assume that on a second disagreement, the voter goes
catatonic, doesn't it? ...which is the problem TMR/simplex is trying to
solve, and the reason the TMR reliability drops below simplex as time
goes on. Couldn't you just push out the decision with which of the two
modules to continue until an actual disagreement happens? Then you get
at least the diagnosis of the second fault.

Jan

I can understand TMR with spare - what is TMR/simplex?

From: http://66.113.195.245/history/history_docs/sp-
8070/ch2/2p5/2p5p1_redundancy.htm

A substantial reliability increase over simplex operation can be
achieved by reorganizing the TMR system to switch out one of the two
remaining good modules, as well as the failed one, in the event of a
malfunction (ref. 78). As a result, one or more modules may operate
simplex while the remainder operate TMR (the "TMR/Simplex" curve in
fig. 8).

OK. That seems to assume that on a second disagreement, the voter goes
catatonic, doesn't it? ...which is the problem TMR/simplex is trying to
solve, and the reason the TMR reliability drops below simplex as time
goes on. Couldn't you just push out the decision with which of the two
modules to continue until an actual disagreement happens? Then you get
at least the diagnosis of the second fault.

Jan

In article ,
rk wrote:
Anyways, whether it's called COTS or modified COTS it is inexpensive
and more or less available to anyone at a commercial fab.

It's COTS if I can order it from Digi-Key and have it arrive on my desk
the next morning. :-)

Actually, you can take the ":-)" off that. One of the Secret Wisdoms :-)
of the cheap-spacecraft mafia is that prototyping early and often, which
is really good for effective debugging and thus for system reliability, is
just a Whole Lot Easier if you stick to parts that *don't* have six-month
delivery times and a requirement for ITAR paperwork. (Not to say that
these necessarily do; haven't tried them.) Being able to implement your
design change tomorrow, so you can start testing it the day after, does
wonders for cost-effective engineering.
--
MOST launched 30 June; first light, 29 July; 5arcsec | Henry Spencer
pointing, 10 Sept; first science, early Oct; all well. |