Movatterモバイル変換

[0]ホーム
URL:

(forSAGE technical information- use you brouser's "BACK" function to return here)

Stories about SAGE

Factoids which needs a home - Apr 2014

Origins of the Internet
The first recorded description of the social interactions that could be enabled through networking was a series of memos written by J.C.R. Licklider of MIT in August 1962 discussing his "Galactic Network" concept. He envisioned a globally interconnected set of computers through which everyone could quickly access data and programs from any site. In spirit, the concept was very much like the Internet of today. Licklider was the first head of the computer research program at DARPA,4 starting in October 1962. While at DARPA he convinced his successors at DARPA, Ivan Sutherland, Bob Taylor, and MIT researcher Lawrence G. Roberts, of the importance of this networking concept.

Professor Martin Campbell-Kelly says that
a) J.C.R. Licklider was a major player in the machine/human interaction of SAGE
b) the massive SAGE effort put the US way ahead of the Brits in computers

Many people say that the IBM profits from SAGE paid for IBM System 360 development.

from a "scope dope"Gary Odle - December 2003

I just read your article on the weaknesses of the SAGE system and agree with you whole-heartedly. I was a Weapons Controller (i.e., "scope dope") at the Duluth SAGE site from 1975-76 and again for the year 1978.

I always marvelled that in our SNOWTIME excercises (SAC/NORAD Operational Weapons Testing and Evaluation ... send B-52's and KC-135's north and have them attack us) that the attackers always came in high and slow, and right in the middle of our radar coverage, neatly avoiding our blank areas. Our "kill" percentage would be about 99%. Commanders would praise us, nice reports would be written, and I would be angry that the whole thing had been a sham.

After four years in air defense I figured that if the Air Force wasn't going to take it seriously, I didn't need to be a part of it. I left the Air Force in 1979 to pursue other interests.

Controlling fighters in SAGE was fun ... like being paid to play video games ... but no way for a responsible adult to spend their career.

Gary Odle

Comment fromJoe Romito - Mar 2014
One of the earlier posts on the SAGE website used the SNOWTIME acronym incorrectly. The term stood for SAC-NORAD Operational Weapons Testing Involving Military Electronics. Its primary purpose was not to test SAGE, but rather to test ground-based Army air defense weapons in the US, which in the late 1960s were mostly Nike-Hercules missile units stationed around major population centers and military facilities. In the late 1960s there were roughly 15 defended areas around the country. I was most familiar with the ones on the west coast -- Seattle, San Francisco, and LA.

The exercise was conducted annually, against one defended area at a time. It was conducted late night-early morning to minimize interference with the FAA's air traffic control radars. In the exercise SAC aircraft would fly against the area using their maximum radar jamming capabilities. And the Nike units were allowed to use almost all of their full wartime countermeasures systems to counter the jamming. As someone who served in the San Francisco Nike brigade 1968-1970, I know that it was usually a humbling experience for the Army. I seem to recall that typical results were that Nike units would defeat at best one third of the attacking aircraft. Keep in mind that the Nike mission was to shoot down attacking Soviet bomber flights, each of which was carrying multiple thermonuclear bombs. If just one bomber in a flight completed its mission, the target city would likely have been destroyed. The sad reality was that Nike-Hercules radars were using technology from the 1950s and probably would have been no match for attacking enemy bombers in an actual wartime situation. Fortunately, we never found out for certain if this was the case.

Western Electric activities
FromRobert F. Martina - SAGE Test Director

Western Electric, part of AT&T then, was awarded the contract as system integrator for the entire SAGE System. Close to 500 WE engineers went through SAGE computer/radar school at MITRE Hanscom Field, 15 at a time. --They were responsible for the testing of all sectors in the country and turning the system over to the Airforce. Five test teams of apx. 50 each (25 at radar and interceptor bases; 25 at the direction/computer centers) were deployed at a time. Sector integration and certification testing took 9 months.--Some engineers were left behind to upgrade the system as changes came from Rand/SDC and MITRE as well as the radar contractors.

Problems with software and hardware were tracked and improvements suggested. Simulated inputs mixed with live data was one innovation made/programmed by this team.Alumni of this organization still meet annually, 2002 in Boston, to share a few memories of life on the road along way from the flag pole, the excitement of running 12 intercept missions a day and trips to find the source of permanent echos used for azimuth registration of radars.

Many of these engineers left WECo after the project phased down in the early 60's and became part of many other organizations, particularly NASA and its contractors.

R.F. Martina. ( a 5 sector man ) Senior Test Director
- Great Falls and Phoenix Air Defense Sectors

Update 10/28/02 - WECo SAGE reunion ... will be held in Cody WY in 03.

FromChris McWilliams

Subject: Computer Museum

Hi Ed,
The visit to themuseum was quite enjoyable. They have all kinds ofcomputer equipment in there, much of which cost $millions to build. I wasespecially impressed with some of the Cray super computer equipment. DagSpicer was very helpful and informative on all the various eras of computerdevelopment their display covers.

They have 2 SAGE consoles (Intercept andWeapons Tech) which are very similar to the ones I worked on. They also havecore and drum memories, plus a control panel and racks showing the thousandsof tubes it took to run SAGE. I explained to Dag how we used to spend a lotof the quiet midnight shifts playing "Battleship" over the extensivecommunication setup we had. Also mentioned the problems we had getting thevarious radar site precisely enough located in the computer to avoid gettingmultiple returns from just one aircraft.

