The Therac-25 Incident (2021)

Post by kulahan » Sat, Aug 30, 2025, 1:35 AM UTC

waste_monk wrote: post #262

kulahan wrote: post #207

Earlier quoted context omitted.

Unfortunately, software developers are the absolute most offensive use of the word "engineer", because 99.9% of the stuff this field makes is a competition to take the most unique approach to a solution, then getting it bandaged together with gum and paperclips. If this industry wants to be respected, it should start trying to be actual engineers. There should be tons and tons of standards which are enforced legally,…

My university offered (not sure if it still exists) a software engineer degree that was part of the school of engineering, had a mix of courses from the school of engineering and school of math and IT, and at the end of it you would be eligible to take the local equivalent of the PE exam and become a Real Engineer (I think technically you would be in the field of mechatronics). IMO this should be the standard - softw…

Post by I_dream_of_Geni » Wed, Sep 03, 2025, 8:36 PM UTC

snerbles wrote: post #193

bell-cot wrote: post #101

Earlier quoted context omitted.

>> the real failure in the story of the Therac-25 from my understanding, is that it took far too long for incidents to be reported, investigated and fixed. > the earlier (manually operated) version of the machine did have the same fault. But it also had a failsafe fuse that blew so the fault never materialized. #1 virtue of electromechanical failsafes is that their conception, design, implementation, and failure mode…

When I worked at an industrial integrator, we had a hard requirement for hard-wired e-stop circuits run by safety relays separate from the PLC. Sometimes we had to deal with dangerous OEM equipment that had software interlocks, and the solution was usually just to power the entire offending device down when someone hit an e-stop or opened a guarding panel. About a decade ago a rep from Videojet straight up lied to us…

Post by Hackbraten » Thu, Sep 04, 2025, 11:07 AM UTC

Aloha wrote: post #270

WalterBright wrote: post #220

Earlier quoted context omitted.

At Boeing there's a required "failure analysis" document listing all the failure modes and why they won't cause a crash by themselves.

Agreed - This is essentially the corner stone of systems failure analysis - something I wish architects thought about more in the software space. I'm a product manager for an old (and if I'm being honest somewhat crusty) system of software, the software is buggy, all of it is, but its also self healing and resilient, so while yes, it fails with somewhat alarming regularity, with very lots and lots concerning looking…

Post by snerbles » Tue, Sep 09, 2025, 4:12 PM UTC

I_dream_of_Geni wrote: post #303

snerbles wrote: post #193

Earlier quoted context omitted.

When I worked at an industrial integrator, we had a hard requirement for hard-wired e-stop circuits run by safety relays separate from the PLC. Sometimes we had to deal with dangerous OEM equipment that had software interlocks, and the solution was usually just to power the entire offending device down when someone hit an e-stop or opened a guarding panel. About a decade ago a rep from Videojet straight up lied to us…

To be fair, reps don't really know anything deep about their product. They just parrot what they are told (or they wing it, which, i guess, can be lying). They are pushed to sell, and they will say anything to sell.