Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…
The General Accounting Office (GAO) has issued a report, 20 Apr 89, entitled
"Management and Technical Problems Delay Operation Center Acquisition"
(GAO/IMTEC-89-18). The 50+page report discusses the Air Force Space Defense
Operations Center modernization effort at Cheyenne Mountain.
The following is from the Executive Summary:
"The SPADOC program has been marked by management problems, unrealized
expectations, and program delays. The Air Force has invested over $235 million
in a system that is now more than 4 years behind schedule and far from meeting
its required operational capability.
. . .
At the root of SPADOC's technical problems is the Air Force's attempt
to achieve controlled mode security. Software development tasks designed to
achieve this form of multilevel security are time-consuming, technically
demanding, and still undergoing much research and development. In SPADOC's
case, functions such as notifying national decision makers that a satellite is
under attack take as much as four times longer to complete than required."
Interested parties can call 202-275-6241 to obtain a free copy. In the
interest of fairness the DoD/Air Force response is included within the report.
My uncle is a conspiracy and doomsday person and several friends have worked in
the "business". They have given me an education. My own experiences in a
military organization have confirmed their observations:
The major problem is that only a couple of times has our nuclear arsenal been
tested under field conditions (to the public's knowledege). Even then it has
not really been under battle conditions.
The major problem is that today's military rarely have surprise tests.
Operational Readiness Tests(ORT) would have to simulate a true war. This would
include a lot of collateral information and details, lack of warning, and other
items. Anything less than firing random rockets would not be a real test.
Also there are cross checks to make sure other missiles are being fired.
The current worry is that 1). The missile crews might freeze or panic. 2).
The missile would explode on the pad or fail to fire. 3). It wouldn't get
airborne - blast through the silo lid. 4). It would cartwheel in the air or
explode (as one recent test did). 5). It wouldn't hit the target.
The problem is testing this because any commander who has word of an inspection
or a ORT will prep his equipment and men. The phemonena of the perfect troop
of military is well known to inspecting generals and chiefs of state as well as
the GIs who are told to prepare for a "surprise inspection".
The risk? How do you test a doomsday machine. Can any system be tested for
"ultimate load" or "emergency conditions".
=Dennis L. Mumaugh
Lisle, IL ...!{att,lll-crg,attunix}!cuuxb!dlm OR dlm@cuuxb.att.com
NASA and McDonnel Douglas are testing a helmet-mounted, visual approach and landing system that could have applications for future aircraft without cockpit windows, according to the June 19, 1989 issue of Aviation Week and Space Technology (pages 126 and 127). The system uses two fixed-position monochrome video cameras mounted in the aircraft's nose. Video and graphics processing is performed, and digitized pictures are relayed to the helmet display. According to Mark S. Rolwes, principal investigator for McDonnell Douglas, the use of a fixed sensor suite offers advantages such as high reliability (because there are no moving parts) and redundancy. A magnetic tracking device is used to measure the pilot's head movements. Based on where the pilot is "looking", a 30 by 40 degree field of view is selected, processed and displayed on the helmet's eyepieces. There is a 17-millisecond delay in getting an image from the cameras to the eyepieces. Rolwes said the delay is imperceptible and that it doesn't affect pilot performance. All four pilots in the tests were able to successfully land NASA's Boeing 737 Transport Systems Research Vehicle aircraft using the landing system, coming within 500 feet of a specified target after making several practice approaches. A second pilot was present to set up the approach and be ready to take over and fly the aircraft visually if there was a problem with the landing system. I won't belabor RISKS readers by enumerating a bunch of the obvious potential problems with such a system. Suffice to say that the possibility of crashing an airplane because of a failure in the video system, coupled with the inability to look out the window (because the plane doesn't have one) is terrifying. The article specifically mentions future hypersonic flight vehicles as aircraft that may not have, or be able to have, conventional cockpit windows. Also, it says that the system could have applications in current military aircraft in which crew eye protection during combat is important. For commercial aircraft, the system would supposedly be useful for obviating window area restrictions and for providing night vision capabilities. Although this touches on a whole kettle of risks that have been undergoing periodic discussion in this forum (risks from too much going on in the cockpit, etc), I think that such a system, if well-designed, could help to reduce the possibility of an accident, as long as a manual backup system (a window) was retained.
Here are excerpts from FEDERAL COMPUTER WEEK, May 8 1989, p. 10: ``Air Force to Upgrade Missile Control Systems'' by Bob Brewin The Air Force plans to upgrade the computer and communications systems that run the launch control centers of the US long-range missile arsenal. The $507 million project will streamline the authentication of war order messages as well as missile retargeting and launch authorization, according to the Air Force. Under the Rapid Execution and Combat Targeting (REACT) contract, the Air Force plans to automate for the first time the processing of emergency war order messages by the two-man intercontinental ballistic-missile launch control center crews. Part of the job includes improvements in the 1960s-vintage weapons system control computers that manage the launch and retargeting of all missiles in a wing. Although the REACT system features an electronic interface between the war order message processing function and weapon control systems, an Air Force official said, ``The nuclear assuredness aspects of the system will remain the same. Man will remain in the loop.'' ... Bruce Blair, a former launch control center (LCC) officer who studies nuclear command and control systems for the Brookings Institution, said that while the REACT program ``will reduce human judgment at [the LCC level] by some factor,'' its impact will be minimal ``because most of the human judgments are made at the NORAD or National Command Authority level.'' ... LCC crews receive war order messages through three digital communications channels: very low frequency radio, the Air Force Satellite Communications System and the SAC digital information network. According to Brooking's Blair, the crews must then take these messages and manually authenticate them with secured code books. The computerized message processor would handle these tasks, including sorting through duplicate messages, automatically. ``We're going to let the machine sort through all the messages and then present the information on the screen to the crew member,'' (Col. Michael) Mazzaro (a REACT program manager) said. After authenticity checks are completed, the processed messages, together with retargeting information, are passed via an electronic interface to the weapons system control element. Mazzaro said that although the system has been automated, ``this is not the stuff of the `War Games' scenario. Man is in the loop the entire way. He makes the decisions''... The planned modifications ``will permit LCC's to stay on alert beyond the turn of this century,'' (the Air Force) said. [The article explained the new system would be used with Minuteman, MX, and possibly future Midgetman and rail garrison MX missiles]. REACT consists of two different but related programs managed by the Electronic Systems Division (ESD) and the Ballistics Systems Division (BSD) of the Air Force Systems Command. ESD will manage development of the higher-authority communications and rapid message processing element for which GTE government systems was awarded ... $33.7 million. ... BSD awarded Ford Aerospace ... $71.3 million for development of the Weapon System Control Element, which includes rapid retargeting systems, voice communications, control consoles and displays, the weapons system processor and modifications to existing LCC trainers. . BSD officials ... estimated the total value (of the upgrade effort) at $507 million ... Ford based its architecture on the Raytheon MilVax. BSD officials have said they have not determined whether to use existing code or new code for the weapons system control element. - Jon Jacky, University of Washington.
Jon's posting re SAC's REACT missile launch ugrade is just another relentless
turn of the hair-trigger screw. Another turn is reported in this month's Air
Force Magazine, which is all about AF electronics. An article reports:
The Ground Wave Emergency Network (GWEN) [is] a
multi-stationed net of LF radio towers and receivers...
Electronic Systems Division (ESD), working with RCA, has
nearly completed installing an initial, 56-node "thin-line"
segment for flashing [one-way] emergency messages [launch
orders] to Strategic Air Command units.
With glasnost and perestroika afoot, and the JCS visiting the U.S.S.R., must we
reduce SAC's standing response time from over to under a minute? Is anyone
seriously weighing the concomitant risks?
[By the way,] for those who don't know, on May 1 this year I filed a lawsuit
against the Strategic Air Command's chain of command for launching Minuteman
and MX missiles, including the launch crews, alleging that their standing
orders, to launch the missiles immediately upon receipt of cryptologically
valid launch orders, are inherently reckless and dangerous. In particular, I
allege with particularity the risk of mistaken computer prompts causing the
accidental launch of nuclear missiles. The suit was endorsed by the board of
Computer Professionals for Social Responsibility.
In a motion to dismiss based on the pleadings, which presumes that all facts
alleged be taken as true, here is Commander In Chief General Chain's
(minion-attorney's) key argument:
The allegation of "high risk" may affect the amount of
speculation but only marginally, and it does not move the
allegation into the realm of injury in fact. At most,
plaintiff makes the general assertion that some government
officials may act in a manner contrary to law.
Several recent postings in this digest have speculated about the
accuracy/quality of strategic weapons guidance systems. Apropos of that, I
offer the following excerpts from an article by Stan Shebs, about working on
cruise missile guidance, that appeared in the CPSR/Seattle Newsletter, June
1988:
from ``My Life in a Megadeath Corporation'' by Stan Shebs
Upon graduation from Texas A&M in 1981, I accepted an offer from Boeing
Aerospace in Seattle ... I was re-assigned to work on the cruise missile.
I went off to Seattle (Kent actually) and started work. This involved
fingerprinting (a surprise) and the long long form to fill out (for a
clearance, even though I never did anything classified). Next thing was to
jump in on the work, which was to help finish up and deliver "mission planning"
software - a giant mass of undocumented Fortran intended to run on IBM
mainframes at SAC headquarters in Nebraska. My first task was to finish
testing the FORMVO module, which had to do with figuring out which VOs
(Vertical Obstructions - like trees and telephone poles) were likely to be in
the path of the missile as it flew along.
If this is confusing, well, it was to me too. After about a month, I went to
the official orientation and indoctrination, which lasted about two days.
Boeing was building the Air-Launched Cruise Missile (ALCM), essentially a robot
airplane about 6 meters long and 1/2 in diameter, powered by a jet engine of
just the right size for a go-cart, and carrying a 400-kiloton fusion bomb. The
idea was that B-52 bombers would fly up to the edge of the USSR, launch the
ALCMs, and fly away again. The missiles would then fly about 2000 km or so,
low to the ground and beneath radars all the way, to detonate at some target.
... Now the onboard software was basically done; where I came in was to help
with the software that figures out if an intended route was actually doable.
The onboard computer has only a very limited capacity, so you need a lot of
"mission planning" software to decide where to turn, how high to fly, when to
look at the ground to see if you're on course, and so forth. Another piece of
software then makes up the cute little cassette tapes that the bomber crew
loads into the missile before launching it. It's tricky, because how tight a
turn the missile can make depends on how much fuel it's used already, it could
run into telephone wires if it's flying too low at the wrong moment, the little
maps that it uses for navigation mustn't be too far apart, and so forth.
The difficulty of all this apparently didn't occur to anybody until after
the missile was working, so the mission planning software got hacked out in
a real hurry, the people that did it departed for greener pastures, and
then the rest of us were picking up the pieces and trying to turn all this
into a reasonably reliable 40,000 lines of Fortran. The day-to-day work
was like regular software stuff; debugging a program that took map data
from tapes and put them into VSAM files, writing the "Program Design" for
an already-written program (is that stupid or what), figuring out how to
compute the intersection of two polygons in space. We supposedly had a
"model" software engineering methodology; what I remember most clearly is
that half the work was done on one flavor of IBM OS, and the other half
done on a different flavor, and file transfer between the two was tricky
and time-consuming.
The fragility of something like the cruise missile and its software is
something I've spent a lot of time wondering about, and don't really have any
idea. The nuclear safety aspect seemed pretty good - there was at least some
effort to get accurate estimates of the chance of going off at the wrong time
(was 1 in 2^64 chance, I think). Navigation is considerably more problematic.
Like most missiles, ALCM relies on inertial navigation, but the error
accumulation over 2000 km is immense, and you had to be sure to have navigation
maps spaced so there would be a reasonably good chance they would be found.
("3-sigma" was the standard - position assumed to be a normal distribution.)
Now that I think about it, the 3-sigma test (98% chance) would have to be
multiplied for each map, and there might be 10-20 of them, meaning as much as
40% of missiles might not make it through all the maps... Calculations on a
sphere were a perennial problem - there was a standard joke that the safest
place in the world during a nuclear exchange was the North Pole, because the
lat/long singularity makes it impossible to target, and the worst place was 0
lat, 0 long, because the software would divide by 0 or overflow or something
while passing over the North Pole and reset to all 0s... The precision and
formality of the software was very low, but it was exhaustively tested over and
over and over again. I suppose the greatest risk of failure derives from
things that weren't anticipated during testing, such as a Siberian snowdrift
changing the topography on a navigation map...
(Regarding) statistics on software quality, the closest thing we had was maybe
a count of problem reports (hundreds, but each report ranged from one-liners to
one-monthers in terms of effort required). ... the humongous requirements
document that was our bible for how the program was supposed to work (was)
alternately entertaining and horrifying. Nothing classified, we had the odd
situation that the *data* was classified, but the *program* wasn't even rated
"confidential"! (Theory was that the Russians were supposed to get a copy,
which would set them back ten years... :-) ) ...
From the June 16 _Science_ article "Early Data: Losing Our Memory?":
"Allen Watkins, director of the USGS center in Sioux Falls, SD,
where Landsat tapes are kept, says, "90% of the data collected
before 1979 are now inaccessible." The reason: the data tapes were
recorded on old Xerox computers which can no longer be operated.
In addition, the satellite location and timing data were recorded
on a kind of video tape deck that no longer exists. Tape renewal
is another problem that looms in the future. Magnetic images
"bleed" through the layers as time passes, and tapes must be
recopied at least once every 10 years to make them usable. Watkins
says the task is already formidable, and wonders what will happen
when the Earth Observing System begins sending back the equivalent
of an entire Landsat archive every 2 weeks."
Please report problems with the web pages to the maintainer