From: jake@bony1.bony.com (Jake Livni)
Newsgroups: talk.politics.mideast
Subject: Israelis debug Patriot Software (was: Re: Well, it isn't quite over yet)
Summary: Patriot software problems found by Israelis
Date: 8 Apr 92 22:08:09 GMT
Organization: The Department of Redundancy Department

In article <1992Apr03.150041.163792@cs.cmu.edu> anwar+@cs.cmu.edu (Anwar Mohammed) writes:

>It seems that this is the type of behavior on Israel's part that makes it a
>prime target for the Patriot story.  Reports like this were pretty much
>squashed in the past, in the interest of the American/Israeli relationship.
[...]
>It isn't wise to play hardball with the folks who exert considerable control
>over not only the purse strings, but a good portion of your security apparatus
>(namely, the American military technology that forms the core of Israel's
>defenses).

Actually, the U.S and Israel have a long-standing and mutually beneficial 
relationship of developing and testing weapons systems together.  The 
recent allegations against Israel have certainly caused the Israeli voters
to become suspicious of the Bush Administration and could possibly also
hurt future military co-operation between the two countries.

The following article in a recent comp.risks posting demonstrates the
American and Israeli co-operation in field testing weapons systems.


>RISKS-LIST: RISKS-FORUM Digest  Saturday 4 April 1992  Volume 13 : Issue 35
>----------------------------------------------------------------------
>
>Date:        3 Apr 92 17:58:00 EST
>From: Stanley (S.T.H.) Chow <SCHOW@BNR.CA>
>Subject:    Some details on patriot problem (from comp.realtime)
>
>This is the first time I have seen a detailed description of the
>round-off/accumulation problem.     Stanley Chow        (613) 763-2831
>
>In article <1992Apr3.062551.7306@sequent.com>, jjb@sequent.com (Jeff Berkowitz)
>> [...]
>> The article states "...this particular Patriot battery had been
>> running continuously for about 100 hours...[and]...had built up
>> a timing lag of 0.3433 second."  This timing error was sufficient
>> to shift the "range gate" enough to cause the system to disregard
>> the Scud.
>>
>> My "comp.realtime" question: what algorithm in the Patriot system
>> would cause an ABSOLUTE time variation like this to change a
>> relative computation, like the predicted course of the incoming
>> missile?
>
>I just received my copy of the US General Accounting Office's "Report to the
>Chairman, Subcommittee on Investigations and Oversight, Committee on Science,
>Space, and Technology, House of Representatives: Patriot Missile Defense -
>Software Problem Led to System Failure at Dhahran, Saudi Arabia" (phew!)
>
>Since I can't find a copyright notice on it anywhere, I'll quote the
>appropriate paragraph:
>
>"The range gate's prediction of where the Scud will next appear is a function
>of the Scud's known velocity and the time of the last radar detection.
>Velocity is a real number that can be expressed as a whole number and a decimal
>(e.g., 3750.2563...miles per hour).  Time is kept continuously by the system's
>internal clock in tenths of seconds but is expressed as an integer or whole
>number (e.g., 32, 33, 34...).  The longer the system has been running, the
>larger the number representing time.  To predict where the Scud will next
>appear, both time and velocity must be expressed as real numbers.  Because of
>the way the Patriot computer performs its calculations and the fact that its
>registers are only 24 bits long, the conversion of time from an integer to a
>real number cannot be any more precise than 24 bits.  This conversion results
>in a loss of precision causing a less accurate time calculation.  The effect of
>this inaccuracy on the range gate's calculation is directly proportional to the
>target's velocity and the length of the the system has been running.
>Consequently, performing the conversion after the Patriot has been running
>continuously for extended periods causes the range gate to shift away from the
>center of the target, making it less likely that the target, in this case a
>Scud, will be successfully intercepted."
>
>Interestingly, when the Israelies were running their Patriot systems, they
>studied the heck out of them, and noticed this problem after merely 8 hours of
>operation.  (8 hours corresponds to a range-gate shift of 55 meters; 100 hours
>corresponds to 678 meters.)  They sent this data back, and the Americans
>responded with something like, "This was designed for the European theater,
>where it would be run for a few hours before being moved.  Who in his right
>mind would run a system continuously for eight hours?  Or more?"  They did
>write a software patch to fix the problem, but it took two weeks to arrive in
>Saudi, because of transport difficulties.  It arrived the day after the
>failure.
>
>Frederick G. M. Roeber | CERN -- European Center for Nuclear Research
>e-mail: roeber@cern.ch or roeber@caltech.edu | work: +41 22 767 31 80
>r-mail: CERN/PPE, 1211 Geneva 23, Switzerland | home: +33 50 42 19 44
>
>------------------------------


Isn't that something?!  Israeli software engineers fixing problems to 
safeguard Saudi military targets!


-- 
Jake Livni
jake@bony1.bony.com
My opinions only - employer has no opinions.
Newsgroups: talk.politics.mideast