3 ms·

This data point is not useful without knowing the failure rate for each of them. For example, the Sun is a single point of failure for us each day. ...but the

This data point is not useful without knowing the failure rate for each of them. For example, the Sun is a single point of failure for us each day. ...but the odds of the Sun being destroyed per day are so infinitesimally small, that it's not meaningful to say I have a single point of failure each day for the next 20,000 days.

vlovich123 6y ago
That’s a logical albeit unhelpful argument. My observation of how engineering is done and the economic pressures involved make me think that such cost cutting is inevitable. So the short term “we’ll just make this single point of failure component more reliable” is not an effective strategy as “design in depth” that assumes any single component will fail. It can be more expensive but in some ways (maintenance, up-front cost) but can also be cheaper since the individual components don’t need as much testing/validation/reliability. That being said, engineering is all about trade offs so the takeaway I have from something like this is blind faith/hope that the domain experts make these decisions better than an outsider (me) and that when mistakes are made they’re corrected in the longer-term. I don’t know a better way than that.
bumby 6y ago
This is fair. Single point of failures denote a severity (loss of mission) but risk is defined as severity x probability. To extend your example to the extreme, everything on the JWST has a failure probability > 0, even the systems with redundancies. What ends up happening is each failure is plotted on a severity x probability matrix with a resulting score. Depending on the requirements, the exact probability category thresholds may be defined quantitatively (e.g. 1/10,000 chance) or they may be more qualitative (e.g., ‘likely’ vs. ‘may happen’ vs. ‘improbable’). The resulting risk has to accepted by someone (usually a program or project manager). To your point, they have obviously found each to be an acceptable (but perhaps uncomfortable) risk. Some projects will define the acceptable level of risk at the requirements stage to drive design (e.g., no single points of failure that can result in loss of crew). With all that said, it is still an abnormally high number of single point failures in a complex system and reliability is generally not linearly related to complexity (just think about what happens to cyclomatic complexity as you add more variables and the resulting number of test cases you need for full coverage) In my opinion, the real dangerous part of this process is that humans are notoriously poor at thinking in probabilistic terms. Challenger, Columbia, EVA 23 etc. are all attributable, in part, to bad assessments of probability. Human biases are all but guaranteed to affect these probabilities and thus affect our understanding of the associated risk.

vlovich123 6y ago

That’s a logical albeit unhelpful argument. My observation of how engineering is done and the economic pressures involved make me think that such cost cutting is inevitable. So the short term “we’ll just make this single point of failure component more reliable” is not an effective strategy as “design in depth” that assumes any single component will fail. It can be more expensive but in some ways (maintenance, up-front cost) but can also be cheaper since the individual components don’t need as much testing/validation/reliability. That being said, engineering is all about trade offs so the takeaway I have from something like this is blind faith/hope that the domain experts make these decisions better than an outsider (me) and that when mistakes are made they’re corrected in the longer-term. I don’t know a better way than that.

bumby 6y ago

This is fair. Single point of failures denote a severity (loss of mission) but risk is defined as severity x probability. To extend your example to the extreme, everything on the JWST has a failure probability > 0, even the systems with redundancies. What ends up happening is each failure is plotted on a severity x probability matrix with a resulting score. Depending on the requirements, the exact probability category thresholds may be defined quantitatively (e.g. 1/10,000 chance) or they may be more qualitative (e.g., ‘likely’ vs. ‘may happen’ vs. ‘improbable’). The resulting risk has to accepted by someone (usually a program or project manager). To your point, they have obviously found each to be an acceptable (but perhaps uncomfortable) risk. Some projects will define the acceptable level of risk at the requirements stage to drive design (e.g., no single points of failure that can result in loss of crew). With all that said, it is still an abnormally high number of single point failures in a complex system and reliability is generally not linearly related to complexity (just think about what happens to cyclomatic complexity as you add more variables and the resulting number of test cases you need for full coverage) In my opinion, the real dangerous part of this process is that humans are notoriously poor at thinking in probabilistic terms. Challenger, Columbia, EVA 23 etc. are all attributable, in part, to bad assessments of probability. Human biases are all but guaranteed to affect these probabilities and thus affect our understanding of the associated risk.