The title of this post is misleading, they eventually supplied a software patch that fixed the clock drift. The Israelis proposed rebooting as a stopgap until the bug could be fixed.
Failed intercept at Dhahran caused by a software error in handling of timestamps
31–40 of 91 posts
Re: Failed intercept at Dhahran caused by a software error in handling of timestamps
#32The scud missile lead to their deaths, not the software. There's no absolute guarantee it would have intercepted it, plus rebooting a deployed machine regularly is an acceptable fix when it's live in the field
That's a reductio fallacy. If you want to play that game, it was being deployed to that specific place that caused their deaths. Or was it enlisting in the first place? Maybe merely having been born? This is a strictly technical examination of the proximate cause of their deaths; it makes no claims about their ultimate cause. Whether or not a missile system with an accurate clock might have hit the target, it is unam…
So much could go right or wrong, especially when in a war, or even when depending on technology in our households (fire alarms, replace your batteries!).
I feel "preventable deaths" is a preferable focus over "cause of death".
Re: Failed intercept at Dhahran caused by a software error in handling of timestamps
#33Despite other comments below, I think that the equivalence drawn between "failed to save" and "killed" reflects an interesting philosophical choice. I don't think that this equivalence is universally accepted, even by those who call thinking otherwise fallacious. If an EMT fails to save a victim of a car crash, did he/she kill the victim? If the dispatcher misspoke and gave the wrong cross street, delaying aid, did t…
In the medical device industry the company who made the device can be found at fault if a clinician makes a poor decision that leads to death based on a fault in the device. If the soldiers would have sought better cover or be otherwise saved in the case that there was no missile defense system was there then yes, some, if not most, of the blame lies on the software error.
Re: Failed intercept at Dhahran caused by a software error in handling of timestamps
#34Even better, the timeline: - February 11th: Vendor informed of the issue - February 25th: 28 people die because of the issue - February 26th: The vendor ships a fix I'd have loved to be a fly on the wall for that phonecall on the 25th (or early on the 26th).
Per the GAO report[0]
> According to Army officials, the delay in distributing the software from the United States to all Patriot locations was due to the time it took to arrange for air and ground transportation in a wartime environment.
I'm not knowledgeable at all on how software for missile batteries was distributed in 1991 from the US to the Persian Gulf but 11 days doesn't seem unreasonable to me.
Re: Failed intercept at Dhahran caused by a software error in handling of timestamps
#35Earlier quoted context omitted.
That's a reductio fallacy. If you want to play that game, it was being deployed to that specific place that caused their deaths. Or was it enlisting in the first place? Maybe merely having been born? This is a strictly technical examination of the proximate cause of their deaths; it makes no claims about their ultimate cause. Whether or not a missile system with an accurate clock might have hit the target, it is unam…
How so? The implication you and the article are asserting is that the clock error caused their deaths.. rather than the more accurate description "could have prevented death".
At this point we are already used to these trashy titles. There is no logic reasoning game to play; simply the bad faith in the title must be mentioned. And considering that the death of 28 persons is involved, it's in poor taste.
Re: Failed intercept at Dhahran caused by a software error in handling of timestamps
#36Earlier quoted context omitted.
I learned about it in a Decision Analysis course and had a completely different point driven home. This wasn't bad code. It was code that was correctly written to a very well defined requirement ("System shall be operational for at most X hours before a reboot"). The code was written to a spec that was approved by the customer (the military). Unfortunately though, that requirement wasn't communicated to the end users…
I'm failing to find anything that says the requirement was "System shall be operational for at most X hours before a reboot". It's more likely that there was a key performance paramater (KPP) saying that it should be functional for at least some period of time. And that was what was tested. Generally KPPs (which aren't requirements themselves, but influence the requirements for systems) are set at lower bounds, not u…
I just regurgitation about some kind of article the professor brought in.
Wikipedia didn't exist when I was taking the course. It's probably in one of the 100 odd source articles since it wasn't just my professor that pointed it out. One of the other commenters mentioned a similar discussion from one of their professors.
Re: Failed intercept at Dhahran caused by a software error in handling of timestamps
#37Earlier quoted context omitted.
You're not even curious to see how it was dealt with and how the issue was expressed to the vendor? I'd never be in a meeting regarding deaths of users of my software, because I just make internal webapps, so I just cannot help but be curious as to how one of those meetings would go.
Sure but > I'd have loved to be a fly ... loving anything about that sad scenario seems impossible.
It's a figure of speech, not a show of approval.
Re: Failed intercept at Dhahran caused by a software error in handling of timestamps
#38Little things do add up.
Re: Failed intercept at Dhahran caused by a software error in handling of timestamps
#39regarding the comments about bug killed people versus weapon killed people.
There is no 1 answer, this argument is a result of black-white/yes-no/us-them single point of blame thinking. and it's terrible.
the bug contributed to the loss of life.
Re: Failed intercept at Dhahran caused by a software error in handling of timestamps
#40Earlier quoted context omitted.
You missed this date-- Feb 21--notice goes out to users to avoid "very long run times". Users do not know what that means, and ignore warning. https://www.gao.gov/assets/220/215614.pdf (page 9) "On February 21, 1991, the Patriot Project Office sent a message to Patriot users stating that very long run times could cause a shift in the range gate, resulting in the target being offset. The message also said a software c…
That's terrible. Competent technical writing is criminally undervalued.
But there's also "presumed" and "did not think" in there. When there's a problem with your killing device you probably shouldn't use it until you've clarified what the problem is and don't just assume your end users will use it correctly.
That's like saying "It's fine, the critical vulnerability patch will be applied on reboot", while in reality all your users just suspend to disk and move that annoying reboot nag window behind the task bar where it's out of sight.