No Redundancy
from Gerhard Holtkamp, 29. August 2009, 14:01
Critical technical systems on which human life may depend usually contain a lot of redundant components to ensure reliability. Sometimes however, non-redundancy might be better...
Nothing lasts forever. This is true for every component in any technical or biological system. There is always a certain probability that a particular component might fail. If you are sitting in an airplane and the in-flight entertainment system breaks down you would find this annoying but it is not life-threatening and the flight can safely continue. But if there is a failure in the steering or navigation system you will be in trouble.
To guard against failures of a critical nature such components are usually made redundant. Engineering requirements might call for double, triple or even higher redundancies. If one or even two critical components fail there should still be some other component to take over the job.
Let's assume we have a valve. To guard agains the possibility of a failure we place a second valve parallel to the first one. (We might even place yet another valve in sequence to the first one to handle the problem of a valve being stuck in the open position). We now have a much more reliable system than the single valve one but of course there still remains a (small) probability that this redundant system might fail.
To make the system even more reliable you could add more redundancies but there is a limit. The more redundancy you have the more complex the system gets and a more complex system could become less reliable again. Quite a number of Space Shuttle launches had to be postponed not because of problems with the prime systems but because some backup system was at fault.
Added redundancies typically mean added cost, mass, power and volume. Spaceflight engineers in particular are usually working within very tight constraints and have to make tough choices with regard to how much redundancy they can afford. The extra cost may or may not be a problem. Arguably an airplane which is more expensive due to redundancies but doesn't crash is cheaper in the long run than one that does crash.
Redundancies by themselves do not necessarily increase reliability. A redundant set of wires in an airplane being placed next to each other would both fail if damage occured at that critical spot. You can have a large number of computers scattered all over the world but if they all use one particular program and there is something wrong with this program you got a problem.
It is important to note that what you really want is not the most redundant system but the most reliable system. Going back to the example with the valve let's assume there is a new valve which is more reliable than the redundant set of valves. Of course substituting the new valve for the old ones would create an even more reliable system. But what if you cannot do this? Maybe the new valve is a lot more expensive than the old ones and you are left with the choice to either use the redundant set of old valves or a single new valve. To have the most reliable system the single valve would be preferable.
One good example of a system in which some critical parts are redundant while others are not (but amazingly reliable) is provided by nature. Our human body has organs which come in pairs but also some single ones like our heart. Having to rely on a single engine for all of our life may sound risky from an engineering point of view but the design has stood the test of time!
While computer hardware is comparatively cheap and usually provided with sufficient redundancy software development tends to be expensive. The system to control multiple spacecraft on different missions at the European Space Operations Centre contains a few million lines of code with a good deal of it being of a critical real time nature. Not only does this have to be created in the first place but also needs to be maintained over a long time (some space missions can last for twenty years or so). You simply don't have the money and manpower to let two separate teams work on completely redundant software.
Some aspects of the Apollo moonlanding program were non-redundant. This is especially true for the ascent engine of the Lunar Module. Almost everything else could be checked briefly before being used seriously and had some kind of backup to get the crew home alive but the LM ascent engine could not be tested after being installed and had to work perfectly the very first time it was fired on the Moon. Designing this engine as simple and with as little moving parts as possible to make it highly reliable proved to be the key to success. The lives of twelve astronauts depended on it. The engine always worked.
All those examples pale compared to the biggest non-redundancy of all: Our very own planet Earth. Mars seems to hold some promise for establishing a second human presence but to have real redundancy it is not enough to have a few human outposts there which are regularly supplied from Earth. You would need a completely self-sufficient colony where everything needed is produced locally from breakfast cereals to microchips. It is safe to say that for many generations to come we are left with the one planet we already inhabit.
Not having a redundant planet to fall back on we have no choice but to make our Earth as reliable as possible. Apart from the many earthbound activities needed there is one particular space project which holds out some promise. Deflecting rogue asteroids on a collision course with Earth seems to be possible with a fairly moderate budget - much less than human flights to Mars. This idea is definitely worth pursuing.
Let's not make the same mistake the dinosaurs did by not investing enough into space technology!
Nothing lasts forever. This is true for every component in any technical or biological system. There is always a certain probability that a particular component might fail. If you are sitting in an airplane and the in-flight entertainment system breaks down you would find this annoying but it is not life-threatening and the flight can safely continue. But if there is a failure in the steering or navigation system you will be in trouble.
To guard against failures of a critical nature such components are usually made redundant. Engineering requirements might call for double, triple or even higher redundancies. If one or even two critical components fail there should still be some other component to take over the job.
Let's assume we have a valve. To guard agains the possibility of a failure we place a second valve parallel to the first one. (We might even place yet another valve in sequence to the first one to handle the problem of a valve being stuck in the open position). We now have a much more reliable system than the single valve one but of course there still remains a (small) probability that this redundant system might fail.
To make the system even more reliable you could add more redundancies but there is a limit. The more redundancy you have the more complex the system gets and a more complex system could become less reliable again. Quite a number of Space Shuttle launches had to be postponed not because of problems with the prime systems but because some backup system was at fault.
Added redundancies typically mean added cost, mass, power and volume. Spaceflight engineers in particular are usually working within very tight constraints and have to make tough choices with regard to how much redundancy they can afford. The extra cost may or may not be a problem. Arguably an airplane which is more expensive due to redundancies but doesn't crash is cheaper in the long run than one that does crash.
Redundancies by themselves do not necessarily increase reliability. A redundant set of wires in an airplane being placed next to each other would both fail if damage occured at that critical spot. You can have a large number of computers scattered all over the world but if they all use one particular program and there is something wrong with this program you got a problem.
It is important to note that what you really want is not the most redundant system but the most reliable system. Going back to the example with the valve let's assume there is a new valve which is more reliable than the redundant set of valves. Of course substituting the new valve for the old ones would create an even more reliable system. But what if you cannot do this? Maybe the new valve is a lot more expensive than the old ones and you are left with the choice to either use the redundant set of old valves or a single new valve. To have the most reliable system the single valve would be preferable.
One good example of a system in which some critical parts are redundant while others are not (but amazingly reliable) is provided by nature. Our human body has organs which come in pairs but also some single ones like our heart. Having to rely on a single engine for all of our life may sound risky from an engineering point of view but the design has stood the test of time!
While computer hardware is comparatively cheap and usually provided with sufficient redundancy software development tends to be expensive. The system to control multiple spacecraft on different missions at the European Space Operations Centre contains a few million lines of code with a good deal of it being of a critical real time nature. Not only does this have to be created in the first place but also needs to be maintained over a long time (some space missions can last for twenty years or so). You simply don't have the money and manpower to let two separate teams work on completely redundant software.
Some aspects of the Apollo moonlanding program were non-redundant. This is especially true for the ascent engine of the Lunar Module. Almost everything else could be checked briefly before being used seriously and had some kind of backup to get the crew home alive but the LM ascent engine could not be tested after being installed and had to work perfectly the very first time it was fired on the Moon. Designing this engine as simple and with as little moving parts as possible to make it highly reliable proved to be the key to success. The lives of twelve astronauts depended on it. The engine always worked. All those examples pale compared to the biggest non-redundancy of all: Our very own planet Earth. Mars seems to hold some promise for establishing a second human presence but to have real redundancy it is not enough to have a few human outposts there which are regularly supplied from Earth. You would need a completely self-sufficient colony where everything needed is produced locally from breakfast cereals to microchips. It is safe to say that for many generations to come we are left with the one planet we already inhabit.
Not having a redundant planet to fall back on we have no choice but to make our Earth as reliable as possible. Apart from the many earthbound activities needed there is one particular space project which holds out some promise. Deflecting rogue asteroids on a collision course with Earth seems to be possible with a fairly moderate budget - much less than human flights to Mars. This idea is definitely worth pursuing.
Let's not make the same mistake the dinosaurs did by not investing enough into space technology!
Concerning spacecraft, the issue of enhancing reliability via redundant components is indeed a baffling task (or a highly non-trivial one, as engineers like to put it, modestly).
You made some good points. Allow me to belabor them a bit on the basis of a real-world example.
Imagine you have a large expensive spacecraft that shall go into orbit around Mars to study that planet's surface. To insert into the orbit around the planet, the spacecraft has to apply a braking manoeuvre using a rocket engine. This manoeuvre is referred to as MOI: Mars Orbit Insertion.
What if this manoeuvre fails, e.g., because the rocket engine does not ignite at the prescribed time? Why, then the spacecraft would shoot out from Mars again on a hyperbolic arc and might well end up in an orbit around the sun that extends out into the asteroid belt. Instead of slowing down to a stable orbit around Mars, it would even pick up orbital energy from that planet. Barring a major lucky break, that mission would be lost, the spacecraft would never be able to return to Mars to perform its intended task there.
So, how could one enhance reliability? Adding another engine seems like a good idea. One could ignite both engines simultaneously. In that case, The manoeuvre duration would be halved - in fact more than halved, as the gravity losses would also be reduced ... but let's not go into details.
At first sight, this looks like a good idea. If both engines work - as is normally the case - one has a much shorter manoeuvre and much less time where things may go badly wrong. If one engine fails, then the other one will pick up the slack, achieve MOI and save the mission.
Fine and dandy. But here's the rub: Two engines that come of the production line never have exactly the same thrust. If you have only one engine, that doesn't matter, because it will be mounted such that it fires exactly along the symmetry axis of the spacecraft.
If that engine is a bit stronger or weaker than predicted, it makes no difference. Accelerometers will monitor the deceleration imparted and cut off the engine a bit later or earlier than pre-calculated, and that's all.
But if you have two engines, you have to mount both of them off the symmetry axis, because how else would you place them? They have to be separated by a certain distance, as these rocket engines get hot during operation and must have enough free space around them.
Now, if one engine is stronger than the other, there will be a torque. The engine thrust will not only slow down the spacecraft, it will also twist it around. The amount of that torque, i.e., the strength of the twisting effect depends on where the centre of gravity of the spacecraft is, and THAT in turn changes with time as propellant from the tanks is being used up.
If one of the engines fails, or even falters momentarily, there will instantaneously be a much stronger torque. To counteract that, one needs a lot of smaller rocket engines mounted at different points of the spacecraft that produce a counter-torque. These engines will fire in bursts to kep the spacecraft pointed in the right direction during the burn.
But of course, also these engines have redundancy and reliability issues. What if they don't work at all? What if they ignite when they should be off? What if one of them suddenly cuts out? The system needs to be supervised and controlled.
All of this would require a lot "plumbing", in spacecraft engineers' parlance. You end up with a very complex system, and in the end, it may not be certain at all that the overall system reliability is enhanced ... the opposite may be true, and your spacecraft may end up with a lot more hardware installed (and thus, a lot less mass available for scientific instrumentation), while the overall reliability, the chance of performing MOI as planned, is not improved or even reduced.