warack@dip.eecs.umich.edu (Christopher Warack) (06/19/91)
From: warack@dip.eecs.umich.edu (Christopher Warack) >The reference to "tired" software was discussed in the Risks digests >recently. It seems that there are allegations that software for the >particular Patriot battery which was defending the area of the barracks >had been running continuously for 4 days. (It was suggested that >this could have contributed to an "unstable" system.) Other information Last weeks AW&ST (10 Jun) provided more info on this. The problem lay in a clock drift that accumulated over the 4 days of continous operation. The clock drift wasn't anticipated to be a problem because the Patriot was meant to operate for less than a day before moving or undergoing maintenance. The problem surfaced because the Patriot was being used in a way which it was not intended. It's curious to note how quickly responses have come (re: Risks articles) blaming the defense industry for buggy software. In reality, the situation was quickly identified, diagnosed, and fixed. The true sadness in this situation was that the fixed release was in Saudi Arabia en route to the battery in Riyadh when the attack occured. In another day or two, the new version would have been loaded and the missile tracked properly and, in all likelihood, engaged.
002@pnet16.cts.com (J.W.Cupp Lcdr/Usn) (06/21/91)
From: 002@pnet16.cts.com (J.W.Cupp Lcdr/Usn)
This long post quoted several news articles, which made mention of a possible
computer glitch in the Patriot computer. The glitch was attibuted to having
operated four days continuously without a reboot.
When I was on a ship with a Navy Tactical Data System (NTDS) we made it a
habit to reboot the system once a day. Typically, this would occur during the
night watches when things were slowest. Usually nothing untoward would happen
if we missed a day, but if the NTDS went several days without a reboot, there
was a chance some funny things might begin to happen. Of course, it could be
counted upon to happen at the worst possible moment. So, we generally did
that once-a-day reboot, if at all possible.
J. W. Cupp
UUCP: humu!nctams1!pnet16!002 Naval Telecommunications Center
ARPA: humu!nctams!pnet16!002@nosc.mil P.O. Box 55
INET: 002@pnet16.cts.com Pearl Harbor, Hawaii 96860
The above is merely my opinion, and not to be construed as anything else.boone@IDA.ORG (John Boone) (06/22/91)
From: boone@IDA.ORG (John Boone) The following is the latest posting to the Risks Digest on the Patriot missile failure. (Some information not pertaining to the actual failure has been deleted.) The posting talks about a 0.36 second error - this error is in reference to the clock-drift which occurred due to extended operation of the system; i.e., the clock was not reset by re-initializing the system, and incremental errors built up over time to cause a significant discrepency. I think claims that the Patriot software was "buggy" are somewhat of a knee-jerk reaction, given the overall performance of the system. The fact is, any significantly complex system has some bugs. With our present state of technology, it's just a question of how often (and under what conditions) the bugs manifest themselves. I would not call a system with a +95% performance rate (in shooting down extra-supersonic missiles) - a buggy system. --------------------------------------- Article 494 in comp.risks (moderated): Date: 19 Jun 91 00:06:15 GMT RISKS-LIST: RISKS-FORUM Digest Tuesday 18 June 1991 Volume 11 : Issue 94 Date: Tue, 18 Jun 91 13:48 EST From: HORN%HYDRA@sdi.polaroid.com Subject: Re: The Patriot system and the Dharan Scud: Time Warp (RISKS-11.92) A slight correction, the specification for Patriot was 14 hours of operation. The 22 hour figure was the actual operational time for systems that did detect the Scud but were out of range. The origin of the 14 hour spec was the original intended use of Patriot in defense of mobile forces where it was expected that the systems would relocate several times per day, so the assumption was not tacit. It was a deliberate considered decision, balancing procurement and operational costs against the operational needs. For those who don't understand how a 0.36 second (or 1 ppm) error can cause this problem, you have to examine how a machine tracks a target. At initial acquisition time you have a single location, but no speed or direction. So you put a ``box'' around the location and look again a very short time later. Based upon the article, the timing error resulted in a mislocated box. A slower target (like an airplane) would still have been within the box. A Mach 6 missile was outside the box. So the computer did not associate the second echo with the first echo. (information about formal proofs for software deleted) --------------------------------------- -- ........................................................................... : : : : J.M.Boone : Tenacity of purpose for a rightful cause : : : is not shaken by a frenzy of opposition. : : boone @ ida.org : : : : - A. Lincoln : ...........................................................................
tewok@TIS.COM (Wayne G. Morrison) (06/28/91)
From: Wayne G. Morrison <tewok@TIS.COM> In a recent article, John Boone (boone@ida.org) said the following: > I think claims that the Patriot software was "buggy" are somewhat of a > knee-jerk reaction, given the overall performance of the system. The fact is, > any significantly complex system has some bugs. With our present state of > technology, it's just a question of how often (and under what conditions) the > bugs manifest themselves. I would not call a system with a +95% performance > rate (in shooting down extra-supersonic missiles) - a buggy system. For unspecified reasons, I have not gotten a daily paper for a few months and so I don't know what sort of numbers the DoD has released about the usage of the Patriot system during the Gulf War. However, I have heard from a reliable source that the Patriot system did far worse than the above mentioned +95% performance rate. Depending on which number is accurate, the Patriot's performance rate was 15% - 18%. (The "depending on which number is accurate" comment is a reflection of my memory -- I don't remember which of two numbers was actually given to me.) The performance rate function I was given was: performance rate = (# of SCUDs within Patriot's coverage envelope) / (# of Patriot missiles fired) Filling in the numbers gets either: 15% rate = 27 SCUDs / 180 Patriots or 18% rate = 27 SCUDs / 150 Patriots The 27 SCUDs may be off by a bit, but I think that's a pretty close number. One of the first things my college statistics professor taught me is that statistics can be used to say anything you want them to say and are, therefore, useless. I suppose the Mr. Boone's +95% performance rate can be derived from something like the percentage of SCUDs that the Patriots intercepted. I'd like to know how that number was generated and I'd also like to know if that's what the DoD has been saying. I guess the performance of the Patriots all comes down to what you're trying to show. +95% SCUD-killing rate or the effectiveness-rate (for lack of a better term) of the Patriots. If you had the system cost, you could even give it in terms of which system was more cost-effective. Wayne Morrison PS. I realize that my information is not likely to be seen as particulary trustworthy since I can't give precise numbers.