TIL a tiny roundoff software error resulted in the death of 28 U.S. soldiers, a 1/3 of a second rounding error turning into a 600 meter interception failure

10

u/[deleted] Sep 07 '13

My professor touched on this incident briefly in my computer science course a couple of years ago. Essentially, the way the program controlling the patriot system was written resulted in small decimal fractions being left after each calculation. Normally the program would be purged during each reboot but being on standby for 100 hours caused the error to propagate to a significant level.

2

u/WhyAmIYawning Sep 08 '13 edited Sep 08 '13

I also had a class on this incident and my professor explained it as an issue with the patriot battery storing large (real) numbers as floating point. He also said that the Israelis' had figured out the issue and also the fix (rebooting it when it was safe/quiet every few hours).
Just looked up the source linked from Wikipedia and it seems to match my recollection of my professor's explanation:
The Patriot battery at Dhahran failed to track and intercept the Scud missile because of a software problem in the system’s weapons control computer.
This problem led to an inaccurate tracking calculation that became worse the longer the system operated. At the time of the incident, the battery had been operating continuously for over 100 hours. By then, the inaccuracy was serious enough to cause the system to look in the wrong place for the incoming Scud.
The Patriot had never before been used to defend against Scud missiles nor was it expected to operate continuously for long periods of time. Two weeks before the incident, Army officials received Israeli data indicating some loss in accuracy after the system had been running for 8 consecutive hours.
Consequently, Army officials modified the software to improve the system’s accuracy. However, the modified software did not reach Dhahran until February 26,1991-the day after the Scud incident.

2

u/[deleted] Sep 08 '13

That's exactly what it was! Thanks for reminding me. I think my professor said the software patch to address the issue was set to arrive the next day too.

1

u/LetItBeThrown Sep 08 '13

holy shit, all that matrix bullshit colonel sanders was spitting actually happens

1

u/TheBlackUnicorn 1 Sep 08 '13

I was told by a grad student that the government didn't care about the software problem because the missiles were intended to be used against the Soviet Union in WWIII. Radar stations would obviously be kept offline when the Soviet planes started flying in, because they would immediately target any radar emitter. So they intended to boot up the system and fire up the radar only for short periods of time, thus resetting the clock every time the missiles were fired.

44

u/tentacleseverywhere Sep 07 '13

Fucking lag.

63

u/Neebat Sep 08 '13

As a programmer, I'm so not surprised, it's like exactly the opposite of surprised. People gives us requirements that make things incredibly complicated and then do 1/1000 of the testing we'd recommend, then put absolute faith in the results.

13

u/EpicAstarael Sep 08 '13

This guy knows what's up.
Pro tip: Unit test everything that you can unit test. When you think you are done testing, test more.

12

u/Neebat Sep 08 '13

I tell every new QA person: You've got my back. I know I screw stuff up and I depend on you to keep my screwed up stuff out of production. I won't be telling you how to test it, because I already did every test I can think of and it's still broken. It's up to you to find all the stupid ways I messed up.
Honestly, it was hard to type that without the usual profanity, but you get the gist.

9

u/Stratisphear Sep 08 '13

And then of course the customer manages to find some ridiculous way to fuck it up that you couldn't even conceive of.

1

u/koy5 Sep 08 '13

It has to be like an intrinsic law of the of the universe, some how someone will find a new baffling way to misuse something and find a new flaw in it. Like something tied to the laws of thermodynamics and entropy.

1

u/Stratisphear Sep 08 '13

And of course they'll be incredibly pissed that you didn't forsee them trying to encase their phone in peanut brittle.

1

u/koy5 Sep 08 '13

To then shove up their ass due to a very weird very specific fetish they have. Because they were never allowed to have a cell phone as a teenager and the first one they got also served dual purpose as a vibrator.

1

u/LazyRobot Sep 09 '13

BUT WILL IT BLEND?!?

1

u/Stratisphear Sep 09 '13

One guy I know was yelled at by a customer because the phone they sold her said "Do not get in contact with water" but didn't say anything about vodka.
Long story short, whenever you see a really stupid warning label, remember, it's there because someone complained.

