ARMS-D-Request@MIT-MC.ARPA (Moderator) (10/31/85)
Arms-Discussion Digest Thursday, October 31, 1985 11:28AM
Volume 5, Issue 9
Today's Topics:
Bulls**t and bees**t in Scientific American
SDI, Safeguard, and software complexity
----------------------------------------------------------------------
Date: Tue, 29 Oct 85 12:02:07 est
From: David Rogers <drogers%farg.umich.csnet@CSNET-RELAY.ARPA>
Subject: Bulls**t and bees**t in Scientific American
Certainly, claiming that a journal misrepresented an authors work
through biased editing is a serious charge; the final judgement
would be the opinion of the author, unless he was "in cahoots" with the
magazine in the purported scam. The key would seem to be a confirmation
of the claim in WSJ that "Mr. Meselson said that he generally accepts
... that trichothecene mycotoxins don't occur naturally in Southeast
Asia"; anyone care to write this fellow for his comment?
The statement "I don't want to see SA quoted in a arms control
context" is unjustifiable (and intellectually unprofessional) in any
case. In fairness to the authors of independently generated articles,
you should judge each article on its own merit (unless you really feel
that the entire journal is biased, not just in the selection of topics,
but in editing out results that don't conform to its own beliefs).
I a face-off, I trust WSJ no more than SA, and without more information,
giving either the benefit of the doubt is just picking sides. This is
too important an issue to judge simply on whether I like SA or WSJ
better.
Regards,
David Rogers
drogers@mit-oz.ARPA
------------------------------
Date: Tue, 22 Oct 1985 14:50:35 EDT
From: Michael Caplinger <mike%bambi@mouton.ARPA>
Subject: SDI, Safeguard, and software complexity
One possible way to get a handle on the size of the software needed to
manage an SDI ABM system is to examine the size of the Safeguard ABM
system as of the mid 70s. A reference is the Bell System Tech Journal
Special Supplement on the Safeguard Data Processing System, dated 1975.
We find the following numbers there:
Real time code (in thousands of instructions)
operating system 100
Missile Direction System (MDS)
applications 300
exercisers 50
Perimeter Acquisition Radar (PAR)
applications 200
exercisers 25
Ballistic Missile Defense Center
applications 60
Non real time:
Installation and maintenance software: 830K statements
Software development environment: 580K instructions
Most of the code was written in "Centran", a middle level language
vaguely like PL/I. A cross compiler running on IBM 360s was used for
program development (all batch, I believe).
As I understand it, the processors themselves were located at the MDS
sites, along with multi-face phased array radars for most interception
tracking. The PAR sites had single-face radars and were used for long
range tracking and Spartan interception guidance. The BMDC was a
central monitoring point.
The processors themselves were multiprocessors (up to 10 elements) with
shared memory. Multiprocessing was used for both speed and
fault-tolerance through hardware redundancy.
I find the instruction counts above surprisingly low. Of course,
there's no evidence that Safeguard would have worked, though there was
a major effort made to validate the software through both non-RT and RT
testing (mostly with simulated radar inputs).
It's also obvious that SDI is a rather more demanding problem in many
respects. I'd be interested in the comments of anyone who actually
worked on Safeguard or knows more about it as to how real the final
system was, and what performance expectations were like.
Michael Caplinger
mike@bellcore.arpa
ihnp4!bambi!mike
------------------------------
End of Arms-Discussion Digest
*****************************