Also, when the system startedloading up on data the "frame" time (time to run through entire program)kept getting longer. When it reached 15 seconds, we would start dumpingdata. We avoided that by controlling the data input to use only thatnecessary for the task at hand.

I went through some of their pictures, and am trying to identify some ofthe people I recognized.


This is an extended e-mail fromLes Earnest
(Table of Contents and formatting added by Ed Thelen)

Attached FYI are some articles onSAGE and related C3 systems that I wrote about ten years ago for theUsenet newsgroup comp.risks.

-Les Earnest

TABLE OF CONTENTS
SAGE-BOMARC risks

Testing the fire-up decoder
Duplexed for reliability
The C3 legacy, Part 1: top-down goes belly-up recursively
The C3 legacy, Part 2: a SAGE beginning
COUNTERMEASURES
HARDENING
PLACEMENT
The C3 legacy, Part 3: Command-control catches on
The seductive image
The C3 legacy, Part 4: A gaggle of L-systems
The C3 legacy, Part 5: Subsystem I
The C3 Legacy, Part 6: Feedback
Was there ever a command and control system that worked?
SAGE revisited

[Risks 8.74]

SAGE-BOMARC risks

This is an account of two ancient (30-year old) computer risks that werenot publicly disclosed for the usual reasons. It involves an air defensesystem called SAGE and a ground-to-air missile called BOMARC.

SAGE was developed by MIT in the late '50s with Air Force sponsorship tocounter the threat of a manned bomber attack by you-know-who. It was alsodesigned to counter the political threat of a competing system called Nikethat was being developed by the Army.

SAGE was the first large real time computer system. "Large" was certainlythe operative term -- it had a duplexed vacuum tube computer that coveredan area about the size of a football field and a comparably sized airconditioning system to take away the enormous heat load. It used anadvanced memory technology that had just been invented, namely magneticcore, and had a larger main memory than any earlier computers, though itis not impessive by current standards -- it would now be called 256kbytes, though no one had heard of a byte then.

The system collected digitized radar information from multiple sites andused it to automatically track aircraft and guide interceptors. SAGE wasdesigned to work initially with manned interceptors such as the F-102,F-104, and F-106 and used a radio datalink to transmit guidance commandsto these aircraft. It was later modified to work with the BOMARC missile.

Each computer site had about 50 display consoles that allowed theoperators to assign weapons to targets and monitor progress. As I recall,there were eventually between one and two dozen SAGE systems built invarious parts of the U.S.

BOMARC missiles used a rocket booster to get airborne and a ramjet tocruise at high altitude to the vicinity of its target. It was then usedits doppler radar to locate the target more accurately so that it coulddive at it and detonate. It could carry either a high explosive or anuclear warhead.

BOMARCs were housed in hardened structures. When a given missile received alaunch command from SAGE, sent via land lines, the roof would roll back, themissile would erect, and if it had received a complete set of initial guidancecommands in the meantime it would launch in the specified direction.

Testing the fire-up decoder

It was clearly important to ensure that the electronic guidance system in themissile was working properly, so the Boeing engineers who designed the launchcontrol system included a test feature that would generate a set of syntheticlaunch commands so that the missile electronics could be monitored for correctoperation. When in test mode, of course, the normal sequence of erecting andlaunching the missile was suppressed.

I worked on SAGE during 1956-60 and one of our responsibilities was tointegrate BOMARC into that system. This led us to review the handling oflaunch commands in various parts of the system. In the course of thisreview, one of our engineers noticed a rather serious defect -- if thelaunch command system was tested, the missile would be in a state ofreadiness for launch. If the "test" switch was then returned to "operate"without individually resetting the control systems in each missile that hadbeen tested, they would all immediately erect and launch!

Needless to say, that "feature" was modified rather soon after we mentioned itto Boeing.

Duplexed for reliability

For some reason, I got assigned the responsibility for securing approval to putnuclear warheads on the second-generation BOMARCs, which involved "proving" toa government board that the probability of accidentally launching a missile onany given day as a result of equipment malfunctions was less than a certainvery small number and that one berserk person couldn't do it by himself. Wedid eventually convince them that it was adequately safe, but in the course ofour studies we uncovered a scary problem.

The SAGE system used land lines to transmit launch commands to the missile siteand these lines were duplexed for reliability. Each of the two lines followeda different geographic route so that they would be less likely to be taken outby a single blast or malfunction. There was a black box at the missile sitethat could detect when the primary line went bad and automatically switched tothe alternate. On examination, we discovered that if both lines were bad atthe same time, the system would remain connected to the alternate line and theamplifiers would then pick up and amplify whatever noise was there andinterpret it as a stream of random bits.

We then did a Markov analysis to determine the expected time that it would takefor a random bit stream to generate something that looked like a "fire" commandfor one of the missiles. We found that expected value was a little over 2minutes. When such a command was received, of course, the missile would erectand prepare to launch. However, unless the missile also received a number ofother commands during the launch window, it would automatically abort.Fortunately, we were able to show that getting a complete set of acceptableguidance commands within this time was extremely improbable, so this failuremode did not present a nuclear safety threat.

