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

51–60 of 91 posts

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

#51

Post by sharemywin »

Jtsummers wrote: post #44
sharemywin wrote: post #36

Earlier quoted context omitted.

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.

Fair. I wasn't replying to you, your #1 sounds a lot like what I'm saying, though. 1. I remember hearing the system was only designed for XX operational hours but was being run over the operational spec. This is very similar to my "at least" which is very different than "at most". In requirements we wouldn't bound ourselves like that. We wouldn't say our system should run for at most 8 hours. We'd say it should run f…

The Patriot system was originally designed to operate in Europe against Soviet medium- to high-altitude aircraft and cruise missiles traveling at speeds up to about MACH 2 (1500 mph). To avoid detection it was designed to be mobile and operate for only a few hours at one location.

http://archive.gao.gov/t2pbat6/145960.pdf

Page 2

I never did embedded programming or government programming, so what your saying make sense from a spec perspective.

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

#52

Post by ajross »

leggomylibro wrote: post #48

I could be reading this wrong, but 1/3 of a second within 100 hours seems really good, like something you'd get from a temperature-controlled crystal oven. I don't mean to second-guess them in an area I know so little about, but if that was enough to cause a serious issue in the span of only a few days, shouldn't the devices be designed with a separate synchronization system, at least as a backup? Maybe GPS? Which br…

MIL-SPEC was indeed famous for overspecified components. So it's not terribly shocking that the oscillator on that board would operate really well as an isolated system. You probably don't need temperature control per se, a temperature compensation circuit could probably do that.

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

#53

Post by logfromblammo »

For doing a ballistic propagation, you apply a gravitational map in Earth-centered, Earth-fixed (ECEF) geodetic coordinates, then convert to Earth-centered rotating (ECR) geodetic coordinates, because that way you don't have to correct for the Coriolis effect. That ECEF-ECR conversion requires a time-of-day parameter.

You can use a gravitational map that only accounts for latitude, but it isn't as precise.

So using an accurate clock is really important if your intent is to hit a missile with a missile.

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

#54

Post by codazoda »

criley2 wrote: post #47

This is bad, editorialized title that is not the title of the article. Mods should change this. The "software fix" was a software patch which corrected the clocking bug. The "software workaround" to use pre-fix was reboot. I hate editorialized, lying titles :(

Came here to mention that. The title needs a re-write but the story is interesting still.

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

#55

Post by celticninja »

otoburb wrote: post #46

This was a tragic and preventable loss. It's incredible that a software bug might have been the root cause. At the time, this incident really stuck out because it broke the illusion of our fabled Patriot missile shield protecting us. Civilian expats really believed the inflated Patriot interception rates parroted to us by mainstream media and our American military expat buddies. A large number of remaining expats who…

I mean I kind of understand the attitude of the British Embassy, it wasnt like trouble flared up overnight, the option to leave was there for a long time prior to the war beginning. Obviously it isnt the fault of the children who were kept there by their parents, but some responsibility needs to be borne by the expats that decided they were getting paid well enough to stay.

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

#56

Post by sjburt »

This is a completely misleading headline. The Patriot missile was not effective at destroying the Scud [0]. The DoD initially claimed successful intercepts when the missile detonated near the Scud, but it rarely, if ever, actually destroyed the warhead. The only reason there was an illusion of success was that the Scud was also spectacularly unreliable and often broke up on re-entry or failed to detonate. It is a complete falsehood to claim that the Patriot would have prevented this loss of life.

[0] http://www.slate.com/articles/news_and_politics/war_stories/...

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

#57

Post by dragonwriter »

Jtsummers wrote: post #24
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…

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…

As I gather a the Patriot was a mobile anti-aircraft / anti-cruise missile platform that was meant to move, be activated when needed, and then be turned off and move again because the original location was expected to become a target. It was pressed, on short notice (with some software upgrades, but not the normal cycle of specs, development, and validation that would go into that kind of repurposing) into stationary, continuous coverage, anti-ballistic-missile (critically, dealing with much faster targets than originally envisioned, which means short warning times where deactivations have a lot more risk) use.

So, while it's horrible in results, it can be very easy to understand why basic functions would have specs not at all adapted to the use to which it was being put.

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

#58

Post by Jtsummers »

sharemywin wrote: post #51
Jtsummers wrote: post #44

Earlier quoted context omitted.

Fair. I wasn't replying to you, your #1 sounds a lot like what I'm saying, though. 1. I remember hearing the system was only designed for XX operational hours but was being run over the operational spec. This is very similar to my "at least" which is very different than "at most". In requirements we wouldn't bound ourselves like that. We wouldn't say our system should run for at most 8 hours. We'd say it should run f…

The Patriot system was originally designed to operate in Europe against Soviet medium- to high-altitude aircraft and cruise missiles traveling at speeds up to about MACH 2 (1500 mph). To avoid detection it was designed to be mobile and operate for only a few hours at one location. http://archive.gao.gov/t2pbat6/145960.pdf Page 2 I never did embedded programming or government programming, so what your saying make sens…

Right, but it didn't say that it was a cap on how long it should work correctly, rather it's a lower bound and also sets the maximum they tested it to. This is a design feature, but not a requirements feature, then, that it required a reboot after less than 8 hours of operations.

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

#59

Post by GCU-Empiricist »

leggomylibro wrote: post #48

I could be reading this wrong, but 1/3 of a second within 100 hours seems really good, like something you'd get from a temperature-controlled crystal oven. I don't mean to second-guess them in an area I know so little about, but if that was enough to cause a serious issue in the span of only a few days, shouldn't the devices be designed with a separate synchronization system, at least as a backup? Maybe GPS? Which br…

As a former submariner who has had used clock for inertial navigation or for similar weapons systems 1/3 of a second over 100 hours is terrible.

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

#60

Post by leggomylibro »

GCU-Empiricist wrote: post #59
leggomylibro wrote: post #48

I could be reading this wrong, but 1/3 of a second within 100 hours seems really good, like something you'd get from a temperature-controlled crystal oven. I don't mean to second-guess them in an area I know so little about, but if that was enough to cause a serious issue in the span of only a few days, shouldn't the devices be designed with a separate synchronization system, at least as a backup? Maybe GPS? Which br…

As a former submariner who has had used clock for inertial navigation or for similar weapons systems 1/3 of a second over 100 hours is terrible.

I mean, it's not an atomic clock, but I'm comparing it to the 32.768KHz RTC crystals I use with consumer microchips. If super-precise isolated accuracy were actually important, I assume they would use a rubidium or cesium oscillator.
Post reply on HN