8 ms·

Patriot missile software failure, 28 soldiers died. Fix: reboot the system

110 points by bl4k 16y ago

patio11 16y ago
This was covered in our C classes in college, and it is probably more interesting for programmers here if you understand what the bug actually was. The "software error" Wiki alludes to is that the Patriot missile kept track of its internal clock with floating point numbers. When the machine had been booted in the recent past, such as every time in testing, the floating point number spent most of its precision to the right of the decimal point. This let it able to do the designed behavior, which was calculate very small delta(time) to be able to do velocity/position calculations and get fairly close to fast moving objects then go boom. The problem is that floating point numbers have a limited amount of precision available to them, and if you are using a few billion milliseconds (2 weeks), almost all of your precision is lost to the left of the decimal point (and, given that this is precision-intensive work, you didn't need to wait that long to see anomalies). Lower precision meant that taking delta(time) got increasingly less precise as time went on. Which meant that velocity/position calculations got progressively more screwed up. Which meant the missile did not go boom in the general vicinity of incoming missiles. Which killed Americans and allies. Thus the moral of the lecture: a) your computer is a powerful, tricksy beast which has many ways to trap you in even straightforward code and b) you should treat software quality like some 19 year old's life depends on it, because it might.
- ars 16y ago
  Do you know how they fixed it? I can think of a few ways, but I'm curious which they used.
- bl4k 16y ago
  I thought that the experience of developing the GPS network (where all the sattelites and ground stations must be time co-ordinated to within 10+ decimal places in seconds) would have helped them with this missile system. A GPS satellite travels much faster than a missile, and is accurate to within meters, so the tolerances are much higher (and the system was designed prior to patriot). There is a definite 'not invented here' syndrome amongst defense contractors - I doubt they share any information, research or solutions amongst one other, which means the US tax payer foots the bill each time one of these contractors must independently develop and implement a system that has likely already been built in another part of defense.
  - some1else 16y ago
    Oh, Interesting. I always figured GPS satellites were geo-stationary, but in fact (as you pointed out), they travel at 7000 mp/h :-0
    - pmjordan 16y ago
      Geostationary orbits would tie the satellites to being directly above the equator, which (a) would prevent the system from working beyond a certain latitude and (b) would cause an extremely bad distribution of "visible" satellites and angles between signals, precision would suffer.
      - kiujygtyujik 16y ago
        Not to mention the transmitter power you would need if they were 25,000miles away in GSO rather than 90mi away in LEO
        chrisbolt 16y ago
        GPS satellites are actually in MEO, at 12,500 miles away. http://en.wikipedia.org/wiki/Medium_Earth_orbit http://en.wikipedia.org/wiki/Medium_Earth_orbit
    - tetha 16y ago
      Note that while you sit on your chair, you are travelling pretty fast. Relativity for the win!
  - weaksauce 16y ago
    I would wager that some of the NIH syndrome is due to top secret requirements and blackops development that makes things tough to get at source code for other systems.
  - rdtsc 16y ago
    > There is a definite 'not invented here' syndrome amongst defense contractors Yes. Especially because of contractors. A defense contractor is not going to its competitors in order to reveal and exchange know-how. That know-how is a trade secret that gives them competitive advantage. Except that in this case, lack of sharing results in making the same mistake multiple times, which results in loss of human life. Interestingly lately I have observed that the government is trying to tighten up its defense spending belt and there is a tendency to develop more in-house rather than contract out. In order to gain public support the Congress keeps voting to increase the salary of service personnel. That leaves less money to spend on contracting out. So perhaps we'll see more sharing in the future at least between DoD's own projects.
- some1else 16y ago
  It's truly remarkable how nobody cared to attend to the bug report about the drift, given that they are in the business of making missile pilot software, and it turned out they can issue a patch in one day. My teachers didn't have such a terrifying example at hand (they emphasize it with financial calculations), yet I still remember the issue and consider it when necessary. Poor QA :-S
- losethos 16y ago
  Does a video game demand the same quality as life support? A double float time since boot is handy. God's right here. He's listening to you. You know that, right? maintain discipline seated us overcoming groves went Predicaments exhort vein parity hereafter teeming feverishness angels altogether strongly vanities profit pronouncing rare Despite advance shone senseless plainness indigested tender figurative reproof Catechumen Augustine
- davidw 16y ago
  > you should treat software quality like some 19 year old's life depends on it, because it might. You should treat it like that if someone's life does depend on it and you have the resources to develop accordingly. If you're developing something like, say, bingo software, you're probably better off devoting time to improving the product or marketing it, rather than working on it being 100% bug free. It's all a tradeoff - time spent on eliminating every last little bug is time not spent on adding features or making it faster or marketing it or whatever. Edit somewhat less clear-cut cases might be bits of software that you release publicly, and subsequently get used for life-critical systems. However, in that case, the onus is on those adapting the code for use in that environment to provide the testing/review/etc... rather than blaming the upstream developer.
  - extension 16y ago
    That approach works if you know exactly what applications your code will ever be used for. If you are writing a library or a compiler or anything that will potentially be reused by unknown 3rd parties, then you can't be sure just how critically it will be put to use. There is no certification to distinguish software that lives can depend on. That doesn't mean it's your fault if someone uses your free XML parser in an amusement park ride and your bug makes it fly off the rails. But I still wouldn't feel very good about it and would like to do everything I can to avoid it. Also, when it comes time for you to write life or death code, it would be good if you already knew how to meet the required quality standard.
    - davidw 16y ago
      You seem to have written this after my edit, which addresses that point. I'd feel bad too, but I'd feel bad if I had to hire a team of coders to review every line of my open source projects and document any change: > "At the on-board shuttle group, about one-third of the process of writing software happens before anyone writes a line of code. NASA and the Lockheed Martin group agree in the most minute detail about everything the new code is supposed to do -- and they commit that understanding to paper, with the kind of specificity and precision usually found in blueprints. Nothing in the specs is changed without agreement and understanding from both sides. And no coder changes a single line of code without specs carefully outlining the change. Take the upgrade of the software to permit the shuttle to navigate with Global Positioning Satellites, a change that involves just 1.5% of the program, or 6,366 lines of code. The specs for that one change run 2,500 pages, a volume thicker than a phone book. The specs for the current program fill 30 volumes and run 40,000 pages." From: http://www.fastcompany.com/node/28121/print http://www.fastcompany.com/node/28121/print If there's no certification for ready-made life critical components, then that means the burden of reviewing, checking and verifying everything in the system is on whoever wants to use it in a life-critical environment.
- extension 16y ago
  A potentially more specific moral in this case is "beware of floating point numbers". Don't use them unless you really, really understand how they work, or if you are using them in a very conventional way, like with 3D graphics. Inexperienced programmers often regard FP as magical numbers that do everything. It doesn't help that programming languages like JavaScript essentially treat them as such.
  - gaius 16y ago
    See, there've been guided missiles since the 1950s. There'll be 60-something old geezers at Raytheon who have done missiles their whole careers, 30-40 years, and they would have been apprenticed to the previous generation of old geezers who had merely done missiles most of their careers. These guys should know this stuff by now. Fatal errors are almost never a single thing going wrong unpredictably - they're a chain of events leading to an inexorable conclusion. Root cause - where were these guys? It is possible to get this right: http://en.wikipedia.org/wiki/Sea_Dart_missile#Gulf_War_.281991.29 http://en.wikipedia.org/wiki/Sea_Dart_missile#Gulf_War_.2819...
    - azernik 16y ago
      The problem is, they never had to deal with software engineering; my mom, who served in the Israeli Navy in the late 70s, told me horror stories about the ship-to-ship guided missiles they dealt with. They were essentially analog electronics - addition done by adding voltages, for example - with error creeping in at every component. The way I remember her telling it, something like 30% to 60% of the things were down at any given time because some analog multiplier or adder had an error that was just a little bit too large. No one in the field was even thinking about software bugs at that point. The reliable (and programmable) digital electronics were originally developed for ICBMs in the 60s, and only after quite a bit of miniaturization were they available for smaller guided missiles, meaning that there wasn't quite as much institutional experience of software engineering among guided missile designers as you'd think.
      - varjag 16y ago
- dagw 16y ago
  Moral c) The floating point numbers you use when programming computers are fundamentally very different from the numbers you'll see in math class. Any assumption that computer numbers and math numbers behave the same will eventually lead to bugs.
