|
|
Thread Tools | Display Modes |
#51
|
|||
|
|||
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. |
#52
|
|||
|
|||
Operating systems used in spacecraft?
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. |
#53
|
|||
|
|||
Operating systems used in spacecraft?
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. |
#54
|
|||
|
|||
Operating systems used in spacecraft?
||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. |
#55
|
|||
|
|||
Operating systems used in spacecraft?
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 |
#57
|
|||
|
|||
Operating systems used in spacecraft?
(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. |
#58
|
|||
|
|||
Operating systems used in spacecraft?
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 |
#59
|
|||
|
|||
Operating systems used in spacecraft?
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 |
#60
|
|||
|
|||
Operating systems used in spacecraft?
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. | |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Decision on the Soyuz TMA-4 spacecraft prelaunch processing | Jacques van Oene | Space Station | 0 | April 1st 04 01:12 PM |
Voyager Spacecraft Approaching Solar System's Final Frontier | Ron Baalke | Science | 0 | November 5th 03 06:56 PM |
Soyuz TMA-3 manned spacecraft launch to the ISS | Jacques van Oene | Space Station | 0 | October 21st 03 09:39 AM |
The Final Day on Galileo | Ron Baalke | Science | 0 | September 19th 03 07:32 PM |
BAE Systems Microprocessors Enroute To Mars | Ron Baalke | Technology | 0 | July 29th 03 10:40 PM |