The official name of the first BOMARC model was IM-99A, so I wrote a reportabout this problem titled "Inadvertent erection of the IM-99A." While thattitle raised a few eyebrows, the report was destined to get even more attentionthan I expected. Its prediction came true a couple of weeks after it wasreleased -- both phone lines went bad on a BOMARC site in Maryland, nearWashington D.C., causing a missile to suddenly erect and start the launchsequence, then abort. Needless to say, this scared hell out of the site staffand a few other people.

The Air Force was suitably impressed with our prediction and I wasimmediately called upon to chair an MIT-AT&T committee that had the honorof fixing the problem. The fix was rather easy: just disconnect when bothlines are bad. With good engineering practice, of course, this kind ofproblem wouldn't occur. However, the world is an imperfect place.

[Risks 9.60]

The C3 legacy, Part 1: top-down goes belly-up recursively

After more than 30 years of accumulated evidence to the contrary, the U.S.Defense Department apparently still believes that so-called command-control-communications (C3) systems should be designed and built from thetop down as fully integrated systems. While that approach may have somevalidity in the design of weapon systems, it simply doesn't work forsystems intended to gather information, aid analysis, and disseminatedecisions. The top-down approach has wasted billions of dollars so far,with more to come, apparently.

I noticed the citation in RISKS 9.52 of the article, "The Pentagon'sBotched Mission," in DATAMATION, Sept. 1 1989, which describes the latestdevelopment failures in the World Wide Military Command and Control System(WWMCCS). The cited article indicates that they are still following thesame misguided "total system" approach that helped me to decide to leavethat project in 1965. I confess that it took me awhile to figure out justhow misguided that approach is -- I helped design military computersystems for 11 years before deciding to do something else with my life.

In RISKS 9.56, Dave Davis and Tom Reid observe that current C3 developmentprojects seem to be sinking deeper into the mire of nonperformance even asthe plans for these systems become more grandiose and unrealistic.

Please understand that I am not arguing against top-down analysis oforganizational goals and functions. It is clearly essential to know whichare the important responsibilities of an organization in order to properlyprioritize efforts. Based on my experience, attempts at aiding analysisand decision-making tasks with computer applications should begin with thelowest levels and proceed upward IN THE CASES THAT WORK. Contrary to somewidely held beliefs, many such tasks do not lend themselves to computerassistance and the sooner one weeds out the mistakes and intractable tasksthe faster one can improve the areas that do lend themselves toautomation and integration.

A great deal of time, effort, and money can be save by approachingdevelopment in an evolutionary bottom-up way. It is essential toshake-down, test, and improve lower level functions before trying tointegrate at a higher level. Trying to do it all at once leads to grossinstability that takes so long to resolve that the requirements changelong before the initial version of the system is "finished." Each timeone moves up a level it is usually necessary to redesign and modify someor all of the system. It is much faster to do that a number of times thanit is to try to build a "total system" the first time because thatapproach almost never works.

Someone (Karl von Clausewitz?) once said that people who don't knowhistory are condemned to repeat it. A modern corollary is that people whodo know history will choose to repeat it as long as it is profitable.Unfortunately, the Defense Department's procurement policies often rewardtechnical incompetence and charlatanism. I will support this claim witha few "peace stories" that would have been much more atrocious "war stories"if any of the systems that we designed had been involved in a real war.Fortunately, that didn't happen.

The presumption that computer-communication system development should bedone on a grand scale from the outset is just one of many bad ideas thathave taken root within the military-industrial establishment. The reasonthat this misconception has persisted for decades is that there is nopenalty associated with failure. On the contrary, failures are often veryprofitable to the contractors -- the bigger, the better. The bureaucratswho initiate these fiascos usually move on before the project fails, so ifanyone tries to point fingers they can say that it was the fault of thesubsequent management.

While the "total system" approach is one of the more persistent causes offailure in C3 development, it is by no means the only misconceptionafloat. In subsequent segments I will review some other causes ofhistorical fiascos. All of this will be ancient history, since I got outof this field about 25 years ago. Of course, many of the more recentfiascos are protected from public scrutiny anyway by the cloak ofnational security.

[RISKS 9.65]

The C3 legacy, Part 2: a SAGE beginning

Thanks to moraes@csri.toronto.edu for pinning down my half-rememberedquotation in the preceding segment (RISKS 9.60):
> The actual quote is "Those who cannot remember the past are condemned
> to repeat it." from George Santayana's "The Life of Reason".

The grandfather of all command-control-communication (C3) systems was anair defense system called SAGE, a rather tortured acronym for Semi-Automatic Ground Environment. As I reported earlier in RISKS 8.74, some ofthe missiles that operated under SAGE had a serious social problem: theytended to have inadvertent erections at inappropriate times. A moreserious problem was that SAGE, as it was built, would have worked only inpeacetime. That seemed to suit the Air Force just fine.

SAGE was designed in the mid to late 1950s, primary by MIT Lincoln Lab,with follow-up development by IBM and by nonprofits System DevelopmentCorp. and Mitre Corp. The latter two were spun off from RAND and MIT,respectively, primarily for this task.