- joegaudet 16y ago
  I thought the issue was due to the binary representation of numbers like 0.1, 0.01, 0.001 being in fact non terminating fractions ala: 1/3 thus the longer the system ran the more small amounts of round off error it accumulated but adding two incomplete fractions. I seem to remember this being the case in my numeric methods course, but maybe that was a different systme.
- jacquesm 16y ago
  There's an in-joke amongst embedded systems programmers, which is that if you need floating point you don't fully grok the problem (yet). Floats are subtle, they can have exactly the kind of nasty little side effects that you overlook during testing and that bite you in a terrible way once you hit production. Fixed point is the way to go to implement stuff like this, floating point is asking for trouble. Of course floating point is more convenient, but most people that use it don't really understand what's going on under the hood, and most of the time they don't need to. But bank balances, clock values, GPS coordinates and other values of some importance are best represented in fixed point format. You'll have to do a bit more work when manipulating them but that pays off in reliability.
  - jpr 16y ago
    Is there really any place where floating point is the right solution or default? I mean, all general purpose languages generally use floating point, but for general purposes, floating point isn't what you want. Or maybe it is, but it certainly isn't what I want.
- pvg 16y ago
  the Patriot missile kept track of its internal clock with floating point numbers It didn't, really, and the bug itself is more convoluted than the loss of precision you are describing. See the references: http://www.mc.edu/campus/users/travis/syllabi/381/patriot.htm http://www.mc.edu/campus/users/travis/syllabi/381/patriot.ht... and http://www.fas.org/spp/starwars/gao/im92026.htm http://www.fas.org/spp/starwars/gao/im92026.htm
