5 ms·

Wow, if you look at the PDF there were issues all over the place, not just in the binary representation. Patriot battery operators could have easily worked arou

Wow, if you look at the PDF there were issues all over the place, not just in the binary representation. Patriot battery operators could have easily worked around the computer math issues in particular, but various leadership-system-level mistakes were made, and then procedural details added up on top of that. Edit: To be clear, this was not just bad code, as that issue was already measured and known, but not communicated well, for one. It was military leadership systems-level issue in addition to a Raytheon/coder/etc. issue. Software was corrected on February 16. > 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. So Israel was running their units for 8h, but the US unit kept theirs running more than 10x longer with no idea what was appropriate. Phew. Then, on Scud-day, February 25, there were _six_ batteries operating around the vicinity, and it so happens that the 100h-uptime Patriot battery was tasked to this missile. (How many scuds flew that day? I'd like to know) And finally on February 26, the next day, "the modified software, which compensated for the inaccurate time calculation, arrived in Dhahran." Ouch. :-( The PDF report is a really nice effort. Things like the table on page 17/print page 15 made it easier to understand the range error situation compared to Patriot battery run time.

bostonsre 5y ago
Seems almost criminally negligent.
- 2OEH8eoCRo0 5y ago
  It's interesting that Raytheon's name is nowhere to be found on this. It sounds like Raytheon's bad code killed 28 US soldiers.
  - mlyle 5y ago
    The Iraqi SCUD killed 28 US soldiers. Raytheon failed to prevent it.
    - 2OEH8eoCRo0 5y ago
      Due to a code defect in their product*
      - kevin_thibedeau 5y ago
        That was being used outside of its original design specifications.
      - lumost 5y ago
        Missile interceptors are incredibly complicated. Even with perfect code there is a probability range for successful intercept. The probability was much lower in this case as the software had a defect, and the battery was online for 100h.
      - codechad 5y ago
    - bostonsre 5y ago
      Yes, the Iraqi scud was the primary factor, but it almost seems like if your seat belt snaps in a car accident with a drunk driver and you go through the windshield and die. The drunk driver is culpable but the car company doesn't get a free pass.
doodlebugging 5y ago
I once worked with a person who had an advanced degree in nuclear physics. They were sharp as a tack, a skilled programmer in multiple languages and on several platforms, and grossly over-qualified for the job they had taken but Congress had just killed their position with the SSC in Texas so they needed to switch gears for a while. Though they were super smart and a rapid typist they were also dyslexic. To make it worse, they would never take responsibility for any mistakes resulting from their failure to double-check the figures entered into the software they needed to run. As a result, we were constantly forced to rerun processes they had worked on because the person never reviewed the parameters they entered into the processing modules before running the jobs. Very simple mistakes like entering 1005 instead of 1500 would cost us a day or more rerunning jobs. It took me weeks to detect the pattern of failures and link them conclusively to this individual since other jobs by other people I supervised also failed but for different reasons. Once I saw the problem and could easily document the issue I took a few moments to sit with them privately to show what I had found and made the recommendation that they should double-check everything they typed before submitting the jobs so that we could eliminate that class of failures. This person was adamant that I had to be wrong and that they were a perfect typist and somehow someone else was responsible. Try as I might I could not get them to adopt a simple review-before-submit plan so, since they were a valuable team member who didn't need to lose their job during a period where good jobs were not easy to find, after consulting with my superiors it became my job to review everything they submitted, correct any input parameter fat-fingers or dyslexic inputs, and resubmit those jobs so that we could eliminate those failures. It was easy enough to do so we made it work and they were never informed I was bird-dogging their work so closely. They remained a valued member of the team until one day they put in their notice. They had been applying for any positions anywhere that would allow them to use their programming skills on problems that a physicist might find challenging. They had been offered and had accepted a position as a programmer with Raytheon working on missile guidance systems. After their exit, we joked that one day we would hear about a fat-finger mistake sending a missile to an unintended location. This person was not connected at all to this event since their work with Raytheon was several years after this event occurred (SSC shuttered in 1993). I have no idea what they worked on while there but I hope that someone noticed the issue and insured that two sets of eyes hit everything they typed. Those were the days.

bostonsre 5y ago

Seems almost criminally negligent.

2OEH8eoCRo0 5y ago
It's interesting that Raytheon's name is nowhere to be found on this. It sounds like Raytheon's bad code killed 28 US soldiers.
- mlyle 5y ago
  The Iraqi SCUD killed 28 US soldiers. Raytheon failed to prevent it.
  - 2OEH8eoCRo0 5y ago
    Due to a code defect in their product*
    - kevin_thibedeau 5y ago
      That was being used outside of its original design specifications.
    - lumost 5y ago
      Missile interceptors are incredibly complicated. Even with perfect code there is a probability range for successful intercept. The probability was much lower in this case as the software had a defect, and the battery was online for 100h.
    - codechad 5y ago
  - bostonsre 5y ago
    Yes, the Iraqi scud was the primary factor, but it almost seems like if your seat belt snaps in a car accident with a drunk driver and you go through the windshield and die. The drunk driver is culpable but the car company doesn't get a free pass.

doodlebugging 5y ago

I once worked with a person who had an advanced degree in nuclear physics. They were sharp as a tack, a skilled programmer in multiple languages and on several platforms, and grossly over-qualified for the job they had taken but Congress had just killed their position with the SSC in Texas so they needed to switch gears for a while. Though they were super smart and a rapid typist they were also dyslexic. To make it worse, they would never take responsibility for any mistakes resulting from their failure to double-check the figures entered into the software they needed to run. As a result, we were constantly forced to rerun processes they had worked on because the person never reviewed the parameters they entered into the processing modules before running the jobs. Very simple mistakes like entering 1005 instead of 1500 would cost us a day or more rerunning jobs. It took me weeks to detect the pattern of failures and link them conclusively to this individual since other jobs by other people I supervised also failed but for different reasons. Once I saw the problem and could easily document the issue I took a few moments to sit with them privately to show what I had found and made the recommendation that they should double-check everything they typed before submitting the jobs so that we could eliminate that class of failures. This person was adamant that I had to be wrong and that they were a perfect typist and somehow someone else was responsible. Try as I might I could not get them to adopt a simple review-before-submit plan so, since they were a valuable team member who didn't need to lose their job during a period where good jobs were not easy to find, after consulting with my superiors it became my job to review everything they submitted, correct any input parameter fat-fingers or dyslexic inputs, and resubmit those jobs so that we could eliminate those failures. It was easy enough to do so we made it work and they were never informed I was bird-dogging their work so closely. They remained a valued member of the team until one day they put in their notice. They had been applying for any positions anywhere that would allow them to use their programming skills on problems that a physicist might find challenging. They had been offered and had accepted a position as a programmer with Raytheon working on missile guidance systems. After their exit, we joked that one day we would hear about a fat-finger mistake sending a missile to an unintended location. This person was not connected at all to this event since their work with Raytheon was several years after this event occurred (SSC shuttered in 1993). I have no idea what they worked on while there but I hope that someone noticed the issue and insured that two sets of eyes hit everything they typed. Those were the days.