SAGE was clearly a technological marvel for its time, employing digitizedradar data, long distance data communications via land lines andground-air radio links, the largest computer (physically) built before orsince, a special-purpose nonstop timesharing system, and a largecollection of interactive display terminals. SAGE was necessarilydesigned top-down because there had been nothing like it before -- it wasabout 10 years ahead of general purpose timesharing systems and 20 yearsahead of personal computers and workstations.

While the designers did an outstanding job of solving a number oftechnical problems, SAGE would have been relatively useless as a defensesystem if a manned bomber attack had occurred for the following reasons.

  1. COUNTERMEASURES. Each SAGE system was designed to automatically track aircraft within a certain geographic area based on data from several large radars. While the system worked well under peacetime conditions, an actual manned bomber attack would likely have employed active radar jamming, radar decoys, and other countermeasures. The jamming would have effectively eliminated radar range information and would even have made azimuth data imprecise, which meant that the aircraft tracking programs would not have worked. In other words, this was a air defense system that was designed to work only in peacetime! (Some "Band-aids" were later applied to the countermeasures vulnerability problem, but a much simpler system would have worked better under expected attack conditions.)

  2. HARDENING. Whereas MIT had strongly recommended that the SAGE computers and command centers be put in hardened, underground facilities so that they could at least survive near misses, the "bean counters" in the Pentagon decided that this would be too expensive. Instead, they specified above-ground concrete buildings without windows. This was, of course, well suited to peacetime use.

  3. PLACEMENT. While the vulnerabilities designed into SAGE by MIT and the Pentagon made it relatively ineffective as a defense system, the Air Defense Command added a finishing blunder by siting most of the SAGE computer facilities in such a way that they would be bonus targets! This was an odd side effect of military politics and sociology, as discussed below.

In the 1950s, General Curtis Lemays's Strategic Air Command consistentlyhad first draw on the financial resources of the Defense Department. Thiswas due to the ongoing national paranoia regarding Soviet aggression andsome astute politicking by Lemay and his supporters. One thing that Lemayinsisted on for his elite SAC bases was that they have the best OfficersClubs around.

MIT had recommended that the SAGE computer facilities be located remotely,away from both cities and military bases, so that they would not be bonustargets in the event of an attack. When the Air Defense Command wascalled upon to select SAGE sites, however, they realized that their peoplewould not enjoy being assigned to the boondocks, so they decided to putthe SAGE centers at military bases instead.

Following up on that choice, the Air Defense Command looked for militarybases with the best facilities, especially good O-clubs. Sure enough, SAChad the best facilities around, so they put many of the SAGE sites on SACbases. Given that SAC bases would be prime targets in any manned bomberattack, the SAGE centers thus became bonus targets that would be destroyedwithout extra effort. Thus the peacetime lifestyle interests of themilitary were put ahead of their defense responsibilities.

SAGE might be regarded as successful in the sense that no manned bomberattack occurred during its life and that it might have served as adeterrent to those considering an attack. There were reports that theSoviet Union undertook a similar experimental development in the same timeperiod, though that story may have been fabricated by Air Forceintelligence units to help justify investment in SAGE. In any case, theRussians didn't deploy such a system, either because they lacked thecapability to build a computerized, centralized "air defense" system suchas SAGE or had the good sense not to expend their resources on such avulnerable kluge.

[RISKS 9.67]

The C3 legacy, Part 3: Command-control catches on

(Continuing from RISKS 9.65)

As the U.S. Air Force committed itself to the development of the SAGE airdefense system in the late 1950s, new weapons that did not requirecentralized guidance came to be rejected, even though some appeared to beless vulnerable to countermeasures than those that depended on SAGE. Anexample was a very fast, long range interceptor called the F-109 that wasto carry a radar that would enable it to locate bombers at a considerabledistance and attack them. As such, it did not need an elaborateground-based computer control system.

My group at MIT Lincoln Lab had been responsible for integrating earlierinterceptors and missiles into SAGE. We subsequently joined MitreCorporation when it was formed from Lincoln Lab's rib and were laterassigned the responsibility for examining how the F-109 interceptor mightbe used.

I had assumed that the Air Force was genuinely interested in seeing howthe F-109 could best function in air defense. Accordingly, we worked outa plan in which the interceptors that were in service would be deployed tovarious airfields, both civilian and military, so as to make them lessvulnerable to attack. This dispersal together with their ability tofunction with minimal information about the locations of attacking bombersappeared to offer a rather resilient air defense capability that couldsurvive even the destruction of the vulnerable SAGE system.

When we published a utilization plan for the F-109 based on these ideas,The Air Force made it clear that we had reached the "wrong" conclusion --we were supposed to prove that it was a bad idea. We apparently had beenchosen to "study" it because, as designers of SAGE, we were expected tooppose any defensive weapons that would not need SAGE.

In order to deal with the embarrassing outcome of this study, a Colonelwas commissioned to write a refutation that confirmed the ongoing need forcentralized computer control. The Air Force insisted that anyone whorequested our report must also get a copy of the refutation. Mitrenecessarily acceded. In any case, the F-109 was never built in quantity.

The seductive image

Though the designers of SAGE came to recognize its weaknesses andvulnerabilities and the Air Force should have been reluctant to build moresystems of the same type, it somehow came to be regarded as the model ofwhat the next generation of military control systems should be. Nevermind that it was essentially useless as a defense system -- it lookedgood!