- slavak 16y ago
  This baffles me. Did the software engineers creating this not take a course on numerical analysis in college? Or were those, as so often are, electrical engineers that had been hired to do software work? The amount of misunderstanding in the industry about what it takes to create mission-critical software is incredible.
  - assemble 16y ago
    Trust me, most of us EEs know -plenty- about floating point problems. We also have to take entire classes about how our work could kill somebody. Bugs are bugs, errors and oversights happen. You have to deal with it, document what happened, and be vigilant to make sure it never happens again.
stretchwithme 16y ago
Interesting how complex it is to determine the accuracy of the missiles. Multiple Patriot missiles fired at each Scud, several possible outcomes, the Scud can break apart making multiple targets for the Patriots.
- patio11 16y ago
  I agree, though "We got the missile but missed the warhead. That has to count for something." strikes me as a little off. Pretend Saddam Hussein has ordered his team of crack experts to use crappy engineering as an active countermeasure. They just beat you. Do better.
  - Anechoic 16y ago
    One of my college professors was an outspoken opponent of missile defense systems (and the Patriot system specifically) that worked during the missile's reentry/descent phase. His objection is that it's too easy for an opponent to defeat the system either by overwhelming it (MIRVs for instance) or by designing the reentry vehicle to make random movements which would make it really difficult for a intercepter to track. Even if the interceptor can hit it, it's more likely to knock the warhead off course instead of destroying it. If a nuclear missile is aimed at NY and an interceptor hits it so that it falls to Philly instead, that's still a net loss. Saddam inadvertently hit upon the both methods - his engineers tried to improve on the Soviet scud design to give them more range (which they were successful at) but their improvements made the missile more likely to break up on reentry (which presented more targets than the tracking radar anticipated) and the lack of aerodynamics of the resulting pieces (including the warhead) the missiles fall in unpredictable ways which caused tracking problems. An opponent that actually tried to game the system could make his missiles more difficult to hit. The professor is advocating for boost-phase missile defense since the missile movements are much more predicable.
    - jacquesm 16y ago
      But it makes for more defense spending. If you catch something on the launchpad that's a relatively low expense, to catch it i in flight you need to actively defend each and every possible target and a lot of sexy hardware to do so.
