3 ms·

Interesting story. I've been on the testing site of medical hardware many many moons ago. It's quite amazing what you can and must test. For instance: We had to

Interesting story. I've been on the testing site of medical hardware many many moons ago. It's quite amazing what you can and must test. For instance: We had to prove that if our equipment broke by falling damage that the potential debris flying off could not harm the patient. I always liked the testing philosophy institutes like for instance Underwriter Laboratories had: Your product will fail. This is stated as fact and is not debatable. What kind of fail safes and protection have you made so that when it fails (and it will) it cannot not harm the patient?

buescher 6y ago
Yes. It's amazing the number of engineers that resist doing that analysis - "oh that part won't ever break". Some safety standards do allow for "reliable components" (i.e. if the component is already been scrutinized for safe failure modes, you don't have to consider them) and for submitting reliability analysis or data. I've never seen reliability analysis or data submitted instead of single-point failure analysis though, myself. Single-point failure analysis techniques like fault trees, event trees, and especially the tabular "failure modes and effects analysis" (FMEA) are so powerful, especially for safety-critical hardware, that when people learn them they want to apply them to everything, including software. However, FMEA techniques actually have been found to not apply well to software below about the block diagram level. They don't find bugs that would not be found by other methods (static analysis, code review, requirements analysis etc) and they're extremely time and labor intensive. Here's an NRC report that goes into some detail: https://www.nrc.gov/reading-rm/doc-collections/nuregs/agreement/ia0254/index.html https://www.nrc.gov/reading-rm/doc-collections/nuregs/agreem...
- b3lvedere 6y ago
  "Through analysis and examples of several real-life catastrophes, this report shows that FMEA could not have helped in the discovery of the underlying faults. The report concludes that the contribution of FMEA to regulatory assurance of Complex Logic, especially software, in a nuclear power plant safety system is marginal." Even more interesting! Thank you for this link. I appreciate it. Never too old to learn. :)

buescher 6y ago

Yes. It's amazing the number of engineers that resist doing that analysis - "oh that part won't ever break". Some safety standards do allow for "reliable components" (i.e. if the component is already been scrutinized for safe failure modes, you don't have to consider them) and for submitting reliability analysis or data. I've never seen reliability analysis or data submitted instead of single-point failure analysis though, myself. Single-point failure analysis techniques like fault trees, event trees, and especially the tabular "failure modes and effects analysis" (FMEA) are so powerful, especially for safety-critical hardware, that when people learn them they want to apply them to everything, including software. However, FMEA techniques actually have been found to not apply well to software below about the block diagram level. They don't find bugs that would not be found by other methods (static analysis, code review, requirements analysis etc) and they're extremely time and labor intensive. Here's an NRC report that goes into some detail: https://www.nrc.gov/reading-rm/doc-collections/nuregs/agreement/ia0254/index.html https://www.nrc.gov/reading-rm/doc-collections/nuregs/agreem...

b3lvedere 6y ago
"Through analysis and examples of several real-life catastrophes, this report shows that FMEA could not have helped in the discovery of the underlying faults. The report concludes that the contribution of FMEA to regulatory assurance of Complex Logic, especially software, in a nuclear power plant safety system is marginal." Even more interesting! Thank you for this link. I appreciate it. Never too old to learn. :)