To get a trial key
fill out the form below
Team License (a basic version)
Enterprise License (extended version)
* By clicking this button you agree to our Privacy Policy statement

Request our prices
New License
License Renewal
--Select currency--
* By clicking this button you agree to our Privacy Policy statement

Free PVS-Studio license for Microsoft MVP specialists
* By clicking this button you agree to our Privacy Policy statement

To get the licence for your open-source project, please fill out this form
* By clicking this button you agree to our Privacy Policy statement

I am interested to try it on the platforms:
* By clicking this button you agree to our Privacy Policy statement

Message submitted.

Your message has been sent. We will email you at

If you haven't received our response, please do the following:
check your Spam/Junk folder and click the "Not Spam" button for our message.
This way, you won't miss messages from our team in the future.

R-17 VS Patriot: a Rounding Issue

R-17 VS Patriot: a Rounding Issue

Oct 31 2016

This is another piece in our series of articles where we talk about the importance of high-quality code in computer systems whose failure can cause huge expenses or casualties. This time we will talk about reliability of embedded software in military equipment.


February 11, 1991, the Israeli forces inform the Patriot Project Office about a defect found in the Patriot surface-to-air missile defense system. They discovered that running the system for consecutive 8 hours resulted in a 20% targeting precision loss, and estimated that after continuous operation for 20 hours the inaccuracy would grow so big that the Patriot would no longer be able to lock on, track, and intercept ballistic missiles. The U.S. commanders underrated the importance of the discovery, presuming that the system would never be used for over 8 hours as it had been designed as a mobile system to be used for short-time defense operations.

February 16, a bug fix is issued, but applying it to every unit requires some time due to the ongoing war.

February 21, the commanders issue a directive that the system should not run "for a very long time". It is not specified how much exactly "a very long time" is.

February 25, a ballistic missile R-17 (also known as Scud) strikes a U.S. Army barracks in Dhahran, Saudi Arabia, killing 28 and injuring 96 soldiers. The Patriot battery failed to intercept the missile due to a software error.

February 26, the bug fix is delivered to Dhahran.



R-17 (NATO reporting name SS-1C Scud-B; exported under the name R-300) is a Soviet single-stage ballistic missile propelled by storable liquid fuel.



Officers examining an R-17 missile shot down by a Patriot MIM-104 SAM system in the desert during Operation Desert Storm

The MIM-104 Patriot is a U.S. surface-to-air missile (SAM) defense system used by the USA and several allied nations.




A detailed view of an AN/MPQ-53 radar set. The circular pattern on the front of the vertical component is the system's main phased array, consisting of over 5,000 individual elements, each about 39 millimeters (1.535 in) diameter.


PAC-3 missile launcher, note four missiles in each canister

An investigation discovered a bug in the Patriot's tracking software that caused the system's internal clock to drift gradually from the real time.

The time was stored as an integer number in a 24-bit register with an accuracy of 1/10 of a second. This resulted in some portion of the time value being lost as it incremented each 0.1 seconds. To calculate a target's location, the data had to be cast to real numbers.

1/10 is 1/24+1/25+1/28+1/29+1/212+1/213+... In other words, binary expansion of the value 1/10 is 0.0001100110011001100110011001100.... That's why this value, stored in a 24-bit register, was rounded to 0.00011001100110011001100, resulting in a precision error of 0.0000000000000000000000011001100... in binary format, or about 0.000000095 in decimal format. During 100 hours of continuous operation, this error would build up to 0.000000095×100×60×60×10=0.34 seconds.

An R-17's velocity is 1676 m/s, so it covers over half a kilometer in 0.34 seconds, which is more than enough for the missile to slip past the Patriot's intercept range. The funny thing is that this time-calculation bug was fixed only in some parts of the software, but not in all of it.

The software had been written in an assembler language 15-20 years earlier and was modified a number of times by different programmer teams during the subsequent years.

The slides shown below are taken from the report on the Patriot system's failure:



Golden rules for programmers:

  • Choose adequate sizes for your variables. Always check twice how many bits each of them requires for storing values (long, int, double, float, etc.) in a given language and a given operating system.
  • Use integer numbers instead of floating-point ones wherever possible. Measure money in cents, not in dollars. If you can't do without float, use double-precision format.
  • Never use floating-point numbers as loop counters.
  • Avoid mixing types (signed -- unsigned; integer -- floating-point; single precision -- double precision). Be careful with type casts.
  • Check for possible overflows and division-by-zero operations.

More on Patriot


Our goal is to attract the community's attention to the issues of software reliability. The times when computer programs were all about some strange, obscure scientific calculations in Fortran or video games are long over. Now they surround us and permeate every area of our activity.

In earlier times, critical software bugs affected narrow, specific areas, for example civil (Ariane 5) and military rocket industry. Nowadays, you may encounter them not only when working on your computer, but also when driving a car (Toyota) or undergoing medical treatment (Therac-25). We are among those who support programmers in their fight against bugs. Static code analyzer PVS-Studio developed by our team helps detect many of the errors in C, C++, and C# programs as early as at the coding stage. Taking this opportunity, I'd also like to remind you that starting with October 25, 2016, there is a Linux version of PVS-Studio available in addition to the existing Windows version.

This article was originally published (in Russian) on The original and translated versions were posted on our blog with the permission of the author.

Popular related articles
The Ultimate Question of Programming, Refactoring, and Everything

Date: Apr 14 2016

Author: Andrey Karpov

Yes, you've guessed correctly - the answer is "42". In this article you will find 42 recommendations about coding in C++ that can help a programmer avoid a lot of errors, save time and effort. The au…
The way static analyzers fight against false positives, and why they do it

Date: Mar 20 2017

Author: Andrey Karpov

In my previous article I wrote that I don't like the approach of evaluating the efficiency of static analyzers with the help of synthetic tests. In that article, I give the example of a code fragment…
Characteristics of PVS-Studio Analyzer by the Example of EFL Core Libraries, 10-15% of False Positives

Date: Jul 31 2017

Author: Andrey Karpov

After I wrote quite a big article about the analysis of the Tizen OS code, I received a large number of questions concerning the percentage of false positives and the density of errors (how many erro…
PVS-Studio ROI

Date: Jan 30 2019

Author: Andrey Karpov

Occasionally, we're asked a question, what monetary value the company will receive from using PVS-Studio. We decided to draw up a response in the form of an article and provide tables, which will sho…
Appreciate Static Code Analysis!

Date: Oct 16 2017

Author: Andrey Karpov

I am really astonished by the capabilities of static code analysis even though I am one of the developers of PVS-Studio analyzer myself. The tool surprised me the other day as it turned out to be sma…
The Last Line Effect

Date: May 31 2014

Author: Andrey Karpov

I have studied many errors caused by the use of the Copy-Paste method, and can assure you that programmers most often tend to make mistakes in the last fragment of a homogeneous code block. I have ne…
The Evil within the Comparison Functions

Date: May 19 2017

Author: Andrey Karpov

Perhaps, readers remember my article titled "Last line effect". It describes a pattern I've once noticed: in most cases programmers make an error in the last line of similar text blocks. Now I want t…
PVS-Studio for Java

Date: Jan 17 2019

Author: Andrey Karpov

In the seventh version of the PVS-Studio static analyzer, we added support of the Java language. It's time for a brief story of how we've started making support of the Java language, how far we've co…
Technologies used in the PVS-Studio code analyzer for finding bugs and potential vulnerabilities

Date: Nov 21 2018

Author: Andrey Karpov

A brief description of technologies used in the PVS-Studio tool, which let us effectively detect a large number of error patterns and potential vulnerabilities. The article describes the implementati…
How PVS-Studio Proved to Be More Attentive Than Three and a Half Programmers

Date: Oct 22 2018

Author: Andrey Karpov

Just like other static analyzers, PVS-Studio often produces false positives. What you are about to read is a short story where I'll tell you how PVS-Studio proved, just one more time, to be more atte…

Comments (0)

Next comments
This website uses cookies and other technology to provide you a more personalized experience. By continuing the view of our web-pages you accept the terms of using these files. If you don't want your personal data to be processed, please, leave this site.
Learn More →