Tinfoil is definitely not gonna do much - unless you stack it a foot thick. Tantalum foil is pretty common, however. And tantalum "spot shields" over critical parts, like any sort of solid state devices. No point in trying to protect things that aren't very susceptible to radiation damage.
But error-correction and redundancy is a lot lighter, and weight is vitally important.
It's surprising how long that ~1/2 a second can be. I've had conversations over a geo comsat, and it's pretty awkward - just long enough to screw up the flow, but not so long that you have to consciously compensate for it.
First big problem - why is is that Silicon Valley should do this, vice everyone else that already knows how to build solar cells and has been doing so for years? A few years ago, my aerospace company decided to go into the railroad car business, to "bring them in to the 20th century". Well, predictably, companies that have been building railroad cars since the Civil War turned out to know *far* more about it than we did, and our "improvements" were nonsense. This seems like the same sort of arrogance/hubris.
Second, and far more fundamental, *it takes far more energy to make a solar cell than it can ever possibly collect*. So, to build these renewable, "environmentally-friendly" solar cells, results in fantastically *greater* use of fossil fuels (mostly coal) or nuclear plants. And it's not just start-up costs - it's still a net big loser even with the entire life-cycle. The cell degrades before it ever breaks even.
And if you have to build nuke plants to make solar cells, you might as well send the energy directly to the grid and cut out the intermediate process.
I want to help the environment at least as much as anyone, but doing things that are conceptually faulty won't get it done.
> "The operating system and kernel fit in less than 2 > megabytes; the rest of the code, plus data space, > eventually exceeded 30 megabytes." This should be used as > the example for efficient coding
You've GOT to be kidding, right? 2 meg of OS code? That's ULTRABLOAT compared to most spacecraft. In fact, for the vast majority of the space age, that would have exceeded the resources of the computer by several orders of magnitude.
I've done this kind of programming for a living (for 10 years, moved up to controls design) but the last system I programmed for has 372k of memory, total. That includes data, code, OS, everything. Runs at 432 KIPS. And it performs what it probably one of the most complex in-flight autonomous control operations ever.
Most are even more restrictive. For example, 8K of PROM and 1k of volatile memory (and 28 WORDS) of non-volatile memory. This more than adequate for most applications, if you do it right.
Many spacecraft OS's are more akin to this:
hardware interrupt external electronics power up processor. external electronics set PC = 80hex run {execute all the code} halt power down
Once every 1/4 a second for 15 years.
The project I am currently working on uses VxWorks (and so we were quite interested in the Mars Rover problem) and it's so bloated with unnecessary features it's absurd. This is not a Windows box, it's a spacecraft processor.
I can't argue with the 30 meg of data space. Using the memory as a data recorder would be quite useful and a good picture takes a lot of space. But it's alarming to me that you could figure out how to waste maybe 4-5 meg on code. If you started with a bare home-brew OS, I would guess (and I get paid for this sort of guess) that you could do the entire flight code in 512K, with maybe 8k of data space, excluding the science data.
Only recently have space-qualified rad-hard processors with this kind of capability become available. Until then, if you said you needed 2 meg for the OS alone, you would have gotten fired on the sopt and referred to mental health professionals. The availability of these processors enabled people to use high-level languages with tremendous overhead (like C++) to be used. And this was only done for employee retention purposes during the bubble. For years it was done at the assembler or even machine level. It's still not at all uncommon to do, and we've done MANY flight code patches, with only a processor handbook, an engineering paper pad, and by setting individual bits one-by-one.
>Tube amps natively have *very* high slewing rates too, much >higher than most transistor amps, except for some very >recent, exotic transistor amp designs which use some very >special transistors, which are finally beginning to approach >the slewing rates that simple tube amps have achieved >forever.
Well, nothing like reviving an argument that most sensible people stopped debating 25 years ago. But I never said I was sensible...
The tubes themselves do indeed have very high slew rates. That advantage is defeated by the use of massive step-down output transformers with associated massive inductance. And in any case, the slew rates of the bare devices (transistor or tube) is so inconceivably higher than necessary for reproducing music that the difference is irrelevant. We're talking about the reproduction of no more than 20kHz with devices easily capable of 2-3 orders of magnitude faster response. And if you managed 10 Khz perfectly, no audiophile in the world, "golden ears" notwithstanding, would ever know the difference.
Once you build the circuit, the rest of the circuit determines the response, and the net effect is whatever that circuit determines.
Tube systems to tend to distort in a more agreeable way than transistor amps. And a lot more. That's why they make such interesting sounds come out of an electric guitar, where they are grossly overdriven for beneficial effect.
Far be it for me to say you shouldn't like it, but in terms of accuracy of reproduction, audio equipment shouldn't sound "warm" or in fact, sound like anything.
Junk off-shore generic transistor amps or "receivers" don't work very well, but that's not because it's made with transistors. It's everything else in the circuit - particularly, the tendency to "puke" on the reactive speaker loads, and the tendency to accept distortion in the form of every stray frequency in the world. You can't play AM radio signals with a preamp, but that doesn't mean it doesn't get in there and drive things into saturation. That makes them sound generic and plastic. A high-end transistor audio amp, properly designed, doesn't sound like anything.
I actually like tubes from a design standpoint, because its easy to come up with something that works. Very forgiving as long as you keep your fingers off the high-voltage power supply. I have a mono FM table radio I built with the last of my non-gassy 12AX7 tubes. Works neats, and the heater doesn't run nearly as much. It's quaintly nostalgic, but I wouldn't waste my time trying to make a high-end system that way.
> Quoting from the article, "We have shown that even a small > ion engine like Smart's can get us across space. Now we are > planning to build space telescopes and robot probes to > planets such as Mercury, using bigger and more powerful ion > engines. These will take years off space-travel times. > Instead of decades-long missions, we will take only a > couple of years to cross space for future projects."
Bear in mind ESA exceptionally strong tendency to claim credit for things that they have just done as breakthrough firsts - when in fact, several Western projects have used ion thrusters before now (Deep Space 2, and several commercial commsats), and that was because the Russians had developed it years ago. It's a "breakthrough" for them in several ways, but they have not advanced technology. They're FAR worse than NASA or the DoD in that respect.
I get a kick out of all the breakthrough discoveries claimed for Mars Express - and also how they were lining up to take credit for Beagle 2 (and how much better it was than those redneck colonials and their crappy rovers), then dropped the entire topic like a hot potato when it crapped out. Then it became a "auxiliary package carried by Mars Express" (which in reality, it was the entire time).
> But, "Ion engines need electricity and only solar panels > can provide enough at present. So ion engine missions will > be restricted to planets and moons near the Sun." > > So the solution to deep space exploration is > nuclear-powered ion-drives and NASA is working on it.
Indeed. "Only solar panels prove enough at present". Right, if you intentionally restrict yourself based on ideology. The Russkies have flown MANY space-based fission reactors. And then there's this:
> The ultimate speed of ion propulsion is higher than that of > chemical propulsion.
Depending of course on the fixed mass of the spacecraft, vs it's propellant mass, of course. You get more momentum change from given amount of propellant, but if you only had a teaspoon full of propellant, or the spacecraft was exceptionally massive, you wouldn't get more velocity.
> But the mass being expelled at high speeds (the ions) is so > low, that accelleration is VERY slow. So it takes a long > time to get up to speed, but the maximum speed you can > theoretically reach is much greater than that of chemical > rockets.
To expand, the measure of efficiency of a rocket engine is the specific impulse or ISP. It's how much momentum change you get per unit of propellant mass, and the usual unit is seconds (lb-sec/lb). The highest actually-achievable ISP from a chemical rocket is somewhere in the 475 seconds. The Saturn 5 first stage was more like about 350, and monopropellant thrusters used for many satellite propulsion systems is more like 150-180! That means that if you want to change the velocity a lot, you need a whole lot of propellant.
I'm not sure which engine this particular program uses, but the ISP of the typical Xenon ion thruster is something like 1800. So you have to carry fantastically less propellant for a given velocity change, meaning it can weight less at liftoff, meaning you can use a weaker/cheaper booster.
The downside is that you don't get something for nothing. It takes, not surprisingly, a whole lot of electrical power to make it go. So you put in 4000-5000 watts of power, and it only generates.04 lb of thrust -.64 of an ounce, pushing a spacecraft weighing thousands of pounds on the ground. So the acceleration is very small, meaning takes a long time to get going. The other downside is that the Xenon ions, although chemically pretty neutral, shoot out at such high speeds that anything that gets in the exhaust gets eaten away. This may or may not be an issue depending on there you put it relative to the rest of the spacecraft.
The summary is pretty bizarre. Brazil's launch is to a viable commercial launch system what the Wright Flier is to a 747. It was quite an accomplishment (coming after the previous accidents) but hardly anything more than a promising start along a 15-20 year road, with optimism. RTFA.
Additionally, the development of more commercial launch capability is essentially absurd - given that there is a huge overcapacity in commercial launch capability.
Moreover, NASA has had very little or nothing to do with commercial launch for many, many years. Private companies have been doing this essentially on their own for a long time. They use the same launchers and use Cape facilities. But NASA pays just like everybody else, when they use expendable vehicles. So the relevance of even more commercial launch capability would have no effect in any way on NASA - even assuming that this was what the Brazilians were doing - which they are not.
As far a "looking down on the Chinese" - well, given that they have had exactly one manned launch with capabilities similar to a Gemini flight from 40 years ago, (and an incredible string of accidents including dropping fully-fueled boosters into innocent villlages, destroying them almost completely, and then doing theor utmot to cover it up, and crashing a film return capsule into someone's house just last week) I thought that NASA's reaction was quite charitable. Given the problems in trying to run an international program with the highly-experienced Russians, and the apalling technology-transfer implications, it's hard to see how it would be a wise idea to jump on the Chinese bandwagon with the ISS or other international cooperation projects.
Other than that, excellent summary of the original article.
> It just seems to me that it would be better to install more > sensors, data-gathering, and reporting capabilities and > then leave the trouble-shooting to the people on the > ground.
Actually, this is *exactly* the right thing to do if you really want to perform better diagnostics and have more reliable missions. People make mistakes from time to time, but reproducing the analytical capabilities of even a dull normal person is far beyond the state of the art. Brute force works for chess - but there's orders of magnitude between chess and troubleshooting a complex spacecraft.
But fixing the hardware and using more of it is expensive, in both money and weight. Much cheaper to "solve it" in software. Or at least claim you are solving it with software.
This is a basic fallacy of space technology. Everybody assumes that the old problems are somehow magically resolved by "using fast computers", when in fact computer capabilities weren't a significant impediment to even complex space missions like Apollo. Sure 5x more memory might have made it easier to code (the only holdup at the time being the schedule for coding and testing - not the raw computational power, or lack thereof). But having way more capability is a double-edged sword. As soon as you have it, you have a bunch of people thinking up ways to use it to "solve" their problems. Problems that would be more effectively solved using better hardware, or correcting hardware problems instead of slapping in S/W kludge on top of S/W kludge. And wonder of wonders, what is the biggest schedule and performance issue on most space projects? Flight Software and flight software testing.
Obligatory/. dig - same thing with Windows - if you have a 8 gHz P4, Miscrosoft will find a way to use it up reading email.
I sometimes wonder if the aerospace industry wouldn't be better off still using core rope memory - because it at least forces some level of discipline in the FSW design. That, and banning overhead projectors and the use of PowerPoint.
While the whole thing has proven time and again to be a bad idea (this sort of thing is hardly new - or do I get credit for inventing a math model of conservation of angular momentum that got loaded on a satellite launched in 1994 for similar purposes?)
But there is a good reason to put it on board instead of on the ground. While you can hypothetically always see it from somewhere, there's nowhere near enough ground stations to watch it continuously, nor is it plausible to record every bit of telemetry onboard when it's out of sight. So a "bellringer" system (which is what we have called it for a couple of decades) does make a sort of sense.
Assuming of course the idea that you can find spacecraft failures by doing logic or "limit" checks wasn't bogus to begin with. Which it is in many cases.
Bingo - you have hit that nail on the head. These sorts of systems in aerospace applications are absolutely notorious for detecting proper (but off-nominal) operation as a failure, and then going off and reconfiguring a bunch of stuff unnecessarily. Or diagnosing real problems incorrectly, and either not helping or making things worse, or much worse.
Even more importantly, the testing associated with these systems is very expensive and time-consuming - which means they don't really test it very well at all.
I've seen similar systems in action in real space flights - and for the most part, it just makes things worse. If you were to limit yourself to simple things you really could detect, it would work out fine for the most part. But the tendency is to make it try to be a magic fixit device for any problem that comes up.
In one case, I saw such a system deploy an appendage in conditions that resulted in the spacecraft structure being severely damaged. In another, it reconfigured every spacecraft system to the redundant unit in response to a trivial problem - when all that would have been required would have been to wait 20 minutes, then correct the trivial problem.
Slashdot Mirror
Tinfoil is definitely not gonna do much - unless you stack it a foot thick. Tantalum foil is pretty common, however. And tantalum "spot shields" over critical parts, like any sort of solid state devices. No point in trying to protect things that aren't very susceptible to radiation damage.
But error-correction and redundancy is a lot lighter, and weight is vitally important.
Brett
It's surprising how long that ~1/2 a second can be. I've had conversations over a geo comsat, and it's pretty awkward - just long enough to screw up the flow, but not so long that you have to consciously compensate for it.
First big problem - why is is that Silicon Valley should do this, vice everyone else that already knows how to build solar cells and has been doing so for years? A few years ago, my aerospace company decided to go into the railroad car business, to "bring them in to the 20th century". Well, predictably, companies that have been building railroad cars since the Civil War turned out to know *far* more about it than we did, and our "improvements" were nonsense. This seems like the same sort of arrogance/hubris.
Second, and far more fundamental, *it takes far more energy to make a solar cell than it can ever possibly collect*. So, to build these renewable, "environmentally-friendly" solar cells, results in fantastically *greater* use of fossil fuels (mostly coal) or nuclear plants. And it's not just start-up costs - it's still a net big loser even with the entire life-cycle. The cell degrades before it ever breaks even.
And if you have to build nuke plants to make solar cells, you might as well send the energy directly to the grid and cut out the intermediate process.
I want to help the environment at least as much as anyone, but doing things that are conceptually faulty won't get it done.
Brett
> "The operating system and kernel fit in less than 2
> megabytes; the rest of the code, plus data space,
> eventually exceeded 30 megabytes." This should be used as
> the example for efficient coding
You've GOT to be kidding, right? 2 meg of OS code? That's ULTRABLOAT compared to most spacecraft. In fact, for the vast majority of the space age, that would have exceeded the resources of the computer by several orders of magnitude.
I've done this kind of programming for a living (for 10 years, moved up to controls design) but the last system I programmed for has 372k of memory, total. That includes data, code, OS, everything. Runs at 432 KIPS. And it performs what it probably one of the most complex in-flight autonomous control operations ever.
Most are even more restrictive. For example, 8K of PROM and 1k of volatile memory (and 28 WORDS) of non-volatile memory. This more than adequate for most applications, if you do it right.
Many spacecraft OS's are more akin to this:
hardware interrupt
external electronics power up processor.
external electronics set PC = 80hex
run
{execute all the code}
halt
power down
Once every 1/4 a second for 15 years.
The project I am currently working on uses VxWorks (and so we were quite interested in the Mars Rover problem) and it's so bloated with unnecessary features it's absurd. This is not a Windows box, it's a spacecraft processor.
I can't argue with the 30 meg of data space. Using the memory as a data recorder would be quite useful and a good picture takes a lot of space. But it's alarming to me that you could figure out how to waste maybe 4-5 meg on code. If you started with a bare home-brew OS, I would guess (and I get paid for this sort of guess) that you could do the entire flight code in 512K, with maybe 8k of data space, excluding the science data.
Only recently have space-qualified rad-hard processors with this kind of capability become available. Until then, if you said you needed 2 meg for the OS alone, you would have gotten fired on the sopt and referred to mental health professionals. The availability of these processors enabled people to use high-level languages with tremendous overhead (like C++) to be used. And this was only done for employee retention purposes during the bubble. For years it was done at the assembler or even machine level. It's still not at all uncommon to do, and we've done MANY flight code patches, with only a processor handbook, an engineering paper pad, and by setting individual bits one-by-one.
Brett
Naturally, such a system will be turned off when leaving Chinese territory, because they really only want to monitor their won society.... Brett
>Tube amps natively have *very* high slewing rates too, much
>higher than most transistor amps, except for some very
>recent, exotic transistor amp designs which use some very
>special transistors, which are finally beginning to approach
>the slewing rates that simple tube amps have achieved
>forever.
Well, nothing like reviving an argument that most sensible people stopped debating 25 years ago. But I never said I was sensible...
The tubes themselves do indeed have very high slew rates. That advantage is defeated by the use of massive step-down output transformers with associated massive inductance. And in any case, the slew rates of the bare devices (transistor or tube) is so inconceivably higher than necessary for reproducing music that the difference is irrelevant. We're talking about the reproduction of no more than 20kHz with devices easily capable of 2-3 orders of magnitude faster response. And if you managed 10 Khz perfectly, no audiophile in the world, "golden ears" notwithstanding, would ever know the difference.
Once you build the circuit, the rest of the circuit determines the response, and the net effect is whatever that circuit determines.
Tube systems to tend to distort in a more agreeable way than transistor amps. And a lot more. That's why they make such interesting sounds come out of an electric guitar, where they are grossly overdriven for beneficial effect.
Far be it for me to say you shouldn't like it, but in terms of accuracy of reproduction, audio equipment shouldn't sound "warm" or in fact, sound like anything.
Junk off-shore generic transistor amps or "receivers" don't work very well, but that's not because it's made with transistors. It's everything else in the circuit - particularly, the tendency to "puke" on the reactive speaker loads, and the tendency to accept distortion in the form of every stray frequency in the world. You can't play AM radio signals with a preamp, but that doesn't mean it doesn't get in there and drive things into saturation. That makes them sound generic and plastic. A high-end transistor audio amp, properly designed, doesn't sound like anything.
I actually like tubes from a design standpoint, because its easy to come up with something that works. Very forgiving as long as you keep your fingers off the high-voltage power supply. I have a mono FM table radio I built with the last of my non-gassy 12AX7 tubes. Works neats, and the heater doesn't run nearly as much. It's quaintly nostalgic, but I wouldn't waste my time trying to make a high-end system that way.
> Quoting from the article, "We have shown that even a small
> ion engine like Smart's can get us across space. Now we are
> planning to build space telescopes and robot probes to
> planets such as Mercury, using bigger and more powerful ion
> engines. These will take years off space-travel times.
> Instead of decades-long missions, we will take only a
> couple of years to cross space for future projects."
Bear in mind ESA exceptionally strong tendency to claim credit for things that they have just done as breakthrough firsts - when in fact, several Western projects have used ion thrusters before now (Deep Space 2, and several commercial commsats), and that was because the Russians had developed it years ago. It's a "breakthrough" for them in several ways, but they have not advanced technology. They're FAR worse than NASA or the DoD in that respect.
I get a kick out of all the breakthrough discoveries claimed for Mars Express - and also how they were lining up to take credit for Beagle 2 (and how much better it was than those redneck colonials and their crappy rovers), then dropped the entire topic like a hot potato when it crapped out. Then it became a "auxiliary package carried by Mars Express" (which in reality, it was the entire time).
> But, "Ion engines need electricity and only solar panels
> can provide enough at present. So ion engine missions will
> be restricted to planets and moons near the Sun."
>
> So the solution to deep space exploration is
> nuclear-powered ion-drives and NASA is working on it.
Indeed. "Only solar panels prove enough at present". Right, if you intentionally restrict yourself based on ideology. The Russkies have flown MANY space-based fission reactors. And then there's this:
http://www.jpl.nasa.gov/jimo/
Brett
> The ultimate speed of ion propulsion is higher than that of
.04 lb of thrust - .64 of an ounce, pushing a spacecraft weighing thousands of pounds on the ground. So the acceleration is very small, meaning takes a long time to get going. The other downside is that the Xenon ions, although chemically pretty neutral, shoot out at such high speeds that anything that gets in the exhaust gets eaten away. This may or may not be an issue depending on there you put it relative to the rest of the spacecraft.
> chemical propulsion.
Depending of course on the fixed mass of the spacecraft, vs it's propellant mass, of course. You get more momentum change from given amount of propellant, but if you only had a teaspoon full of propellant, or the spacecraft was exceptionally massive, you wouldn't get more velocity.
> But the mass being expelled at high speeds (the ions) is so
> low, that accelleration is VERY slow. So it takes a long
> time to get up to speed, but the maximum speed you can
> theoretically reach is much greater than that of chemical
> rockets.
To expand, the measure of efficiency of a rocket engine is the specific impulse or ISP. It's how much momentum change you get per unit of propellant mass, and the usual unit is seconds (lb-sec/lb). The highest actually-achievable ISP from a chemical rocket is somewhere in the 475 seconds. The Saturn 5 first stage was more like about 350, and monopropellant thrusters used for many satellite propulsion systems is more like 150-180! That means that if you want to change the velocity a lot, you need a whole lot of propellant.
I'm not sure which engine this particular program uses, but the ISP of the typical Xenon ion thruster is something like 1800. So you have to carry fantastically less propellant for a given velocity change, meaning it can weight less at liftoff, meaning you can use a weaker/cheaper booster.
The downside is that you don't get something for nothing. It takes, not surprisingly, a whole lot of electrical power to make it go. So you put in 4000-5000 watts of power, and it only generates
Brett
The summary is pretty bizarre. Brazil's launch is to a viable commercial launch system what the Wright Flier is to a 747. It was quite an accomplishment (coming after the previous accidents) but hardly anything more than a promising start along a 15-20 year road, with optimism. RTFA.
Additionally, the development of more commercial launch capability is essentially absurd - given that there is a huge overcapacity in commercial launch capability.
Moreover, NASA has had very little or nothing to do with commercial launch for many, many years. Private companies have been doing this essentially on their own for a long time. They use the same launchers and use Cape facilities. But NASA pays just like everybody else, when they use expendable vehicles. So the relevance of even more commercial launch capability would have no effect in any way on NASA - even assuming that this was what the Brazilians were doing - which they are not.
As far a "looking down on the Chinese" - well, given that they have had exactly one manned launch with capabilities similar to a Gemini flight from 40 years ago, (and an incredible string of accidents including dropping fully-fueled boosters into innocent villlages, destroying them almost completely, and then doing theor utmot to cover it up, and crashing a film return capsule into someone's house just last week) I thought that NASA's reaction was quite charitable. Given the problems in trying to run an international program with the highly-experienced Russians, and the apalling technology-transfer implications, it's hard to see how it would be a wise idea to jump on the Chinese bandwagon with the ISS or other international cooperation projects.
Other than that, excellent summary of the original article.
> It just seems to me that it would be better to install more
/. dig - same thing with Windows - if you have a 8 gHz P4, Miscrosoft will find a way to use it up reading email.
> sensors, data-gathering, and reporting capabilities and
> then leave the trouble-shooting to the people on the
> ground.
Actually, this is *exactly* the right thing to do if you really want to perform better diagnostics and have more reliable missions. People make mistakes from time to time, but reproducing the analytical capabilities of even a dull normal person is far beyond the state of the art. Brute force works for chess - but there's orders of magnitude between chess and troubleshooting a complex spacecraft.
But fixing the hardware and using more of it is expensive, in both money and weight. Much cheaper to "solve it" in software. Or at least claim you are solving it with software.
This is a basic fallacy of space technology. Everybody assumes that the old problems are somehow magically resolved by "using fast computers", when in fact computer capabilities weren't a significant impediment to even complex space missions like Apollo. Sure 5x more memory might have made it easier to code (the only holdup at the time being the schedule for coding and testing - not the raw computational power, or lack thereof). But having way more capability is a double-edged sword. As soon as you have it, you have a bunch of people thinking up ways to use it to "solve" their problems. Problems that would be more effectively solved using better hardware, or correcting hardware problems instead of slapping in S/W kludge on top of S/W kludge. And wonder of wonders, what is the biggest schedule and performance issue on most space projects? Flight Software and flight software testing.
Obligatory
I sometimes wonder if the aerospace industry wouldn't be better off still using core rope memory - because it at least forces some level of discipline in the FSW design. That, and banning overhead projectors and the use of PowerPoint.
Brett
While the whole thing has proven time and again to be a bad idea (this sort of thing is hardly new - or do I get credit for inventing a math model of conservation of angular momentum that got loaded on a satellite launched in 1994 for similar purposes?)
But there is a good reason to put it on board instead of on the ground. While you can hypothetically always see it from somewhere, there's nowhere near enough ground stations to watch it continuously, nor is it plausible to record every bit of telemetry onboard when it's out of sight. So a "bellringer" system (which is what we have called it for a couple of decades) does make a sort of sense.
Assuming of course the idea that you can find spacecraft failures by doing logic or "limit" checks wasn't bogus to begin with. Which it is in many cases.
Brett
Bingo - you have hit that nail on the head. These sorts of systems in aerospace applications are absolutely notorious for detecting proper (but off-nominal) operation as a failure, and then going off and reconfiguring a bunch of stuff unnecessarily. Or diagnosing real problems incorrectly, and either not helping or making things worse, or much worse.
Even more importantly, the testing associated with these systems is very expensive and time-consuming - which means they don't really test it very well at all.
I've seen similar systems in action in real space flights - and for the most part, it just makes things worse. If you were to limit yourself to simple things you really could detect, it would work out fine for the most part. But the tendency is to make it try to be a magic fixit device for any problem that comes up.
In one case, I saw such a system deploy an appendage in conditions that resulted in the spacecraft structure being severely damaged. In another, it reconfigured every spacecraft system to the redundant unit in response to a trivial problem - when all that would have been required would have been to wait 20 minutes, then correct the trivial problem.
Brett
That has a lifetime of a few revs, depending on the ballistic coefficient. Heating would also be a significant problem. Brett