The Patriot Missile Failure (2000)
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.<p>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&#x2F;coder&#x2F;etc. issue.<p>Software was corrected on February 16.<p>&gt; 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.<p>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.<p>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&#x27;d like to know)<p>And finally on February 26, the next day, &quot;the modified software, which compensated for the inaccurate time calculation, arrived in Dhahran.&quot;<p>Ouch. :-(<p>The PDF report is a really nice effort. Things like the table on page 17&#x2F;print page 15 made it easier to understand the range error situation compared to Patriot battery run time.