The upper floor of each SAGE command center had a large room with subduedlighting and dozens of large display terminals, each operated by twopeople. Each terminal had a small storage-tube display for tabularreference data, a large CRT display of geographical and aircraftinformation (with a flicker period of just over one second!), and a lightgun for pointing at particular features. Each terminal also had built-inreading lights, telephone/intercoms, and electric cigar lighters. Thisdramatic environment with flickering phosphorescent displays clearlylooked to the military folks like the right kind of place to run a war.Or just to "hang out."

Downstairs was the mighty AN/FSQ-7 computer, designed by MIT using thelatest and greatest technology available and constructed by IBM. It had:

Remarkably, all of this new technology worked rather well. There were somefunny discoveries along the way, though. For example, in doing preventivemaintenance checks on tubes, a technician found one that was completely deadthat had not been detected by the diagnostics. Upon further examination itwas discovered that this tube didn't do anything! This minor blunder no doubtarose during one of the many redesigns of the machine.

Both the prototype and operational SAGE centers were frequently visited bymilitary brass, higher level bureaucrats, and members of Congress. Theygenerally seemed to be impressed by the image of powerful, central controlthat this leading-edge technological marvel had. Of course, General Lemayand his Strategic Air Command could not sit by and let anotherorganization develop advanced computer technology when SAC didn't haveany.

In short order the SAC Control System was born. Never mind that there wasnot much for it to do -- it had to be at least as fancy as SAGE. Whenthe full name was written out, it became Strategic Air Command ControlSystem. The chance juxtaposition of "Command" and "Control" in this namesomehow conjured up a deeper meaning in certain military minds.

In short order, Command-Control Systems became a buzz word and a horde ofdevelopment projects was started based on this "concept." The Air ForceSystems Command soon realized that it had discovered a growth industry andreorganized accordingly. The specifications for the new C2 systemsgenerally contained no quantitative measures of performance that were tobe met -- the presumption seemed to be that whatever was being donealready could be done faster and better by using computers! How wrong theywere.

[RISKS 9.74]

The C3 legacy, Part 4: A gaggle of L-systems

Martin Minow contributes some SAGE anecdotes in RISKS 9.68, including thefollowing.

> My friend also mentioned that the graphics system could be used to display> pictures of young women that were somewhat unrelated to national defense> -- unless one takes a very long view -- with the light pen being used> to select articles of clothing that were considered inappropriate in the> mind of the viewer.  (Predating the "look and feel" of MacPlaymate by> almost 30 years.)  Perhaps Les could expand on this; paying special> consideration to the risks involved in this type of programming.

While light pens did exist in that period, SAGE actually used light_guns_, complete with pistol grip and trigger, in keeping with militarytraditions. Interceptors were assigned to bomber targets on the largedisplays by "shooting" them in a manner similar to photoelectric arcadegames of that era.

Regrettably, I never witnessed the precursor to MacPlaymate, whichprobably appeared after my involvement. While I never saw anything bareon the SAGE displays, a colleague (Ed Fredkin) did stir up some trouble bydisplaying a large Bear (a Soviet bomber of that era) as a vector drawingthat flew across the screen. Unfortunately, he neglected to deal with X, Yregister overflow properly, so it eventually overflew its address space.The resulting collision with the edge of the world produced some bizarreimagery, as distorted pieces of the plane came drifting back across thescreen.

(Continuing from RISKS 9.67)

A horde of command-control development projects was initiated by the AirForce in the early 1960s. Most were given names and each was assigned aunique three digit code followed by "L." Naturally, they came to becalled called "L-systems." A Program Manager (usually a Colonel) was putin charge of each one to ensure that financial expenditure goals were met.Those who consistently spent exactly the amounts that had been plannedwere rewarded with larger sums in succeeding budgets. Monthly managementreviews almost never touched on technical issues and never discussedoperational performance -- it was made clear that the objective was tospend all available funds by the end of the fiscal year and that nobodycared much about technical or functional accomplishments.

In 1960, after earlier switching from MIT Lincoln Lab to Mitre Corp., mygroup was assigned to provide technical advice to a Colonel M., who was incharge of System 438L. This system was intended to automate thecollection and dissemination of military intelligence information. Unlikemost command-control systems of that era, it did not have a descriptivename that anyone used -- the intelligence folks preferred crypticdesignations, so the various subsystems being developed under this programwere generally called just "438L."

I had recently done a Masters thesis at MIT in the field of artificialintelligence and hoped to find applications in this new endeavor. I soonlearned that the three kinds of intelligence have very little in common(i.e. human, artificial, and military).

IBM was the system contractor for 438L and was already at work on anintelligence database system for the Strategic Air Command Headquartersnear Omaha. They were using an IBM 7090 computer with about 30 tapedrives to store a massive database. It turned out to be a dismal failurebecause of a foreseeable variant of the GIGO problem, as discussed below.

The IBM 438L group had also developed specifications for a smaller systemthat was to be developed for other sites. Colonel M. asked us to reviewthe computer Request for Proposals that they had prepared. He said thathe planned to buy the computer sole-source rather than putting it out forbids on the grounds that there was "only one suitable computer available."When I read it, there was no need to guess which computer he had in mind-- the RFP was essentially a description of the IBM 1410, a byte-serial,variable word length machine of that era.

