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

11–20 of 91 posts

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

#11

Post by clw8 »

sharemywin wrote: post #4

I remember hearing about this in my numerical analysis class. 1. I remember hearing the system was only designed for XX operational hours but was being run over the operational spec. 2. The time was stored in base 10 so the calculation errors added up over time or something like that so if they had used some base 2 timing scheme it would haven't have had issues with rounding errors. My class was in the mid nineties s…

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.

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

#12

Post by nerpderp83 »

bertjk wrote: post #9

I've often wondered, considering the supposed low accuracy of Scud missiles, (wiki gives it a CEP of 450m) how much of the casualties from that incident were more due to the bad luck of the missile actually hitting its target.

If the Scud had been brought down earlier in it's trajectory it would have not been near people regardless of any randomness in it's landing.

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

#13

Post by pilom »

clw8 wrote: post #11
sharemywin wrote: post #4

I remember hearing about this in my numerical analysis class. 1. I remember hearing the system was only designed for XX operational hours but was being run over the operational spec. 2. The time was stored in base 10 so the calculation errors added up over time or something like that so if they had used some base 2 timing scheme it would haven't have had issues with rounding errors. My class was in the mid nineties s…

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.

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

#14

Post by [deleted] »

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.

[deleted]

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

#15

Post by dnautics »

bertjk wrote: post #9

I've often wondered, considering the supposed low accuracy of Scud missiles, (wiki gives it a CEP of 450m) how much of the casualties from that incident were more due to the bad luck of the missile actually hitting its target.

many of the scuds "broke up in flight" or otherwise malfunctioned, too, so the actual effectiveness of patriot has been called into question.

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

#16

Post by jasonmaydie »

rosser wrote: post #10
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

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

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

#17

Post by phonon »

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 change was being sent that would improve the system’s targeting. However, the message did not specify what constitutes very long run times. According to Army officials, they presumed that the users would not continuously run the batteries for such extended periods of time that the Patriot would fail to track targets. Therefore, they did not think that more detailed guidance was required."

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

#18

Post by KindOne »

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

I've seen clock drift first hand. I have an old Windows XP machine that would drift ahead about 3-30 seconds an hour while watching YouTube with Adobe flash. Playing video games, compiling gcc and other things in cygwin (hell) would not drift.

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

#19

Post by michaelmrose »

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…

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 do basic math without manual intervention its defective.

In fact everyone including the company that made it admits it's defective.

Its possible your teacher picked a great example to illustrate a communication failure.

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

#20

Post by euyyn »

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

It would depend on whether they were relying on it to work or not.
Post reply on HN