Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Failed intercept at Dhahran caused by a software error in handling of timestamps

en.wikipedia.org

Post reply on HN
Print view View original

21–30 of 91 posts

Re: Failed intercept at Dhahran caused by a software error in handling of timestamps

#21

Post by Vivtek »

jasonmaydie wrote: post #16
rosser wrote: post #10

Earlier 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".

Well, it wasn't the missile that caused their deaths. Strictly speaking, it was the explosion of the missile.

Well, wait. It wasn't the explosion - technically, it was the impact of the pressure wave on their bodies that caused ... well, no. Really, it was the fact that their organs stopped working after impact of the ... well. If you really want to be accurate, it was the fact that metabolism ceased to be practicable after their organs stopped working.

Well, no, actually, the fact that their mental processes depended on their metabolism - that was really the cause of their... Well, no...

Re: Failed intercept at Dhahran caused by a software error in handling of timestamps

#23

Post by KindOne »

jasonmaydie wrote: post #16
rosser wrote: post #10

Earlier 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".

More technically information on the math behind the failure. http://www-users.math.umn.edu/~arnold/disasters/patriot.html

Re: Failed intercept at Dhahran caused by a software error in handling of timestamps

#24

Post by Jtsummers »

pilom wrote: post #13
clw8 wrote: post #11

Earlier quoted context omitted.

My recollection matches with yours, except I learned about it in the first week of Embedded Systems 101. If it isn't a standard part of the curriculum at every college embedded systems class, it should be! It really drove home the point that bad code can kill.

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 upper bounds, for somethnig like this. You wouldn't set a KPP: Should only work for 4 hours. You'd use: Should work for at least 3 hours, 4 hours desirable (or some similar language). If it works for longer, that's great. But longer won't be tested since it's not a requirement or goal for the system, which also means failure modes for longer runtimes won't be encountered because they're outside the bounds of the system requirements and specs.

Re: Failed intercept at Dhahran caused by a software error in handling of timestamps

#25

Post by brookside »

sli wrote: post #8
nathan_long wrote: post #7

Earlier quoted context omitted.

Oh, gosh. Really? It makes me kind of sick imagining that call.

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.

Re: Failed intercept at Dhahran caused by a software error in handling of timestamps

#26

Post by Dehstil »

michaelmrose wrote: post #19
pilom wrote: post #13

Earlier 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…

From the article "However, the timestamps of the two radar pulses being compared were converted to floating point differently: one correctly, the other introducing an error proportionate to the operation time so far" The code had a defect that effects its aim from turning it on but because it took 100 hours to drift by 1/3 of a second the problem wasn't apparent when rebooted regularly. If software can't continue to…

If by "defective" you mean has rounding errors, then sure. Everything that rounds numbers is defective. To be fair, round errors can sometimes be mitigated by carefully changing the order of operations, but never fully eliminated in those cases.

Re: Failed intercept at Dhahran caused by a software error in handling of timestamps

#27

Post by michaelmrose »

jasonmaydie wrote: post #5

The 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

People have been conditioned by using badly designed software that systems naturally drift into broken states in the course of normal operations and that having to start the system from scratch regularly is therefore very reasonable.

This just isn't so. Also the degree of acceptable reliability that is reasonable is different in a missile defense system vs the toy your grandma uses to browse facebook.

It had to be rebooted because a bug caused it to be increasingly inaccurate the longer it was booted up. This was always broken. It wasn't an acceptable fix because you manifestly can't trust users to do so as shown by the 28 corpses. It was however probably the best that could be done on short notice.

Re: Failed intercept at Dhahran caused by a software error in handling of timestamps

#28

Post by mannykannot »

jasonmaydie wrote: post #16
rosser wrote: post #10

Earlier 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".

If you are going to be pedantic, you might want to be very careful about what you write... How do you figure it would be more accurate to say that the clock error "could have prevented death?"

Re: Failed intercept at Dhahran caused by a software error in handling of timestamps

#29

Post by tntn »

Despite 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 the dispatcher kill them?

Re: Failed intercept at Dhahran caused by a software error in handling of timestamps

#30

Post by macintux »

phonon wrote: post #17
avar wrote: post #3

Even 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).

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.
Post reply on HN