When Colonel M. sought my concurrence on the sole-source procurement, Idemurred, saying there there were at least a half-dozen computers thatcould do that job. I offered to prepare a report on the principalalternatives, including an approximate ranking of their relativeperformance on the database task. He appeared vexed, but accepted myoffer.

My group subsequently reviewed alternative computers and concluded thatthe best choice, taking into account performance and price, was the BendixG-20. I reported this informally to Colonel M. and said that we wouldwrite it up, but he said not to bother. He indicated that he was verydisappointed in this development, saying that it was not reasonable toexpect his contractor (IBM) to work with a machine made by anothercompany. I argued that a system contractor should be prepared to workwith whatever is the best equipment for the job, but Col. M seemedunconvinced.

This led to a stalemate; Colonel M. said that he was "studying" thequestion of how to proceed, but nothing further happened for about a year.Finally, just before I moved to another project, I mentioned that the IBM1410 appeared to be capable of doing the specified task, even though itwas not the best choice. Col. M. apparently concluded that I would notmake trouble if he proceeded with his plan. I later learned that heinitiated a sole-source procurement from IBM just two hours after thatconversation.

In the meantime, the development project at SAC Headquarters was fallingprogressively further behind schedule. We talked over this problem in mygroup and one fellow who had done some IBM 709 programming remarked thathe thought he could put together some machine language macros ratherquickly that would do the job. True to his word, this hacker got a querysystem going in one day! I foolishly bragged about this to the manager ofthe IBM group a short time later. Two weeks after that I discovered thathe had recruited my hotshot programmer and immediately shipped him toOmaha. I learned to be more circumspect in my remarks thereafter.

The IBM 438L group did eventually deliver an operable database system toSAC, but it turned out to be useless because of GIGO phenomena (garbage in,garbage out). Actually, it was slightly more complicated than that.Let's call it GIGOLO -- Garbage In, Gobbledygook Obliterated, Late Output.

The basic problem was that in order to build a structured database, theinput data had to be checked and errors corrected. In this batchenvironment, the tasks of data entry, error checking, correction, and fileupdating took several days, which meant that the operational database wasalways several days out of date.

The manual system that this was supposed to replace was based on peoplereading reports and collecting data summaries on paper and grease pencildisplays. That system was generally up-to-date and provided swift answersto questions because the Sergeant on duty usually had the answers to themost likely questions already in his head or at this finger-tips. So muchfor the speed advantage of computers!

After several months of operation with the new computer system, theembarrassing discovery was made that no questions were being asked of it.The SAC senior staff solved this problem by ordering each duty officer toask at least two questions of the 438L system operators during each shift.After several more months of operation we noted that the total number ofqueries had been exactly two times the number of shifts in that period.

The fundamental problem with the SAC 438L system was that the latencyinvolved in creating a database from slightly buggy data exceeded theuseful life of the data. The designers should have figured that out goingin, but instead they plodded away at creating this expensive and uselesssystem. On the Air Force management side, the practice of hiring acomputer manufacturer to do system design, including the specification ofwhat kind of computer to buy, involved a clear conflict-of-interest,though that didn't seem to worry anyone.

[RISKS 9.80]

The C3 legacy, Part 5: Subsystem I

(Continuing from RISKS 9.74)

Of the dozens of command and control system development projects that wereinitiated by the U.S. Air Force in the early 1960s, none appeared toperform its functions as well as the manual system that preceded it.I expect that someone will be willing to argue that at least one suchsystem worked, but I suggest that any such claims not be accepteduncritically.

All of the parties involved in the development of C3 systems knew thattheir economic or power-acquisition success was tied to the popular beliefthat the use of computers would substantially improve military commandfunctions. The Defense Department management and the U.S. Congress mustbear much of the responsibility for the recurring fiascos because theyconsistently failed to insist on setting rational goals. Goals shouldhave been specified in terms of information quality or response time forplanning and executing a given set of tasks. The performance of thesesystems should have been predicted in the planning phase and measuredafter they were built so as to determine whether the project wasworthwhile.

Instead, the implicit goal became "to automate command and control," whichmeant that these systems always "succeeded," even though they didn't work.Despite a solid record of failure in C3 development, I know of just onesuch project that was cancelled in the development phase. That wasSubsystem I, which was intended to automate photo-interpretation and wasdeveloped for the Air Force by Bunker Ramo, as I recall.

The "I" in the name of this project supposedly stood for "Intelligence" or"Interpretation." This cryptic name was apparently chosen to meet theneeds of the prospective users in the intelligence community, who liked topretend that nobody knew what they were doing. This pretense occasionallyled to odd conduct, such as when they assigned code names to variousdevices and tried to keep them secret from outsiders. For example, asecret name was assigned to one of the early U.S. spy satellites -- as Irecall it was Samos -- but when that name somehow showed up in the popularpress they tried to pretend that no such thing existed. In support ofthis claim, everyone in the intelligence community was directed to stopusing that name immediately.

When I attended a meeting in the Pentagon a few days after this decree andmentioned the forbidden word, the person operating the tape recorderimmediately said "Wait while I back up the tape to record over that!"This was a classified discussion, so there was no issue of publicdisclosure involved, just the belief that there should be no record of thenewly contaminated name.

