Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!cbnews!cbnews!military
From: warack@dip.eecs.umich.edu (Christopher Warack)
Newsgroups: sci.military
Subject: Re: patriot missile failure
Message-ID: <1991Jun19.010743.11663@cbnews.cb.att.com>
Date: 19 Jun 91 01:07:43 GMT
References: <1991Jun18.051603.8376@amd.com>
Sender: military@cbnews.cb.att.com (william.a.thacker)
Organization: University of Michigan EECS Dept.
Lines: 23
Approved: military@att.att.com



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.