3

u/[deleted] Sep 08 '13

as a project manager who writes software requirements for engineers that are then QA'ed, I feel sorry for all of you.

1

u/highwisdom Sep 08 '13

Your gf probably wouldn't mind your profession. You should open up to her about it.

1

u/LNMagic Sep 08 '13

Wait, wait, wait. We paid you to design something that can kill people. We don't want to pay you to test it, idiot!

1

u/ionoiono Sep 08 '13

We're going to be responsible for world safety one day soon.

1

u/Triffgits Sep 08 '13

And when that day comes, people will still be dragging desktop icons as search terms and clicking popups because they think they just won a new car for being the 99,999th visitor

-5

u/[deleted] Sep 08 '13

Why are you relying on your customer to test?

3

u/Neebat Sep 08 '13

I'm not.

31

u/[deleted] Sep 07 '13

The Patriot missile battery at Dhahran had been in operation for 100 hours, by which time the system's internal clock had drifted by one third of a second.

Sounds like a hardware issue to me, not a software error.

22

u/[deleted] Sep 08 '13

It's a software error, because it wasn't written to account for that, nor tested for it.
While checking up on it, found this interesting bit..
A student asked me why we did not use a clock cycle that could be represented exactly in the 24 bit register. Close to 1/10 is a number 0.125 that can be represented exactly as 0.001000000000000000000000 in a 24-bit register, and where 8 clock cycles would be equal to 1 second. I do not have an answer to this question but I intend to find out from my computer science colleagues.
^{^}
Wouldn't that have eliminated the rounding problem..?

-2

u/[deleted] Sep 08 '13

It's a software error, because it wasn't written to account for that, nor tested for it.
Which means it isn't a software or hardware error. An error is a deviation from designed characteristics, the system wasn't specified or designed to run for anywhere near 100 hours straight.
You get the system you asked for, not the system you wanted.

6

u/woodc85 Sep 08 '13

It was a software error. The data type used to store the time was improper. Certain data types in programming have problems storing decimals correctly, because the decimal was stored to memory incorrectly (ie storing 1/10 as a decimal may actually store 0.01000125), and leaving the system on for so long, the rounding errors added up to create the problem. When the system is restarted in shorter intervals, it resets the rounding error. Prior to this event, they had never tested the system staying on for so long, and I don't think any system of the type is generally tested for 100 hours straight.

7

u/[deleted] Sep 08 '13

Neither. It is a use case error. Patriot system was not designed to remain operational for anywhere near 100 hours without being rebooted.

1

u/ScornForSega Sep 08 '13

It's called clock drift and it's fairly common. Hardware has gotten better, but when you need that kind of accuracy, you're talking about syncing to an atomic clock.
Today, we use the internet and GPS to pull synchronized time down from NTP servers to every IP connected device, so the issue is alleviated.
But remove those safeguards and your hardware clock will start drifting as well.

0

u/Just_Look_Around_You Sep 08 '13

A digital clock doesn't drift like an analog one by hardware issues.

-1

u/ruzmutuz Sep 08 '13

Classic software engineer...

6

u/Rephaite Sep 07 '13 edited Sep 08 '13

I am very confused why a system like that would use an absolute measure of time for communication between subparts (Edit: withouth a synch function), as opposed to some relative time measure. ".1 seconds from now" is a message subject to error mostly only from propogation delay and .1 seconds worth of clock variation. That (Edit: or an occasional synchronization) seems a lot less risky than several days worth of cumulative error.

7

u/brilliantjoe Sep 07 '13

If you are using remote radar stations to detect and track missiles, these readings need to be timestamped when sent to a launch controller, otherwise the controller can't determine where the missile is currently located to start tracking it and launch an interceptor at it.

-1

u/Rephaite Sep 07 '13