Sometime in the 1981-82 period, the Air Force decided to terminate thedevelopment of Subsystem I. A group of about 30 people from various partsof the defense establishment, including me, was invited to visit thefacility in suburban Los Angeles where the work was going on to see if anyof it could be used in other C3 systems. We were given a two daybriefing on the system and its components, the principal one being amultiprocessor computer.

The conceptual design of this Polymorphic Computer, as they called it, wasattributed to Sy Ramo, who had earlier helped lead Hughes Aircraft andRamo-Wooldridge (later called TRW) to fame and fortune. The architectureof this new machine was an interesting bad idea. The basic idea was touse many small computers instead of one big one, so that the system couldbe scaled to meet various needs simply by adjusting the number ofprocessors. The problem was that these units were rather loosely coupledand each computer had a ridiculously small memory -- just 1K words. Eachprocessor could also sequentially access a 1K buffer. Consequently it wasvery awkward to program and had extremely poor performance.

I sought out the Subsystem I program manager while I was there and askedif our group was the only one being offered this "free system." He saidthat we were just one of a number of groups that were being flown in overseveral months time. When I asked how much they were spending on tryingto give it away, he said about $9 million (which would be equivalent toabout $38 million today). The Air Force Systems Command seemed to betrying desparately to make this program end up as a "success" no matterhow much it cost. When I asked why the program was being cancelled, I gota very vague answer.

I did not recommend that my group acquire any of that equipment and as faras I know nobody else did. The question of why Subsystem I was cancelledremained unresolved as far I was was concerned. It is conceivable that itwas because they figured out that it wasn't going to work, but neither didthe other C3 systems, so the reason must have been deeper (or shallower,depending on your perspective). My guess is that they got into some kindof political trouble, but I will probably never know.

[RISKS 9.97]

The C3 Legacy, Part 6: Feedback

[My apologies for the gap in this series -- I'm running for City Councilcurrently and don't seem to have enough spare cycles. -Les]

Was there ever a command and control system that worked?

My opening remark in RISKS 9.80 was: "Of the dozens of command andcontrol system development projects that were initiated by the U.S. AirForce in the early 1960s, none appeared to perform its functions as wellas the manual system that preceded it." Gene Fucci, who worked on the AirForce satellite surveillance programs as a project engineer on SAMOS andlater as Field Force Test Director of MIDAS, found my remarks "somewhatdistorted" in that he believes the satellite command and control systemsworked well.

I will plead relative ignorance of those systems, but note that they werecalled just "control systems" until "command and control" became abuzzword in the early 1960s. I do not wish to take the position that allsystems to which the term "command and control" or "command-control-communications" was eventually applied were failures -- just that all ofthe dozens that I knew of were failures.

SAGE revisited

Some of the earlier C3 Legacy postings on SAGE have found their way via acircuitous route to an old friend of mine, Phil Bagley, who also helpeddesign that system. Phil has now sent me snail-mail that takes a differentview of that program, as follows.

"I think that you have discovered what is behind the curtain. In case youhaven't, let me tell you my view. The motivation behind a big militaryelectronic system such as SAGE or BMEWS is _not_ to have it work. It isjust to create the _illusion_ that the sponsor is doing his job, andperhaps peripherally to provide an opportunity to exercise influence.Lincoln Lab and MITRE had no motivation to point out the obvious -- thatthe emperor had no clothes. If you had asked a responsible think tank whohad no stake in the outcome how to deal most effectively with the issues,you would have recommendations very different from those that guided theelectronic systems developments.

"Now it wasn't all for naught. Out of SAGE, computer technology got a bigboost. IBM learned how to build core memories and made a lot of moneybuilding machines with core memories. Lots of people like you and me gotgood systems and programming training (I still write programs). Ken Olsenlearned how to design digital equipment and ultimately gave the world afew billion dollars worth of Vaxes.

"The moral of all this is: When things appear not to make sense you veryprobably are looking at it from the `wrong' point of view. Another wayto say it: It's pretty hard to fool Mother Nature, so if it appears thatshe is being fooled, try to find a point of view which doesn't imply thatshe's being fooled."

While Phil and others may be comforted by this view, I will argue that itamounts to nothing more than "Whatever is, is right," which grates on myrationalist soul. I believe that if a comparable amount of governmentmoney had been invested in research, or on a more tractable application,that computer technology would have advanced much more quickly thanactually happened.

I believe that as soon as MIT and MITRE engineers figured out that theyhad designed an unworkable system, they had an ethical obligation to pointthat out to their sponsors. Instead they (we) helped perpetuate the myththat it worked so that we could continue in our beloved technologicallifestyle.

Phil's mention of Ken Olsen reminds me that we gave a going-away party forhim and Harlan Anderson at the MIT Faculty Club when they left to formtheir company to make transistorized digital modules based on experiencein building the TX-0 and TX-2 computers at Lincoln Lab. We told them thatthey could have their old jobs back after their start-up went belly-up, aswe all expected. In fact, that reportedly came rather close to happeningmore than once in the first couple of years, but somehow DEC squeekedthrough and grew a bit.

Requiem: the SAIL computer, which would have reached the grand old ageof 25 next week, is slated to retire tonight and die in the near future.It has provided an intellectual home for a very productive generation ofresearchers and will be remembered fondly.

-Les Earnest

From a rec.aviation.military posting


(beginning of original message)