dotBen 16y ago
Imagine being the developer who wrote the line of code (who didn't understanding floating point variables). Or the QA tester who didn't spot it, or didn't decide it was worth reporting. Aside from being a pacifist, this is why a number of engineer friends have stepped out of building defense systems (including missile guidance systems) and into more civilian engineering because the stress and moral burden is just too great.
- extension 16y ago
  Better than being the executive who decided not to release the patch until 28 people were dead.
  - viraptor 16y ago
    As long as the workaround was known, well... I don't know exactly what the military procedures are for situations like that, but updating an active rocket defence system in area where you don't necessarily have trained engineers -vs- rebooting it every day or so to make sure it works. It looks like a simple choice to me. Also looking at who actually makes the mistake - if someone gives you an update and the system fails, they're at fault. If you give clear instructions for operation and users don't follow it...
    - extension 16y ago
      According to Wikipedia, the workaround came from the Israeli army, who found the bug, not the manufacturer. The instructions for this workaround did not propogate clearly and thus weren't followed. Being defenseless for a few minutes every day during a reboot hardly seems like a reasonable fix anyway, especially if it becomes standard procedure that your enemy may learn about. The fact that the manufacturer did release a patch, rather than a workaround, the day after the accident suggests that this was indeed the safest course of action. It was just taken too late.
nitfol 16y ago
More information about the errors in the (fixed point) math on the patriot: http://www.ima.umn.edu/~arnold/disasters/patriot.html http://www.ima.umn.edu/~arnold/disasters/patriot.html
- joshzayin 16y ago
  That's interesting. Given that it was an issue with a non-terminating binary representation, what would be the way to handle this, without somehow resetting the clock (restart or otherwise)? Obviously, you could, in a modern system, have more memory and be able to store more bits of the number, but there would still be a limit that you would run into after some amount of time that would cause similar problems.
  - tetha 16y ago
    I'm just thinking about this. I think I would try to split the clock into a precise part, which (for example) tracks how many milliseconds we are into an hour and a precise part which stores the hours, or the date up to the hours or whatever. Given this, I can reset the part with the degrading accuracy in a duration which maintains enough accuracy in order to maintain enough accuracy overall.
Natsu 16y ago
I find it interesting how "just reboot" has become something of a user expectation: often, users expect it to fix most anything. To be fair, it does seem to work fairly often. It's a strong enough expectation that when I had some industrial machines running DOS (albeit on more modern hardware), I added my update, backup & diagnostic scripts to autoexec.bat so that rebooting would fix most of their problems. It made my life a lot easier, though, because I could update the files and configurations via a master copy on the network, then tell them to reboot everything whenever it was convenient for them (usually between shifts) and the machines would all grab their updates and upload some log files for me to monitor.
viraptor 16y ago
I wonder how did they actually find out the reason for the failure? They had a system which worked perfectly (almost) and probably could be tested in every standard way without showing the problem. They must've had a seriously good logging system that showed something suspicious, or someone had a really interesting "a-ha" moment... I'd like to hear the story of debugging this one. Also how they managed to identify that this incident was caused by that specific bug.
dRother 16y ago
Sure, rebooting is often the most straightforward way to fix runtime issues because it resets everything. In this case, sounds like resetting the clock would have been just as effective. I'm sure these days, you'd have something like the equivalent of a ntpd update every hour to take care of that.
daemin 16y ago
I seem to recall reading somewhere that the system was originally designed to be a mobile platform against Soviet missiles in somewhere like west Berlin. Where they needed something that would be moved around every day or two so that the enemy would not know its location. That meant that the system would be reset whenever it was moved, and therefore using a floating point clock was a reasonable design trade off.
duncanj 16y ago
The really interesting lesson that engineers have learned from the Patriot is that "never reboot" might not be the best target for critical systems. Rather, controlled rebooting can help clean up problems before they affect the function of the system. http://portal.acm.org/citation.cfm?id=1251254.1251257 http://portal.acm.org/citation.cfm?id=1251254.1251257 http://www.computer.org/portal/web/csdl/doi/10.1109/HOTOS.2001.990072 http://www.computer.org/portal/web/csdl/doi/10.1109/HOTOS.20...

110 points by bl4k 16y ago

This was covered in our C classes in college, and it is probably more interesting for programmers here if you understand what the bug actually was. The "software error" Wiki alludes to is that the Patriot missile kept track of its internal clock with floating point numbers. When the machine had been booted in the recent past, such as every time in testing, the floating point number spent most of its precision to the right of the decimal point. This let it able to do the designed behavior, which was calculate very small delta(time) to be able to do velocity/position calculations and get fairly close to fast moving objects then go boom. The problem is that floating point numbers have a limited amount of precision available to them, and if you are using a few billion milliseconds (2 weeks), almost all of your precision is lost to the left of the decimal point (and, given that this is precision-intensive work, you didn't need to wait that long to see anomalies). Lower precision meant that taking delta(time) got increasingly less precise as time went on. Which meant that velocity/position calculations got progressively more screwed up. Which meant the missile did not go boom in the general vicinity of incoming missiles. Which killed Americans and allies. Thus the moral of the lecture: a) your computer is a powerful, tricksy beast which has many ways to trap you in even straightforward code and b) you should treat software quality like some 19 year old's life depends on it, because it might.

ars 16y ago
Do you know how they fixed it? I can think of a few ways, but I'm curious which they used.
bl4k 16y ago
I thought that the experience of developing the GPS network (where all the sattelites and ground stations must be time co-ordinated to within 10+ decimal places in seconds) would have helped them with this missile system. A GPS satellite travels much faster than a missile, and is accurate to within meters, so the tolerances are much higher (and the system was designed prior to patriot). There is a definite 'not invented here' syndrome amongst defense contractors - I doubt they share any information, research or solutions amongst one other, which means the US tax payer foots the bill each time one of these contractors must independently develop and implement a system that has likely already been built in another part of defense.
- some1else 16y ago
  Oh, Interesting. I always figured GPS satellites were geo-stationary, but in fact (as you pointed out), they travel at 7000 mp/h :-0
  - pmjordan 16y ago
    Geostationary orbits would tie the satellites to being directly above the equator, which (a) would prevent the system from working beyond a certain latitude and (b) would cause an extremely bad distribution of "visible" satellites and angles between signals, precision would suffer.
    - kiujygtyujik 16y ago
      Not to mention the transmitter power you would need if they were 25,000miles away in GSO rather than 90mi away in LEO
      - chrisbolt 16y ago
        GPS satellites are actually in MEO, at 12,500 miles away. http://en.wikipedia.org/wiki/Medium_Earth_orbit http://en.wikipedia.org/wiki/Medium_Earth_orbit
  - tetha 16y ago
    Note that while you sit on your chair, you are travelling pretty fast. Relativity for the win!
- weaksauce 16y ago
  I would wager that some of the NIH syndrome is due to top secret requirements and blackops development that makes things tough to get at source code for other systems.
- rdtsc 16y ago
  > There is a definite 'not invented here' syndrome amongst defense contractors Yes. Especially because of contractors. A defense contractor is not going to its competitors in order to reveal and exchange know-how. That know-how is a trade secret that gives them competitive advantage. Except that in this case, lack of sharing results in making the same mistake multiple times, which results in loss of human life. Interestingly lately I have observed that the government is trying to tighten up its defense spending belt and there is a tendency to develop more in-house rather than contract out. In order to gain public support the Congress keeps voting to increase the salary of service personnel. That leaves less money to spend on contracting out. So perhaps we'll see more sharing in the future at least between DoD's own projects.
some1else 16y ago
It's truly remarkable how nobody cared to attend to the bug report about the drift, given that they are in the business of making missile pilot software, and it turned out they can issue a patch in one day. My teachers didn't have such a terrifying example at hand (they emphasize it with financial calculations), yet I still remember the issue and consider it when necessary. Poor QA :-S
losethos 16y ago
Does a video game demand the same quality as life support? A double float time since boot is handy. God's right here. He's listening to you. You know that, right? maintain discipline seated us overcoming groves went Predicaments exhort vein parity hereafter teeming feverishness angels altogether strongly vanities profit pronouncing rare Despite advance shone senseless plainness indigested tender figurative reproof Catechumen Augustine
davidw 16y ago
> you should treat software quality like some 19 year old's life depends on it, because it might. You should treat it like that if someone's life does depend on it and you have the resources to develop accordingly. If you're developing something like, say, bingo software, you're probably better off devoting time to improving the product or marketing it, rather than working on it being 100% bug free. It's all a tradeoff - time spent on eliminating every last little bug is time not spent on adding features or making it faster or marketing it or whatever. Edit somewhat less clear-cut cases might be bits of software that you release publicly, and subsequently get used for life-critical systems. However, in that case, the onus is on those adapting the code for use in that environment to provide the testing/review/etc... rather than blaming the upstream developer.
- extension 16y ago
  That approach works if you know exactly what applications your code will ever be used for. If you are writing a library or a compiler or anything that will potentially be reused by unknown 3rd parties, then you can't be sure just how critically it will be put to use. There is no certification to distinguish software that lives can depend on. That doesn't mean it's your fault if someone uses your free XML parser in an amusement park ride and your bug makes it fly off the rails. But I still wouldn't feel very good about it and would like to do everything I can to avoid it. Also, when it comes time for you to write life or death code, it would be good if you already knew how to meet the required quality standard.
  - davidw 16y ago
    You seem to have written this after my edit, which addresses that point. I'd feel bad too, but I'd feel bad if I had to hire a team of coders to review every line of my open source projects and document any change: > "At the on-board shuttle group, about one-third of the process of writing software happens before anyone writes a line of code. NASA and the Lockheed Martin group agree in the most minute detail about everything the new code is supposed to do -- and they commit that understanding to paper, with the kind of specificity and precision usually found in blueprints. Nothing in the specs is changed without agreement and understanding from both sides. And no coder changes a single line of code without specs carefully outlining the change. Take the upgrade of the software to permit the shuttle to navigate with Global Positioning Satellites, a change that involves just 1.5% of the program, or 6,366 lines of code. The specs for that one change run 2,500 pages, a volume thicker than a phone book. The specs for the current program fill 30 volumes and run 40,000 pages." From: http://www.fastcompany.com/node/28121/print http://www.fastcompany.com/node/28121/print If there's no certification for ready-made life critical components, then that means the burden of reviewing, checking and verifying everything in the system is on whoever wants to use it in a life-critical environment.
extension 16y ago
A potentially more specific moral in this case is "beware of floating point numbers". Don't use them unless you really, really understand how they work, or if you are using them in a very conventional way, like with 3D graphics. Inexperienced programmers often regard FP as magical numbers that do everything. It doesn't help that programming languages like JavaScript essentially treat them as such.
- gaius 16y ago
  See, there've been guided missiles since the 1950s. There'll be 60-something old geezers at Raytheon who have done missiles their whole careers, 30-40 years, and they would have been apprenticed to the previous generation of old geezers who had merely done missiles most of their careers. These guys should know this stuff by now. Fatal errors are almost never a single thing going wrong unpredictably - they're a chain of events leading to an inexorable conclusion. Root cause - where were these guys? It is possible to get this right: http://en.wikipedia.org/wiki/Sea_Dart_missile#Gulf_War_.281991.29 http://en.wikipedia.org/wiki/Sea_Dart_missile#Gulf_War_.2819...
  - azernik 16y ago
    The problem is, they never had to deal with software engineering; my mom, who served in the Israeli Navy in the late 70s, told me horror stories about the ship-to-ship guided missiles they dealt with. They were essentially analog electronics - addition done by adding voltages, for example - with error creeping in at every component. The way I remember her telling it, something like 30% to 60% of the things were down at any given time because some analog multiplier or adder had an error that was just a little bit too large. No one in the field was even thinking about software bugs at that point. The reliable (and programmable) digital electronics were originally developed for ICBMs in the 60s, and only after quite a bit of miniaturization were they available for smaller guided missiles, meaning that there wasn't quite as much institutional experience of software engineering among guided missile designers as you'd think.
    - varjag 16y ago
dagw 16y ago
Moral c) The floating point numbers you use when programming computers are fundamentally very different from the numbers you'll see in math class. Any assumption that computer numbers and math numbers behave the same will eventually lead to bugs.
joegaudet 16y ago
I thought the issue was due to the binary representation of numbers like 0.1, 0.01, 0.001 being in fact non terminating fractions ala: 1/3 thus the longer the system ran the more small amounts of round off error it accumulated but adding two incomplete fractions. I seem to remember this being the case in my numeric methods course, but maybe that was a different systme.
jacquesm 16y ago
There's an in-joke amongst embedded systems programmers, which is that if you need floating point you don't fully grok the problem (yet). Floats are subtle, they can have exactly the kind of nasty little side effects that you overlook during testing and that bite you in a terrible way once you hit production. Fixed point is the way to go to implement stuff like this, floating point is asking for trouble. Of course floating point is more convenient, but most people that use it don't really understand what's going on under the hood, and most of the time they don't need to. But bank balances, clock values, GPS coordinates and other values of some importance are best represented in fixed point format. You'll have to do a bit more work when manipulating them but that pays off in reliability.
- jpr 16y ago
  Is there really any place where floating point is the right solution or default? I mean, all general purpose languages generally use floating point, but for general purposes, floating point isn't what you want. Or maybe it is, but it certainly isn't what I want.
pvg 16y ago
the Patriot missile kept track of its internal clock with floating point numbers It didn't, really, and the bug itself is more convoluted than the loss of precision you are describing. See the references: http://www.mc.edu/campus/users/travis/syllabi/381/patriot.htm http://www.mc.edu/campus/users/travis/syllabi/381/patriot.ht... and http://www.fas.org/spp/starwars/gao/im92026.htm http://www.fas.org/spp/starwars/gao/im92026.htm
slavak 16y ago
This baffles me. Did the software engineers creating this not take a course on numerical analysis in college? Or were those, as so often are, electrical engineers that had been hired to do software work? The amount of misunderstanding in the industry about what it takes to create mission-critical software is incredible.
- assemble 16y ago
  Trust me, most of us EEs know -plenty- about floating point problems. We also have to take entire classes about how our work could kill somebody. Bugs are bugs, errors and oversights happen. You have to deal with it, document what happened, and be vigilant to make sure it never happens again.

stretchwithme 16y ago

Interesting how complex it is to determine the accuracy of the missiles. Multiple Patriot missiles fired at each Scud, several possible outcomes, the Scud can break apart making multiple targets for the Patriots.

patio11 16y ago
I agree, though "We got the missile but missed the warhead. That has to count for something." strikes me as a little off. Pretend Saddam Hussein has ordered his team of crack experts to use crappy engineering as an active countermeasure. They just beat you. Do better.
- Anechoic 16y ago
  One of my college professors was an outspoken opponent of missile defense systems (and the Patriot system specifically) that worked during the missile's reentry/descent phase. His objection is that it's too easy for an opponent to defeat the system either by overwhelming it (MIRVs for instance) or by designing the reentry vehicle to make random movements which would make it really difficult for a intercepter to track. Even if the interceptor can hit it, it's more likely to knock the warhead off course instead of destroying it. If a nuclear missile is aimed at NY and an interceptor hits it so that it falls to Philly instead, that's still a net loss. Saddam inadvertently hit upon the both methods - his engineers tried to improve on the Soviet scud design to give them more range (which they were successful at) but their improvements made the missile more likely to break up on reentry (which presented more targets than the tracking radar anticipated) and the lack of aerodynamics of the resulting pieces (including the warhead) the missiles fall in unpredictable ways which caused tracking problems. An opponent that actually tried to game the system could make his missiles more difficult to hit. The professor is advocating for boost-phase missile defense since the missile movements are much more predicable.
  - jacquesm 16y ago
    But it makes for more defense spending. If you catch something on the launchpad that's a relatively low expense, to catch it i in flight you need to actively defend each and every possible target and a lot of sexy hardware to do so.

dotBen 16y ago

Imagine being the developer who wrote the line of code (who didn't understanding floating point variables). Or the QA tester who didn't spot it, or didn't decide it was worth reporting. Aside from being a pacifist, this is why a number of engineer friends have stepped out of building defense systems (including missile guidance systems) and into more civilian engineering because the stress and moral burden is just too great.

extension 16y ago
Better than being the executive who decided not to release the patch until 28 people were dead.
- viraptor 16y ago
  As long as the workaround was known, well... I don't know exactly what the military procedures are for situations like that, but updating an active rocket defence system in area where you don't necessarily have trained engineers -vs- rebooting it every day or so to make sure it works. It looks like a simple choice to me. Also looking at who actually makes the mistake - if someone gives you an update and the system fails, they're at fault. If you give clear instructions for operation and users don't follow it...
  - extension 16y ago
    According to Wikipedia, the workaround came from the Israeli army, who found the bug, not the manufacturer. The instructions for this workaround did not propogate clearly and thus weren't followed. Being defenseless for a few minutes every day during a reboot hardly seems like a reasonable fix anyway, especially if it becomes standard procedure that your enemy may learn about. The fact that the manufacturer did release a patch, rather than a workaround, the day after the accident suggests that this was indeed the safest course of action. It was just taken too late.

nitfol 16y ago

More information about the errors in the (fixed point) math on the patriot: http://www.ima.umn.edu/~arnold/disasters/patriot.html http://www.ima.umn.edu/~arnold/disasters/patriot.html

joshzayin 16y ago
That's interesting. Given that it was an issue with a non-terminating binary representation, what would be the way to handle this, without somehow resetting the clock (restart or otherwise)? Obviously, you could, in a modern system, have more memory and be able to store more bits of the number, but there would still be a limit that you would run into after some amount of time that would cause similar problems.
- tetha 16y ago
  I'm just thinking about this. I think I would try to split the clock into a precise part, which (for example) tracks how many milliseconds we are into an hour and a precise part which stores the hours, or the date up to the hours or whatever. Given this, I can reset the part with the degrading accuracy in a duration which maintains enough accuracy in order to maintain enough accuracy overall.

Natsu 16y ago

I find it interesting how "just reboot" has become something of a user expectation: often, users expect it to fix most anything. To be fair, it does seem to work fairly often. It's a strong enough expectation that when I had some industrial machines running DOS (albeit on more modern hardware), I added my update, backup & diagnostic scripts to autoexec.bat so that rebooting would fix most of their problems. It made my life a lot easier, though, because I could update the files and configurations via a master copy on the network, then tell them to reboot everything whenever it was convenient for them (usually between shifts) and the machines would all grab their updates and upload some log files for me to monitor.

viraptor 16y ago

I wonder how did they actually find out the reason for the failure? They had a system which worked perfectly (almost) and probably could be tested in every standard way without showing the problem. They must've had a seriously good logging system that showed something suspicious, or someone had a really interesting "a-ha" moment... I'd like to hear the story of debugging this one. Also how they managed to identify that this incident was caused by that specific bug.

dRother 16y ago

Sure, rebooting is often the most straightforward way to fix runtime issues because it resets everything. In this case, sounds like resetting the clock would have been just as effective. I'm sure these days, you'd have something like the equivalent of a ntpd update every hour to take care of that.

daemin 16y ago

I seem to recall reading somewhere that the system was originally designed to be a mobile platform against Soviet missiles in somewhere like west Berlin. Where they needed something that would be moved around every day or two so that the enemy would not know its location. That meant that the system would be reset whenever it was moved, and therefore using a floating point clock was a reasonable design trade off.

duncanj 16y ago

The really interesting lesson that engineers have learned from the Patriot is that "never reboot" might not be the best target for critical systems. Rather, controlled rebooting can help clean up problems before they affect the function of the system. http://portal.acm.org/citation.cfm?id=1251254.1251257 http://portal.acm.org/citation.cfm?id=1251254.1251257 http://www.computer.org/portal/web/csdl/doi/10.1109/HOTOS.2001.990072 http://www.computer.org/portal/web/csdl/doi/10.1109/HOTOS.20...