home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / fj / question / misc / 1445 < prev    next >
Encoding:
Internet Message Format  |  1992-11-11  |  4.6 KB

  1. Path: sparky!uunet!ccut!wnoc-tyo-news!etl.go.jp!ume!gama!lab!wasisaka
  2. From: wasisaka@wink.ntt.jp (WASHISAKA Mitsukazu)
  3. Newsgroups: fj.questions.misc
  4. Subject: Patriot
  5. Message-ID: <b5d.khdpk@lab.ntt.jp>
  6. Date: 12 Nov 92 04:30:36 GMT
  7. Sender: news@lab.ntt.jp
  8. Distribution: fj
  9. Organization: NTT Basic Research Labs., Tokyo, Japan.
  10. Lines: 83
  11.  
  12. $@OI:d(J@NTT $@$G$9!%(J
  13.  
  14. bit $@$N(J 12 $@7n9f$N(J 64 $@%Z!<%8$N:82<$N5-;v$rFI$s$G$$$F:FEY5$$K$J$C$?$N$G$9$,!$(J
  15. $@!V2$(J$@=#$N@o>l$G$O%Q%H%j%*%C%H$O@d$($:0\F0$7$F;HMQ$9$k!%!W$H$$$&$N$O$J$<(J
  16. $@$J$N$G$7$g$&!)(J
  17.  
  18. $@$3$l$N$b$H5-;v$rFI(J$@$s$@;~$b7^7b%_%5%$%k$r?t;~4V$*$-$K0\F0$5$;$F;HMQ$9$k(J
  19. $@$H$$$&>u67$,NI$/$o$+$i$J$/$F!$@_CV8e(J($@%7%9%F%`;OF0(J$@8e(J)$@?t;~4V$GH/<M$9$k$H$$$&(J
  20. $@0UL#$+$H;W$C$?$N$G$9$,!$?t;~4V$G0\F0$5$;$F;HMQ$9$k$N$J$i$=$NM}M3$O$J$<$J$N(J
  21. $@$G$7$g$&!%(J
  22.  
  23. > From: roeber@vxcrna.cern.ch
  24. > Date: 3 Apr 92 09:47:14 GMT
  25. > Message-ID: <1992Apr3.104714.1@vxcrna.cern.ch>
  26. > Subject: Re: Design question about Patriot
  27. >
  28. > In article <1992Apr3.062551.7306@sequent.com>, jjb@sequent.com (Jeff Berkowitz) writes:
  29. > > [...]
  30. > > The article states "...this particular Patriot battery had been
  31. > > running continuously for about 100 hours...[and]...had built up
  32. > > a timing lag of 0.3433 second."  This timing error was sufficient
  33. > > to shift the "range gate" enough to cause the system to disregard
  34. > > the Scud.
  35. > > 
  36. > > My "comp.realtime" question: what algorithm in the Patriot system
  37. > > would cause an ABSOLUTE time variation like this to change a
  38. > > relative computation, like the predicted course of the incoming
  39. > > missile?
  40. >
  41. > I just received my copy of the US General Accounting Office's "Report
  42. > to the Chairman, Subcommittee on Investigations and Oversight, 
  43. > Committee on Science, Space, and Technology, House of Representatives:
  44. > Patriot Missile Defense - Software Problem Led to System Failure at
  45. > Dhahran, Saudi Arabia" (phew!)
  46. >
  47. > Since I can't find a copyright notice on it anywhere, I'll quote the
  48. > appropriate paragraph:
  49. >
  50. > "The range gate's prediction of where the Scud will next appear is a
  51. > function of the Scud's known velocity and the time of the last radar
  52. > detection.  Velocity is a real number that can be expressed as a
  53. > whole number and a decimal (e.g., 3750.2563...miles per hour).  Time
  54. > is kept continuously by the system's internal clock in tenths of
  55. > seconds but is expressed as an integer or whole number (e.g., 32, 33,
  56. > 34...).  The longer the system has been running, the larger the number
  57. > representing time.  To predict where the Scud will next appear, both
  58. > time and velocity must be expressed as real numbers.  Because of the
  59. > way the Patriot computer performs its calculations and the fact that
  60. > its registers are only 24 bits long, the conversion of time from an
  61. > integer to a real number cannot be any more precise than 24 bits.
  62. > This conversion results in a loss of precision causing a less accurate
  63. > time calculation.  The effect of this inaccuracy on the range gate's
  64. > calculation is directly proportional to the target's velocity and the
  65. > length of the the system has been running.  Consequently, performing
  66. > the conversion after the Patriot has been running continuously for 
  67. > extended periods causes the range gate to shift away from the center
  68. > of the target, making it less likely that the target, in this case a
  69. > Scud, will be successfully intercepted."
  70. >
  71. > Interestingly, when the Israelies were running their Patriot systems,
  72. > they studied the heck out of them, and noticed this problem after
  73. > merely 8 hours of operation.  (8 hours corresponds to a range-gate
  74. > shift of 55 meters; 100 hours corresponds to 678 meters.)  They
  75. > sent this data back, and the Americans responded with something like,
  76. > "This was designed for the European theater, where it would be run
  77.    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  78. > for a few hours before being moved.  Who in his right mind would
  79.   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  80. > run a system continuously for eight hours?  Or more?"  They did 
  81. > write a software patch to fix the problem, but it took two weeks to
  82. > arrive in Saudi, because of transport difficulties.  It arrived the
  83. > day after the failure.
  84. >
  85. > -- 
  86. > Frederick G. M. Roeber | CERN -- European Center for Nuclear Research
  87. > e-mail: roeber@cern.ch or roeber@caltech.edu | work: +41 22 767 31 80
  88. > r-mail: CERN/PPE, 1211 Geneva 23, Switzerland | home: +33 50 42 19 44
  89. > --  
  90. > "Sorry, baby, I can't take you to the pizza joint tonight, I've got to go
  91. > back to the lab and split the atom." -- Ayn Rand, "What is Romanticism?"
  92.  
  93. -----
  94. WASHISAKA Mitsukazu  (wasisaka@wink.ntt.jp)
  95.