Hi
For an article I am writing I need examples of software faults that have caused human fatalities (it's a "make a big impression" thing, not morbid fascination).
Any ideas?
Cheers
Duncan
Printable View
Hi
For an article I am writing I need examples of software faults that have caused human fatalities (it's a "make a big impression" thing, not morbid fascination).
Any ideas?
Cheers
Duncan
Mars lander. Oh, wait, how many people were on that thing?
The Prius(?) gas pedal sticking thing - isn't it a drive-by-wire car?
SS Challenger. Although, technically not a software failure, but a failure of appropriate use of Microsoft Powerpoint.
I thought that was due to a mixup of metric & standard measurements? If so, you really can't blame the software.Quote:
Originally Posted by SJWhiteley
My investigations have dug up quite a few examples from aviation (Airbus Paris air show crash) and some really rather horrible industrial control systems failures.
I thought there were some train crashes in the last few years that were attributed to faulty routing software, but it's just a faint memory.
According to Wikipedia that crash was blamed on pilot error, but a National Geographic documentary floated a conspiracy theory that suggested a cover-up where someone deleted four minutes of data from the flight data recorder ("the black box.")Quote:
Originally Posted by Merrion
Airbus has denied this and claims NG's "expert" simply didn't understand the synchronization between the black box and the control tower.
The flight crew claims the engines didn't respond to their throttle inputs, but the data says they reached 91% of thrust when they began ingesting treetop vegetation and subsequently failed.
Based on the info available it's likely software had nothing to do with this crash.
I don't recall any train crashes blamed on faulty software. Those systems have several layers of built-in redundancy and are pretty bulletproof. Got any links?Quote:
Originally Posted by Shaggy Hiker
Train crashes are usually the result of faulty hardware, employee errors, and of course the occasional dumbass driving around crossing gates & signals. I also recall the sabotage of Amtrak's Sunset Limited a couple of decades back that was never solved. The saboteurs unbolted a rail and attached a wire jumper across the gap to fool the dispatcher and signalling system into thinking everything was normal.
I barely have a memory of it, let alone a link. I'm also thinking that it may have been in China, in which case any report I saw may well have been....incorrect. You never can quite tell with them.
Since computer systems do exactly what you tell them to do, aren't all failures due to 'faulty software' actually human error?
The one and only failure in software was the x86 floating point error (Pentium?) which would not perform some floating point calculations correctly. This could be classed as a borderline hardware failure, though.
Edit: it seems that when a program is sufficiently complex enough that failures of that code are non-obvious, it's attributed to faulty software, but when the problem is - even in hindsight - obvious, then it is attributed to human error. Aren't these things equitable?
For example, consider a multithreading application which every billion cycles encounters a synchronization problem causing the result of a calculation to be incorrect. Is this considered faulty software?
IMO yes. I'd argue that if the code contained a mistake then it's faulty software. If an error is caused by a user miss-using the delivered software (entering incorrect values etc.) then it's user error. You're 100% right, though, that both are ultimately subsets of "human error".Quote:
Is this considered faulty software?
I'm kind of sensitive to this, at the moment. The machine we have is causing all sorts of quality issues because it's not doing what it should. The response from the engineers (a loose term in this case) is that the program is both working correctly and it's a programming fault.Quote:
Originally Posted by FunkyDexter
Regardless, they refuse to admit that there's a problem, and thus cannot do anything about it. When pushed, they simply explain this is how it works and needs more investigation.
I think this is a flaw in software engineering, as taught, in that we are able to divest ourselves of a rather serious responsibility, as the general non-technical public at large accept that software just breaks, regardless of application.
I cannot see a structural engineer shrugging 'oh well, something must have gone wrong' when a bridge fails, and it being taken as an acceptable answer.
I think I'd agree with you on all of that.
You can separate user faults from software faults but they're still both human faults. Hardware faults might be a human fault (if it's delivered with the fault) or it might just be degradation over time. Ultimately, though, if you buy a product from someone and it doesn't work per it's spec - it's a fault and you should have recourse.
Attachment 123655Quote:
Originally Posted by SJWhiteley