Subject: Re: F-102/F-106
From: waltbj@oneimage.com
Date: 1998/11/15
Newsgroups: rec.aviation.military
tomnaylor@mindspring.com (Tom Naylor) wrote:

...
Ah, yes, Data Link! I was in the 326 FIS at Richards Gebaur AFB ( Dicky Goober) known on the air as "RG Tower". I flew a lot of test missions withthe SAGE center there tryiong to debug data link. The original setup was 'frequency division' D/L, know as 'fiddle'. And fiddle we did, for severalyears, until they gave it up as hopelessly unreliable and replaced it with'tiddle', Time Division D/L. This worked amazingly well, so much so thatR/T almost faded from use. We would give and armaments sfaety and oxygen check on initial contact and the SAGE controller would acknowledge our call.

Simultaneously he would transmit to us a standardized test message. If it didits thing properly we were receiving valid signals and would then "Follow Dolly"The next call we made would be 'Judy' (taking control) and "MA" - mission accomplished" or rarely (102 being by now rather reliable) "MI" - missed intercept.

From hating Fiddle we grew to love Tiddle because the silence was so refreshing.

But getting to that point was aggravating . .
I well remember one of the first test missions with SAGE. I spent most of my timealoft Essing madly back and forth chasing the D/L steering command dot. Back on theground we dissected the mission with the SAGE controller and several programmers. At lastwe discovered there had been no allowance made for aircraft turn radius, consequently I was overshooting all turns by as much as 6 to 8 miles. The radar would see me out of positionthe FSQ7 computer would issue a correction which of course I would again overshoot . . .

But like I said after awhile it got pretty good. Especially after they diaabled the RTB (return to base) function for the nuclear-armed BOMARC missile. (One free spirit during a CPX decied to see what would happen if he RTB'd a BOMARC - the notional missile did a 180and headed back home!)

BTW the FSQ7 at the time was the world's finest computer with its 100 KB (kilobyte) corememory. And its vacuum tubes and 15 tons of airconditioning power! The computer I'm typing this on is several orders of magnitude more capable and dozens of magnitudes more reliable!

Speaking of vacuum tubes, I am pretty sure the IRSTS system fro the MG10 was solid-state.It's only break mode I ever saw was loss of LN2 coolant.

Walt BJ ftr plt ret

(end of original message)

from an earlyOperational Planner -Frank Mertely

I was one of a group of 5 or 6 guys in a special project to prepare the operational and implementation plan to install the [SAGE] system in the AIr Defense Command way back in 1954 in Colorado Springs.

We had a large task, but with the help of a lot of people we installed the first computer at Fort Dix, NJ on schedule. This would not have been possible without a lot of groundbreaking effort by the Lincoln Lab people, Western Electric, IBM and a whole lot of other conractors.

My task was to prepare the budget for equipment, facilites, communications and personnel for submission to the folks at the Pentagon. Since it was a National Security Council priority, it was a little easier to gain approvals there and the Congress.

I made many trips from Colorado Springs to New York City for coordination meetings. I stayed with the project for about two years and then went to the Air Command and Staff College and many other places after that.

I would like to make one comment on siting the facilites. I noted that some one stated that we sited the facilities on SAC bases where the had the best O~Clubs. That was not the case when we started .Our first priority was to site away from major target areas and availabilty of communications and to take advantage of existing facilites where possible.That is why you see places like Fort Lee, Topsham, Fort Custer and Truax Field. A number of ADC bases were selected. Among them were: Duluth, Grand Forks , K.I. Sawyer and others that were programmed for ADC interceptor bases.

Unfortunately, when General Lemay dispersed the bomber and tanker forces a few years later some of these bases took on the SAC flavor and did increase the vulnerability of the Sage system.

It is too bad that the transistor did not come along sooner as we could have put them underground at much lower cost since we would not have needed all that space for the computer, less air conditioning and back-up power. So we had to live with the technolgy that we had .

Regardless, it was a great system and a challenge to get us into the computer age.It was a tough job and it was nice to associate with so many skilled and dedicted people.

Thanks for helping me to recall my work on the system. Keep up the good work.

Best regards.

Frank

Locations of SAGE systems


as perhttp://www.radomes.org/museum/
DC-1: McGuire AFB, NJ DC-2: Stewart AFB, NY DC-3 / CC-1: Hancock Field, NY DC-4: Fort Lee AFS, VA DC-5: Topsham AFS, ME (blockhouse demolished) DC-6: Fort Custer, MI DC-7 / CC-2: Truax Field, WIDC-8: Richards-Gebaur AFB, MO DC-9: Gunter AFB, AL DC-10: Duluth IAP, MN DC-11: Grand Forks AFB, ND DC-12 / CC-3: McChord AFB, WA DC-13: Adair AFS, OR DC-14: K. I. Sawyer AFB, MI DC-15: Larson AFB, WA DC-16: Stead AFB, NV DC-17: Norton AFB, CA DC-18: Beale AFB, CA DC-19 / CC-4*: Minot AFB, ND (* CC-4 blockhouse built, but AN/FSQ-8 never installed) DC-20: Malmstrom AFB, MT DC-21: Luke AFB, AZ DC-22: Sioux City AFS, IA

If you have comments or suggestions, Send e-mailto Ed Thelen


[8]ページ先頭
©2009-2026 Movatter.jp