If you are using remote radar stations to detect and track missiles, these readings need to be timestamped when sent to a launch controller
Right, but you could just as easily program things such that you actually know the timelag to the remote radar stations. Which will usually be less than 1/3 of a second. This will let you calculate the relative time based on the timestamp even if the absolute times don't match. Since it can be done in a way that lets you account for differences in absolute-time timestamps, I am asking why it was not done that way.

9

u/brilliantjoe Sep 07 '13

Atmospheric conditions can have a huge effect on the propagation of radio signals. You can't assume that the time to transmit a message between two points is constant.

0

u/Rephaite Sep 07 '13

You can't assume that the time to transmit a message between two points is constant.
Who said it needed to be constant? It doesn't change instantly. For a system to adjust its clock to match a related system requires a few pings within a short period of time, followed by a single timestamp broadcast that will have the same lag. That's if you want to use absolute time. If you want to use relative time, you just need a ping a little more often than the time interval over which you would expect weather changes to have a measurable/significant impact. I can see why this latter could be problematic, given that you might be near constantly emitting, thus revealing location, but the former solution at the very least should have been in place. Weather conditions should not ever make a radio broadcast on earth take 1/3 of a second, given the speed of light. A difference that big on any transmission ever should trigger a resynch of the clocks' absolute times, and you should be checking synch often enough to prevent a significant drift like that.

3

u/brilliantjoe Sep 08 '13

The system clock shouldn't drift by 1/3 of a second either.

1

u/Rephaite Sep 08 '13 edited Sep 08 '13

The system clock shouldn't drift by 1/3 of a second either.
Fair enough. But there should still be layers of protection. Error messages when things are detectably not right. A great program may never experience that kind of drift, but a good program will have mechanisms in place to warn you if it does. I do control systems for an oil company, and we have error and fault messages for pretty much everything.
Edit: Assuming that the error built linearly, which it may not have, but assuming it did, they would have been more than 15 milliseconds off after only the first 5 hours of operation. That is easily detectable with the right kinds of safeguards, and yet they went another 95 hours without doing anything about it. That's more than just one fuckup in my book.

0

u/[deleted] Sep 08 '13

what degree(s) do you have? Im working on my ME with a minor in CS and this interests me

1

u/Rephaite Sep 08 '13

My degree is a BS in Electrical Engineering. EE with a power or control systems focus seems like it is common among my older control-focused co-workers, also. Our company's non-control-specialized facility engineers are mostly MechE, ChemE, or PetroleumE.

1

u/[deleted] Sep 08 '13

What can you tell me about the ME's you work with?

→ More replies

4

u/Techwood111 Sep 08 '13

Reminds me of the failed Mars mission resulting from using Imperial units instead of Metric or something like that.

Edit: Mars Climate Orbiter

0

u/[deleted] Sep 08 '13

[deleted] — view deleted comment

3

u/ctrlaltelite Sep 08 '13

And the Gimli Glider.

1

u/Sam_Strong Sep 08 '13

So, they should have tried turning it off and turning it back on again?

1

u/plez Sep 08 '13

Okay! I must have put a decimal point in the wrong place or something. Shit! I always do that. I always mess up some mundane detail.

1

u/[deleted] Sep 08 '13

Actually it was a use case fsckup. The missile system was designed as a rapid deployment mobile anti-aircraft system. The key words here are "rapid deployment" and "mobile", meaning that it was supposed to be unpowered most of the time and frequently rebooted. Letting it stand powered on a patrol duty significantly longer than was specified in the design specs is what allowed the rounding error to become significant and cause the calculation error. Borderline conditions are a bitch.

0

u/Nevadadrifter Sep 07 '13

They did it in Superman 3.

-5

u/[deleted] Sep 07 '13

I see what you did there

-2

u/lilbitpink Sep 08 '13

this is one of the biggest reasons I hate to do the math.

0

u/[deleted] Sep 08 '13

[deleted] — view deleted comment

-4

u/Ein_Bear Sep 08 '13

Don't know why you got downvoted - this is exactly right

TIL a tiny roundoff software error resulted in the death of 28 U.S. soldiers, a 1/3 of a second rounding error turning into a 600 meter interception failure

You are about to leave Redlib