5 ms·

There are economies of scale and reliability when you're building large numbers of something. Yes. One of the biggest predictors of reliability in aerospace sy

There are economies of scale and reliability when you're building large numbers of something. Yes. One of the biggest predictors of reliability in aerospace systems in general is time in operation---the longer you've actually run something, the closer it approaches the upper limit of reliability for that component. Running 27 small copies gives you 27x the time in operation vs a single big-ass engine. The downside is complexity, and in particular unknown failure interactions which could bring down the entire system in a cascade. As long as many of the components are identical, though, an improvement in reliability of that component should translate directly into lower probability of failure interactions since there are fewer failures, period.

bunderbunder 9y ago
How does one quantify the risk of cascading failure? My initial instinct, informed by computing, is to say that it's easier to avoid cascading failures in the system that is composed of more, smaller parts. All other things being equal, in a rocket with 5 engines, if one of them fails, then each of the remaining ones needs to pick up 1/4 of the slack to compensate. In a rocket with 9 engines, not only would each of the remaining engines need to pick up only 1/8 of the slack, but the total size of the gap would be a little over half as much, too. (This is obvs ignoring the possibility that the failure in question is catastrophic.)
- deleted 9y ago
  [deleted]
- physcab 9y ago
  The difference between aerospace and computing is that aerospace is heavily materials dependent. Getting a bad pixel in a monitor is rare but when it happens it’s not catastrophic. When you’re producing a ton of parts you have to also maintain quality. Not doing so will introduce impurities which will alter the material properties. An alloy with different material properties could potentially burn, fracture, expand etc more differently than represented in their acceptable failure models.
- neltnerb 9y ago
  To answer the first question, you use a fault tree analysis to predict potential failure starting points (like a broken component) and then describe how those failures will propagate through the system. https://en.wikipedia.org/wiki/Fault_tree_analysis https://en.wikipedia.org/wiki/Fault_tree_analysis For an example, say I'm building a system that needs to hold a block of aluminum at 550C, 99% of the time. Okay, so you add a thermocouple and a heater to it, easy. What if the thermocouple fails? Well, if the thermocouple fails open then the temperature will read infinity and the heater will shut down and probably produce a non-catastrophic failure. If the thermocouple fails closed, the temperature will read room temp and the heater will blast full on until the aluminum melts at 660C, which is a catastrophic failure. If the relay in the temperature controller fails, the furnace probably turns off but theoretically could fail on if the relay switch gets fused. Okay, so I can see that there is an unlikely but possible chain of events that could cause a catastrophic failure. So I add a second thermocouple to act as a safety shutoff using a second redundant relay and controller if it reads a temperature above 600C. Total probability then is estimated by either using real world performance metrics or best-guesses. I'd say the odds of a thermocouple failing in 10 years of operation at 550C is nearly 100%, so this failure will nearly certainly occur. Or consider an LED array with 10 of them in parallel. If one blows open, the remaining 9 each get 10% more current so are more likely to fail. So your first branch of the tree might be that the odds are 10% that an LED will fail at design current within five years. That may well not qualify as a failure, especially since the other 9 LEDs are ~10% brighter due to the higher-than-spec current. But now your probability for the next failure is 20% within five years. So you do need to define different outcomes, usually by severity of impact and probability of outcome in event of a predicted possible failure point.
  - ethbro 9y ago
    Is there a name for (or keywords to search for) weighing the tradeoffs between attempting to reduce failure effects in a component itself vs addressing them at the system level? E.g. while you could mechanically debounce a button itself, it's usually easier to engineer the system in such a way that trigger bounce doesn't cause issues Wondering how the call is made on where the appropriate fix to increase reliability should be made? Or is all bespoke / gut?
sehugg 9y ago
Yes, one of the poorly-understood problems with early NASA missions was "pogo", a propellant vibration problem which affects the entire vehicle: https://www.popsci.com/how-little-vibrations-break-big-rockets https://www.popsci.com/how-little-vibrations-break-big-rocke...

bunderbunder 9y ago

How does one quantify the risk of cascading failure? My initial instinct, informed by computing, is to say that it's easier to avoid cascading failures in the system that is composed of more, smaller parts. All other things being equal, in a rocket with 5 engines, if one of them fails, then each of the remaining ones needs to pick up 1/4 of the slack to compensate. In a rocket with 9 engines, not only would each of the remaining engines need to pick up only 1/8 of the slack, but the total size of the gap would be a little over half as much, too. (This is obvs ignoring the possibility that the failure in question is catastrophic.)

deleted 9y ago
[deleted]
physcab 9y ago
The difference between aerospace and computing is that aerospace is heavily materials dependent. Getting a bad pixel in a monitor is rare but when it happens it’s not catastrophic. When you’re producing a ton of parts you have to also maintain quality. Not doing so will introduce impurities which will alter the material properties. An alloy with different material properties could potentially burn, fracture, expand etc more differently than represented in their acceptable failure models.
neltnerb 9y ago
To answer the first question, you use a fault tree analysis to predict potential failure starting points (like a broken component) and then describe how those failures will propagate through the system. https://en.wikipedia.org/wiki/Fault_tree_analysis https://en.wikipedia.org/wiki/Fault_tree_analysis For an example, say I'm building a system that needs to hold a block of aluminum at 550C, 99% of the time. Okay, so you add a thermocouple and a heater to it, easy. What if the thermocouple fails? Well, if the thermocouple fails open then the temperature will read infinity and the heater will shut down and probably produce a non-catastrophic failure. If the thermocouple fails closed, the temperature will read room temp and the heater will blast full on until the aluminum melts at 660C, which is a catastrophic failure. If the relay in the temperature controller fails, the furnace probably turns off but theoretically could fail on if the relay switch gets fused. Okay, so I can see that there is an unlikely but possible chain of events that could cause a catastrophic failure. So I add a second thermocouple to act as a safety shutoff using a second redundant relay and controller if it reads a temperature above 600C. Total probability then is estimated by either using real world performance metrics or best-guesses. I'd say the odds of a thermocouple failing in 10 years of operation at 550C is nearly 100%, so this failure will nearly certainly occur. Or consider an LED array with 10 of them in parallel. If one blows open, the remaining 9 each get 10% more current so are more likely to fail. So your first branch of the tree might be that the odds are 10% that an LED will fail at design current within five years. That may well not qualify as a failure, especially since the other 9 LEDs are ~10% brighter due to the higher-than-spec current. But now your probability for the next failure is 20% within five years. So you do need to define different outcomes, usually by severity of impact and probability of outcome in event of a predicted possible failure point.
- ethbro 9y ago
  Is there a name for (or keywords to search for) weighing the tradeoffs between attempting to reduce failure effects in a component itself vs addressing them at the system level? E.g. while you could mechanically debounce a button itself, it's usually easier to engineer the system in such a way that trigger bounce doesn't cause issues Wondering how the call is made on where the appropriate fix to increase reliability should be made? Or is all bespoke / gut?

sehugg 9y ago

Yes, one of the poorly-understood problems with early NASA missions was "pogo", a propellant vibration problem which affects the entire vehicle: https://www.popsci.com/how-little-vibrations-break-big-rockets https://www.popsci.com/how-little-vibrations-break-big-rocke...