Oral-History:Eberhardt Rechtin
About Eberhardt Rechtin
Eberhardt Rechtin is a systems engineer whose communications and systems architecting skills have been focused on deep space and national security applications throughout his career. He received a B.S. in electrical engineering from Cal Tech in 1946, having participated in an accelerated degree program through the Navy; he received his Ph.D. in electrical engineering from Cal Tech in 1950. While doing his doctoral work, Rechtin worked on ballistic missile and communications technology at JPL and developed an integrated, coded phase lock system in 1957-1958. In 1967 he became director of the Advance Research Projects Agency (ARPA) and significantly changed its funding patterns while redefining its operations and defending its existence during the Vietnam War. After becoming Assistant Secretary of Defense for Telecommunications, Rechtin brought his communications and systems experience to Hewlett-Packard in 1973 and helped manage their development of "smart systems." In 1977 Rechtin became president and CEO of the Aerospace Corporation, where he worked to move Aerospace into the satellite mission business. As president and CEO, Rechtin identified himself as Aerospace's chief architect and strategist and, through his applications of systems architecting, shaped Aerospace's research and funding operations and improved the company's reputation significantly. Finally, in 1987 Rechtin became a professor of electrical engineering at the University of Southern California. He retired in 1995.
The interview begins with a discussion of the circumstances of Rechtin's education at Cal Tech and how he carried lessons he learned as a graduate student into his professional life. Rechtin describes his experiences with communications systems development at JPL, including some discussion of his activities in technical intelligence. After a description of his Ph.D. research, Rechtin discusses how he gravitated towards communications EE and his work at JPL on radar contact with the planet Venus. After describing his development of the coded phase lock loop at JPL and its eventual declassification, Rechtin treats aspects of the U.S. space mission briefly and then discusses at length the concept of systems architecting, using the Bell System as a model of a well-architected system. He describes his work at ARPA, Hewlett-Packard, and Aerospace in terms of his implementation of systems architecting at the managerial and executive levels.
Describing his experiences as director of ARPA, Rechtin points out how his struggle to justify the existence of a government R&D agency during wartime incorporated his (re)definition of ARPA's AGILE program in South Vietnam and the United States' role in the Vietnam War. His discussion of his work at Hewlett-Packard emphasizes the company's implementation of systems architecting and their successful development of "smart" systems well in advance of their competitors. His discussion of Aerospace focuses on his perception of himself as chief architect of management and covers his strong push for affirmative action and for continued work with the federal government, both of which contrasted with past president Ivan Getting's policies. He mentions briefly his reasons for leaving Aerospace and his move to USC. The interview concludes with a discussion of the role played by IRE/IEEE in his professional development.
About the Interview
EBERHARDT RECHTIN: An Interview Conducted by Frederik Nebeker, Center for the History of Electrical Engineering, February 23, 1995
Interview # 241 for the Center for the History of Electrical Engineering, The Institute of Electrical and Electronics Engineers, Inc.
Copyright Statement
This manuscript is being made available for research purposes only. All literary rights in the manuscript, including the right to publish, are reserved to the IEEE History Center. No part of the manuscript may be quoted for publication without the written permission of the Director of IEEE History Center.
Request for permission to quote for publication should be addressed to the IEEE History Center Oral History Program, IEEE History Center, 445 Hoes Lane, Piscataway, NJ 08854 USA or ieee-history@ieee.org. It should include identification of the specific passages to be quoted, anticipated use of the passages, and identification of the user.
It is recommended that this oral history be cited as follows:
Eberhardt Rechtin, an oral history conducted in 1995 by Frederik Nebeker, IEEE History Center, Piscataway, NJ, USA.
Interview
Interview: Eberhardt Rechtin
Interviewer: Frederik Nebeker
Place: Palos Verdes Estates, CA
Date: February 23, 1995
Family Background
Nebeker:
We are talking with Eberhardt Rechtin at his home in Palos Verdes Estates, and this is Rik Nebeker. You were born January 16, 1926 in New Jersey. Where?
Rechtin:
In Orange, New Jersey, near where Edison's shop was.
Nebeker:
Right. It's a West Orange site today. I visited. What was your family background?
Rechtin:
My family background was German. My mother's family was the Farrers. On my father's side there were Eberhardts and Rechtins, and that's where I got my name, Eberhardt Rechtin. My dad was Eberhardt Karl Rechtin and I have one sister, now named Joan Lincoln. We moved almost immediately to South America just before the Depression started. My dad as a green engineering naval architect went to Colombia to build steel houses.
Nebeker:
How was he employed?
Rechtin:
He was employed, I believe, by United Fruit to build housing of steel because the army ants were chewing up all the wooden structures. They decided that steel was better. Unfortunately, we no sooner than got there (I was very young of course) then the Depression hit and there was no work down there. We came back and went to Pittsburgh, Pennsylvania where he worked as a draftsman for a while and then as an engineer designing and building barges and boats for the Mississippi and Ohio Rivers. We then moved to New York, to Long Island where he continued his work with then Bethany Shipbuilding Company. Later we moved to California in early 1941, and by that time I was in high school. And the war started and I was a senior then age seventeen. I volunteered in as part of the Naval V12 program.
Nebeker:
I've heard of that.
World War II and Cal Tech
Rechtin:
I had already been accepted to Cal Tech and I wrote a letter to the Navy suggesting that if they had a unit at Cal Tech, I would like to go there. I fully expected that the government would do as it always does and send me to the East Coast. Well, somebody made a mistake and in the end they sent me to Cal Tech after all. So, I spent the next two and two-third years at Cal Tech getting an undergraduate degree.
Nebeker:
In two and two-thirds year?
Rechtin:
Yes. Because those are the accelerated years.
Nebeker:
You went year round?
Rechtin:
I went year round and at high speed. A group of us that had come in already admitted to Cal Tech rebelled at the idea of taking what Cal Tech rather condescendingly called "the Navy version" of their courses, the presumption being that we were not up to the standards of Cal Tech as a group. So the Navy people were supposed to take a different set.
Nebeker:
Now you were admitted apart from that program, is that right?
Rechtin:
Yes.
Nebeker:
But some of the people in the V12 program —
Rechtin:
Most of them had not been previously admitted; they were sent from all over. Some of us rebelled and we said, "We insist on not taking the Navy version courses, but taking Cal Tech's courses." The Navy and Cal Tech got together and said it was all right if these guys want to do that and they are foolish enough to take the risk. The risk was that if you didn't do it well, out to the fleet you went. We said, "We don't care, we're going to take the full courses." So we took all the Cal Tech courses; I was second in the class of 600. And the rest of us did comparably well. There were several incentives to do well at Cal Tech.
Nebeker:
Who were the most influential teachers you had at that time?
Rechtin:
Well, let me continue a little further, because the war ended just before I graduated. I was in an ideal position. I had been sent to Cal Tech during World War II and it ended in 1945 and then in February of 1946 I was graduating. As it turned out, I didn't spend the war on duty in the fleet, but spent it in the university. Then we were eligible for the GI Bill, and I turned right around and said, "I would like to go to Cal Tech to get my doctorate degree." I bypassed the master's on the way; I guess I was a high-risk type. The primary professor who influenced me the most then, my mentor, my guide who was later my boss and who I am pretty sure sponsored me on all kinds of things, was Dr. William H. Pickering. He was a professor at Cal Tech in electrical engineering and he taught a course out of the Gardener and Barnes book, which essentially was a course on control theory. To some degree there wasn't very much at that time to go on. The other professor was Professor Frederick Lindville, who probably before anyone else had the idea of systems. He taught a course called Engineering and Mathematical Physics because nobody knew a better term; he combined the whole set. He gave us what we essentially now recognize as system problems, where we had no idea what the technical material was going to be or had to be. We had to go find it out. Then we had to solve the same kinds of problems that the Cal Tech faculty was solving for the Navy, in particular during World War II. Those problems became famous and were given to small groups of students to solve and to see whether we could come out with comparable answers.
Nebeker:
Now these are real life problems?
Rechtin:
These were real life problems. For example, one of them was that the Navy was having difficulty in launching torpedoes off of airplanes; it was generally a disastrous kind of military tactic in any count. The torpedoes would bounce off the surface of the water and come back and hit the airplane or they would die; neither is what you wanted them to do. The question is what do you do about that? Cal Tech built a test ramp out in the mountains where the torpedoes are then launched off the end of the ramp in ways comparable to what an airplane might do and then bounced into a lake, so we could see what would happen. They gave the students the problem, cold turkey; what are the parameters of the ramp? Well, you had to know the coefficient of friction between the torpedo and the ramp. We said that we didn't know what it was ahead of time. We said, "We don't know what happens when the torpedo hits the water," and they said, "We don't either. Go find out."
Nebeker:
You were working as groups on these problems?
Rechtin:
Typically, two or three students would work on it. We were expected to turn in well-prepared typewritten engineering solutions to this. It was a fantastic course, something which led us into thinking. As Cal Tech often liked to say at the time, "Start with the particle." In other words, start with the most elementary unit of the world and think it through. The other influential professor, not by any willingness of his own, I'm sure, I think was William R. Smythe. He taught a famous course, Electromagnetics, which was a barrier course. It was designed to throw out Ph.D. students who couldn't cut it.
Nebeker:
Charles Townes told me exactly that. He was a research assistant or teaching assistant for that course.
Rechtin:
- Audio File
- MP3 Audio
(241_-_rechtin_-_clip_1.mp3)
Yes. Well, I wish I had had him as a teaching assistant to tell you the truth. Smythe was not going to teach; you were supposed to learn. So he wouldn't tell you that he wouldn't tell you indeed how to solve his problems. You were to work from the book. Here I was, not boasting, a straight A+ student everywhere I'd ever been, and I flunked that course.
Nebeker:
This is a graduate course.
Rechtin:
This is a graduate barrier course to a Ph.D. I flunked it, absolutely cold out, and it was as I recall a three-quarter course — you had three parts to it. Well, that meant no Ph.D., but Cal Tech always said one could have a second try at it, and if one can get your average above the necessary C or whatever it was, well all right. Very few people ever made it the second time if they couldn't figure it out the first time. So I spent the summer going through every problem in Symthe's book. It got awfully tedious after a while and suddenly the light hit; I saw the key to the lock. I hadn't seen it before and nobody would tell you, least of all Smythe. For every one of his problems, and later I learned for a lot of the world's problems, there is a simple way of getting the answer and the standard way of getting the answer. The standard way takes a lot of time and a lot of grinding, and a lot of work. The simple way you get by sitting back and thinking, "Are there whole chunks of this problem that have already been solved?" For example, did some famous mathematician solve a certain kind of equation? Absolutely, and it is expressed in terms of Bessel functions. I didn't know that; I didn't know a Bessel function from a rock on the ground when I began this thing. Anyway, they are solutions to boundary conditions and if you express them in Bessel functions, they essentially work out what all the mathematical answers are. It suddenly occurred to me that all of these problems were all of the same type.
Nebeker:
So he designed these all to have a simpler way?
Rechtin:
There was always a simple way. His course consisted of a set of problems in an exam session where they were always four problems. If you solved them in the simple clear way that Smythe was aiming for, which he never told you, naturally, you could do the whole thing in maybe half or three quarters of an hour, well within the one hour time limit, with absolutely no problem. If you didn't you were lucky to get past two of them. Well, I had been struggling the hard way, not understanding what the message was. So I then went back and said, "I want to take the first semester over again and at the end of the first semester, I want to take the whole course by exam." Smythe thought, "This guy is a lunatic," because he told me so. Well, I took the semester and cracked it with a straight A. Then I went in to take the whole course by exam, and he looked a bit pitying me in the end, I guess. I sat down for, as I recall, a four-hour exam, a whole slew of problems. In about an hour and a half I finished them all and I walked into his office and said, "This is what I can do." He looked up thinking, "This guy has flunked."
Well, he said he would look at it and looked at it and saw that they were all done. All of them were clean, perfect, straightforward, so I got an A for the course as a whole on top of that. That taught me a number of things. One of the things that I found out was that there were what I call the three line solutions. In many problems you can show what the proof is in just very few lines or a few points in logic worked carefully through. There is a clean, clear way of doing it. That had a profound influence on the rest of my life, which is the reason I told the story in detail.
JPL and Phase Lock Receiving System
Rechtin:
When I first went to the Jet Propulsion Laboratory, I went there before I got my Ph.D. I was at JPL for the final year and that was because I was wiped out on my Ph.D. exam by Bell Labs solving my problem before I could solve it so I had to start all over again but that's a different story. Anyway, I went to JPL to work on problems of jamming and anti-jamming of signals because the defense department was still very active. Even after World War II, the Korean War started up.
Nebeker:
What sort of signals?
Rechtin:
These were primarily guide-missile signals because JPL was working on guided missiles at the time. They were using radio guidance and they were concerned about these things being jammed. A group of us included Saul Galan, who is now a professor at USC and a member of the National Academy. Eva Turby, a professor who went on to found a lot of companies which have done very well, also worked in my group and went on to become a member of the National Academy; Dante Yula went to Brooklyn Poly Tech, became a professor, member of the National Academy; Walt Victor, who was essentially the chief engineer on the architectural things that we came up with and the principal reason the deep space network and communications actually worked, went on to become a member of the National Academy. Of the seven-person group I had at the time, six were members of the National Academy because of what we did.
How did we start? We started out by thinking, "Well, we ought to do some self-learning here." One of the things that we had to learn about was Wiener's famous "yellow peril." That was a thesis-like thing that Norbert Wiener put together; it was called the "yellow peril" because it came out in a yellow-covered book. It was a proof of how you could extract the signal from noise essentially using spectral techniques. By spectral I mean you look at the spectrum of the signal that you anticipate and you look at the spectrum of the noise. You look at the two and you run through all the mathematics and integral equations and lots of complicated things. It will then show you what the transfer function of your box ought to be in order to get the most signal for the least noise, at least on statistical average.
This "yellow peril" started out with the statement of the problem and started to go through forming an analysis. It went on and on. In the middle there was this elaborate integral equation. It kept going on and on and then at the end of the book it said QED. Well, what was it saying? The equation didn't look familiar to anybody; it was a strange-looking thing. Well, it turned out that in Pickering's course, the one I mentioned on Gardener and Barnes, we had to learn the Laplace transforms. It suddenly occurred to me that all this stuff that Wiener had been going through was because of a property of the Fourier transforms which is very difficult to take into account. That is, the Fourier transform assumes that the signal has started at minus infinity and is going to plus infinity. All of the difficulties that Wiener had gone into were because of that characteristic. It occurred to me that maybe I could prove it in three lines with the Laplace transform. The Laplace has an interesting characteristic, a built-in damping function, so the assumption is by the time you get to infinity it will be negligibly small — complex variables will show you the same sort of thing.
Well in three lines I showed not only how to get that integral equation but also how to state it in Fourier terms. I transformed it by complex algebra into a very simple algebraic thing that you could do. Then I realized it was true not only for a simple sine wave going through noise, which is what he had analyzed, but for any signal form in a closed loop control system. I could design control systems confronted with heavy noise, and no one knew how to do that when we started. We had to study Cromaire's book on statistics; we had to study all kinds of things just to make sure that we'd end up on some [unintelligible passage]. But it led in turn to what people now call the phase locked loop. I showed the underlying theory of what a phase locked loop would be confronted with noise, and most importantly that was the best you could do. You could not do any better; there's a remarkable proof that we had, but you had to state it in engineering terms that people could use and apply to any desired application.
Why did that turn out to be important? Because, later on in the career of JPL, we were confronted with the problem of communicating to the edge of the solar system. I was told by Nobel Prize winners that it would not be possible really to communicate to the edge of the solar system. If you could, you couldn't send back enough interesting information. You would have to have bandwidths of your receiving system wide enough to account for the Doppler shifts. If you did that, you had to send megawatts of power back from enormous antennas at the edge of the solar system. Nobody knew how to do that with any finite wait; any worthwhile wait anyway. Well, I sat down and figured out, "Wait a minute. We could track the Doppler. There is no reason we have to have a band width equivalent to the maximum spread that you hear on the train going by." All you had to know was more or less where it started. The rest of it was controlled completely by simple mechanics because Newton's Laws were going to tell you what you were going to do and you could compute what the Doppler was going to be. The filter bandwidth you needed was only enough to find out that single parameter. The amount of information in that single parameter as to what's the Doppler frequency is very small. The only way it can change in the gravitational field is through acceleration, which is another simple parameter to find. If you could find the position and the velocity and the acceleration, the total number of bits that you were looking for in finding the carrier signal was very small.
So we built phase lock receiving systems that had the equivalent bandwidth at ten gigahertz of ten cycles. That meant we had what was then called a Q of 108, unheard of at the ratio of bandwidth to the total signal. There is so such thing; there is no mechanical thick filter that you could build in a Q of that sort. That meant we could detect very small signals. As you know, it is about ten watts with a ten-foot antenna at roughly ten billion miles that is picked up routinely. Given that, when the problems came up that NASA had, we came up first with the system called Microlock. I don't remember the military equivalent system, which was called Codorac. It included ranging, velocity, command and everything else. We found that you could determine where you were in the solar system relevant to the planets with extraordinary accuracy by using radio systems far better than you could with anything else. The precision with which you could near an outer planet was going to be within about a hundred miles at roughly ten billion and that was not going to be all that difficult to do.
Now, nobody believed all this when we started but I knew what to do; I was the architect. I figured out that it was possible to do, and we began to demonstrate it. In due course, JPL wound up building the deep space network and we wound up determining all of the velocity position angular stuff for navigation in the solar system. We had worked out what kinds of commands you could send. We collaborated with MIT-Lincoln, my good friend Bill Davenport, working out how you treat different kinds of systems which are coded, using essentially some of Shannon's ideas, and with all of that we came up with a completely integrated coded phase lock system. It was a completely different architecture from anything I have ever seen before.
Nebeker:
When was this?
Rechtin:
That was 1957. We made proposals on how to do all this in the early part of 1958, and everything came up to the surface.
Deep Space Network and Victor's Rule
Nebeker:
Yes, I read though the deep space article you referred me to. The deep space network evolved out of that initial group that was looking at jamming signals.
Rechtin:
Yeah, that's right.
Nebeker:
And the same people carried on to work out this?
Rechtin:
Different ones came in at different times. Saul Galan came in around 1956, Andy Perturby roughly a little later than that. Walt Victor was very early. He and I and Bob Stevens essentially put together the early systems. I was always the theoretician, the one that said, "We ought to be able to make it work this way." Victor took on what were very practical problems which were keeping us from getting there. One of them sounds strange now; all the digital systems around had a hum — a sixty-cycle hum. We were demanding such precision and such sensitivity of these receivers that anything, a sixty-cycle hum from the power supply, could disrupt it completely. We were going to be asking for systems reliability beyond anything anyone had ever done before because we were going to ask for these systems to go up into a hostile environment of space. There was no way of getting to them; you couldn't adjust anything. If it failed you lost the mission.
I said, "Look. Our communication and navigation system must fail last because if we fail nobody will know what happened. So we must fail last. We must give out a signal after everything else is essentially gone or at least enough trends up to the point that the power system goes out altogether, but something's coming back." It was one of the reasons Galileo was still sending signals even without its big antenna. They have kept that idea the communications must fail last. That led us into quality design problems which also had never been heard of before. There was a famous Victor's Rule, from Walt Victor. He said, "We are going to operate our grounds stations with all the racks closed." It was a very simple paradigm, but it meant that you could not get at the knobs. You could not adjust things. When the mission started, all the doors were closed and he put locks on them; they were closed and now they had to work. We had to do it with vacuum tubes, and he came up with the designs that essentially immersed the vacuum tubes in blocks of aluminum so that the heat would be conducted away. They would always run at a controlled or relatively modest temperature.
Nebeker:
I don't quite understand the value of Victor's Rule for this.
Rechtin:
The value was that it forced us to make equipment which was so stable, so hum-free, so free of defects that you didn't need to go to the back of the rack and do a lot of test measuring. It just worked. No matter what happened, it was going to work.
Nebeker:
That is certainly essential for the systems on the space probe, but it's not clear that it is necessary for the ground stations.
Rechtin:
Well we took the same design, put it on the spacecraft, and it worked. There the problem was that you have no convection, so you can't depend on the air to cool things off. There is nothing better than putting it in a block of aluminum, because then you can conduct it away to whatever radiator you want to build somewhere else. If the ground station failed and you lost the signal it was just as serious as if you lost it in space. It is true that you can do some repairs, put in some redundancy on the ground, and do all those things. But, many of these operations, flybys, for example, are going to occur at a certain day, at a certain time. At that time you must work absolutely. You can have a few glitches between now and then. For the ground systems and spacecraft equipment we built, in I think thirty years, there has yet to be a failure. We also had more piece parts than anybody else and we never failed. That demanded a kind of discipline that earned me the name in some corners as "Depression" because I was just adamant. I was not for "If isn't broke don't fix it." I was, "If it can break we'll fix it first." That later became a basic tenet of all spacecraft engineering. It wasn't because of me but because a lot of people saw the same thing.
When I was at Aerospace later in my career we looked up and we found we had never had anticipated failure in satellites and spacecraft, because if it was anticipated we fixed it ahead of time. The failures we got were unanticipated, which means that the failure rate was pretty low because we worked awfully hard. JPL used to say, "JPL means just plain luck," because we had more examples of just plain luck. One day I went and talked to Bob Parks, who was one of my idols at JPL. He was my senior by a couple of years and he ran the spacecraft program. He said, "Well, Eb, you got something here. But if you work at things hard enough and long enough and really think hard enough about them, then the statistics say that half the time the breaks will go in your favor, and the other half of course they won't. But at least half the time they will go in your favor, so you'll modify Murphy's Law by an awful lot of hard work." And such things happen; spacecraft healed themselves and we never knew why. In the Mariner series things weren't working, and the only explanation we finally had to come up with was that a rock came out of space and bashed the satellite and the spacecraft so well that we couldn't put it back in position again. It was the only explanation that I could come up with; nothing else could have done it. The progression from an equation to a method to a set of hardware to full-scale missions was essentially my background from roughly high school all the way through about 1967.
Technical Intelligence Work
Rechtin:
That particular race into the space was against the Russians, and that led naturally into the government coming to me and others and asking for help on the intelligence side to try to figure out what the Soviets were doing at the same time. It meant among other things: "Do we or don't we do an Apollo program? Can we do some of the others?" And so one of the other threads in my careers has been long-standing devotion to technical intelligence. All of that is classified, but they are beginning to declassify it now, particularly during the early years of what happened and what did happen. I was one of the very few who was willing to predict that the Soviets did indeed have a lunar program, and they did intend to go to the moon, they did intend to go around the moon before we did, to essentially deflate Kennedy's dream. As to whether they would land or not, I wasn't willing to go that far, but I said I thought they were going to go around the moon before we did.
Nebeker:
Were you hired by the military?
Rechtin:
No. That's all done for people like myself as volunteer consultants. We're already being paid by the government when working for NASA or JPL. I have never taken a fee for any governmental work.
Nebeker:
Are you free to tell me how this was work was arranged for?
Rechtin:
Well, yes. A stranger, a very quiet guy, showed up one day and introduced himself. He said he had a set of tapes and he wanted me to look at them. I said, "Well, can you tell me at least what they are about?" I was also in charge of ground instrumentation for JPL at the time. He said, "I can't tell you much about this," and I said, "Nothing at all!" And he said, "No, I can't tell you much about it." I realized that it must have something to do with ballistic missiles, so we put on the tape machine, began to look at it and analyze it. The guy showed up, and I said, "It looks to me as though you are looking at essentially quiescent telemetry signals from a guided missile from a site that must be about 1,000 feet up above a lake or an ocean someplace." It looked as though I hit him in the face with a hot towel and he said, "How did you know that?" Well, there are techniques of how to do it. That was all unclassified but it was hush-hush.
When the Russians finally decided to build bigger and bigger vehicles, the U2's were beginning to collect pictures and the intelligence community thought it had better go and ask some people who knew something about ballistic missiles what they thought they saw here. Beyond that point it is classified, but yes, I and a number of others, including my friend Bud Wheelon who became the CEO of Hughes in due course, were in the intelligence community. He was an official part of that community for years and recently won its highest intelligence award for that particular work. He and I had different relations over the years in that kind of business. I was one that was going on all the time while I was doing my fifty hours a week on something else.
Nebeker:
So the way this worked was that just from time to time you were asked to help on a particular intelligence project.
Rechtin:
Yes. We were put on advisory boards and asked to review programs and come up with conclusions as to whether such and such looked reasonable or practical. It was the technical side of intelligence; it wasn't the spy side or the covert side. That's a completely different part of intelligence, most people don't understand. Well they now can, because people are acknowledging that there is such a thing as technical intelligence, there are such things as spy satellites, they do take pictures and they do listen and do all the things that we expect them to do. The details are very highly classified. What's classified is how well did they perform. It used to be that you couldn't talk about them at all. After a while that became nonsensical, and they wanted absolute silence on the subject because they felt that once people started to ask questions they would ask further questions and still further questions, and it would tend to unravel. With some programs that may still be classified, as to the sources and methods, they are sensitive to the protection of people and of major assets. Every once in awhile there is a leak or somebody goes out and releases a bunch of stuff.
Another part of my career was essentially dealing with the defense department itself, which started with the ballistic missiles at JPL. Then I went to ARPA (the Advance Research Projects Agency) as its director; we were trying to make sure that we weren't technically surprised. Then I became Telecommunications Assistant Defense Secretary.
Ph.D. Work: "Angels" and Missiles
Nebeker:
Before we get into that part of your career, I wonder if I could ask you briefly about your Ph.D. work. You said the first project you did you had scooped by Bell Labs. What was that?
Rechtin:
That was called "angels," of all things, and this was a phenomenon that had been observed and worked on radars that were trying to find aircraft, particularly search radars. The search radars every once in a while would see things drifting across the scope. Observers couldn't understand what they were, but they were clear enough, and if you weren't careful you could confuse them with aircraft, so they called them angels. We were trying to figure out what that was. My idea was that maybe they were atmospheric discontinuities because they traveled relatively slowly. I felt that here in Los Angeles, where we had inversion layers, you might very well see disturbances rolling along the top of the inversion layer, under it or someplace, at least it seemed reasonable. So I got a hold of a small radar and modified it so that instead of sweeping around horizontally it swept a vertical arc. This was to see whether or not I saw angels because on that vertical sweep it should show as a horizontal line. It seemed reasonable; the numbers said that it could be depending on how much turbulence there was at the top of an inversion layer. Bell Labs decided that they would do it a different way. They built a very tall tower and put radar at the base of it. Then they pointed it up out in the middle of the desert and put a spotlight beside the radar so they could see, and it turned out that it was flying insects and small birds. I don't know what they spent on it, a hell of a lot of more than I spent on it as a graduate student. Anyway, they solved the angles problem. The rule of a Ph.D. is if it isn't original work and it isn't first you don't get your degree, so I had to start all over again.
Nebeker:
This was under Pickering?
Rechtin:
Yes, this was under Pickering.
Nebeker:
This was in electrical engineering?
Rechtin:
This was in electrical engineering; I have always been in EE. Cal Tech at one time tried to make me a physicist. I said, "I am not a physicist, I am an EE. I am an engineer and I want to do things that are useful." That is an easy characteristic of an engineer. A scientist wants to understand and discover new things, which I enjoy doing too, but my primary motivation is that of engineering. Although they said, "Look, a physics degree is of the highest possible prestige" and all of the rest of that, and a lot of physicists have told me that since, that's now changing a bit. The nuclear physicists are now off in the bushes. The electrical engineers and the software people and so forth are in the forefront. I wish they would call us rocket engineers. What the hell? No scientist built that rocket.
Nebeker:
Good point.
Rechtin:
It used to be a nuclear physicist. Now it's a rocket scientist. The media keeps doing that to us. Every success is a scientific success, and every failure is an engineering failure. So, I had to start all over again.
Well, then there was another problem that Pickering came across in the work at JPL and that was out at the Naval Test Range. They had various systems which were trying to track cruise missiles going over the surface of the sea. Their range was well beyond the line of sight. How were they going to track it? They had various systems and one was called radist, which essentially was a set of radio stations which would listen to the propagation and wavelengths that would come from the horizon. The question was at what precision you could measure such things. There is essentially a problem in the propagation of electromagnetic waves over a conducting surface, and there were theories for this, but no one knew whether they could believe them or with what precision.
So, I figured that what I could do is model the whole thing. Instead of using those frequencies I would instead use microwave frequencies over water by having pairs of antennas, two down at the surface and two up higher, to see whether or not the radio waves indeed behaved as we thought. The theory covered the whole range and you could test the whole theory in this microwave range. You could show that indeed it was happening and to that degree over real water. Well, my first attempt using water was at Point Magoo in the tidal flats. Unfortunately, it took more time to make measurements, and the water would come up and around my ankles. It was probably one of the strangest and dumbest experiments I ever did in my own life because here I was handling very high voltage standing in seawater; only the young would consider even doing this. That didn't work, so then I figured maybe I could find some large pond someplace. There was a great fishing pond which had an asphalt base and was about three feet deep and it was used by fly fisherman to practice. But they weren't about to hear about this.
Nebeker:
Where was this?
Rechtin:
That was in Lacabta. They weren't about to hear this because I had to make it more conducting. I had to bring the parameters up and I had to pour a lot of salt in it. They weren't about to have the salt in their fishing pond, even though there was no fishing — just a casting pond, they used to call it. I managed then, probably with Pickering's help, to get the city college to allow me to use the great mirror pond and —
Nebeker:
I know that well.
Rechtin:
I am not sure they really understood what was going to happen. I hoped that their pipes hadn't corroded. The amount of salt was literally in barrels, true three foot barrels which were about two feet in diameter, barrels of this stuff to get the conductivity. I had a pump and I threw salt into this barrel and it overflowed into their fine mirror pond. You couldn't see any difference but I am sure the pipes knew the difference. At any rate I then performed the experiment and indeed it did track. I got the necessary information as to what the coefficients were and with what accuracy you could probably do it and showed what all that stuff was. Then some people heard about it in the state of Washington and said, "How would you like to come up and give a presentation?" I thought that was a great idea because we were just married and that gave us a honeymoon with a few more days off work. So I presented my thesis material with my bride in the audience. I pointed her out and everybody cheered. I went to an IEEE conference and gave a paper on my honeymoon; they thought that was appropriate for engineers.
Nebeker:
And that was...
Rechtin:
That was in 1951. My Ph.D. was in 1950, and we were married in 1951.
Nebeker:
I see.
Rechtin:
So I got my cum laude Ph.D. I need to tell one more story about Pickering because it welded me to Pickering as no other thing would. I was in my third year as a graduate student and I had just flunked Smythe absolutely cold — I told you the story. Well, at the same time I was supposed to be doing research and I had worked so hard trying to get past this course. I had done absolutely nothing on my research and we were supposed to send in reports and they were supposed to be graded by my thesis advisor. So I wrote a half page saying I worked like the devil on Smythe, I flunked it cold and did absolutely nothing. My grade sheet came out and he gave me an A. If ever a guy needed it at that time, he was an understanding professor. He would say, "I've got the same confidence in you as I always have." So in some ways it has been almost like a father-son relationship.
Nebeker:
Did you work closely with him on your thesis projects?
Rechtin:
Well to the extent that counselors always do, I would say yes. He helped find that first little radar for trying the angels experiment. It was through him that I heard that because I was also at JPL and he heard about this instrumentation problem. One way or another he has been around when opportunities have shown up.
Job Prospects after WWII
Nebeker:
And when you completed your degree, were you already working full time at JPL?
Rechtin:
Yes.
Nebeker:
Did you consider going elsewhere?
Rechtin:
I thought that it would be a short-term stop on the way into industry, and it almost was. I think the Korean War started in 1953, if I recall, roughly around that time. It was just before then that it was clear that government interest in JPL was waning again. Pickering came into my office and said, "Eb, I think it might be advisable if you thought about finding work someplace else." That wasn't because he didn't like what I was doing but because he was trying to alert us.
Nebeker:
So JPL was an Army facility at the time?
Rechtin:
An Army facility paid for by the Army. Then the Korean War hit. That was another time my career might have changed; it is a lesson to people now; they ought to think about it. I was still in graduate school and various interviewers came around to talk to us. One of them was from GE, and his name was Boing. We were taking electronics and systems and so forth at the time. He said, "Well, I need to be honest with you. World War II generated so many people that understand electronics and radar and so forth during the war that there really is no market for Ph.D.s in EE. You'd probably do better 'to raise apples in Oregon'." That became my by-word, of course. Myself and the others who were at Cal Tech who were getting degrees at that stage was that nobody else was around who knew what we knew when the need showed up. So in all fairness to all the other fine people around, we literally floated on the top as the tides came in. We were the only ones who had seriously looked into the theoretical evolutions during World War II, understood what some of them meant, modified them and were ready to go. We were again in the same position when the space business showed up; we had the techniques soon on how to do it. In aerospace we were again in the same position. When Star Wars showed up, and they wanted to at least think about the surveillance aspects of it, I knew that. So in each case I have been extraordinarily lucky, and I caught every wave that has come by and have ridden it.
Jam-Resistant Codes & Radaring Venus
Nebeker:
How did you decide to go into communications EE?
Rechtin:
At that time it was straight EE, and it included both the power option and I don't know what the other one was called. It was not yet called electronics. Those were the two options in the electrical engineering field.
Nebeker:
Were there other options in EE?
Rechtin:
Not that I recall. In the late 1940s, the electrical power option was bigger and stronger, led by Professor Sorenson and a number of others who had done work on the power grade in the west; an extraordinary achievement. And this business of electronics and vacuum tubes and so forth was just coming along. Principle applications had been in communications and so you tended to think of it that way. They were just beginning to get into control systems and feedback loops — Bodie's book was influential there. We learned from Bodie and from Gardener and Barnes on the mathematical side. They showed with equations you could have analogs of one system played out in another. In particular you could make electrical analogs in mechanical systems and understand what they were, express them in terms of impedance and so forth, feedback loops, gains and all the rest of this which the people at Bell Labs put together. We turned around and put that into guided missiles, jamming and anti-jamming and coding systems.
We learned about the use of noise as a signal in a conference held at either MIT or Lincoln, where it was brought up. One of our people, Frank Lehan picked it up when he was there. He came back and I heard about him and I said, "Hey, I want to work on that." That was what led to the idea of going back into Wiener's book and trying to find that out. That led me into developing some of the earliest ideas on machine-built codes and how to do that. I was very proud of myself because I built these little machines which are now called key generators. Completely in the clear, unclassified, knowing nothing about what anyone else was doing. We hired Saul Galan from then Harvard. He was a young Ph.D. and he looked at what I had done and he said, "You have done really remarkably well, but it is all in the first page of Set Theory." Given that, I said, "There's the guy to run with it," so he did and he became world famous in codes, code cracking and all kinds of things.
So we got some remarkable jam-resistant codes and in the process had all kinds of codes that sort of fell on the floor. Then we converted the civilian space business. We picked up all the codes almost literally, the ones we had thrown on the floor because they were so easily cracked, that had all the rest of the properties that we wanted, and stuck that in. The consequence of that was that JPL was the first to clearly get radar contact with the planet Venus. It's a different and long story; we were in a race essentially with Lincoln and we were the ones that got it. And it's only because we had a code which was so long that there was no ambiguity whatsoever when the signal came in.
Nebeker:
This is bouncing the signal off?
Rechtin:
This is bouncing the signal off the planet Venus. It was bounced off many of the planets but Venus was the first. The significance of that for the space program was that we now knew how far away Venus and the sun and all the rest of the planets were expressed in radar time. How long does it take a radar signal to go? With that we could go anywhere with tremendous precision. As it turned out, the astronomers were off as to where the planet Venus was, and consequently all solar distances, called astronomical units, were way off. They were off by 10,000 miles from what it actually was.
Nebeker:
What percentage is that?
Rechtin:
It was about a part in 104 and what we needed was a part in 108. We then calibrated the solar system, and it was one of the most important and least advertised projects.
Nebeker:
This was at JPL?
Rechtin:
At JPL. Lincoln on the other hand was doing virtually the same identical experiment but they had a short-range code because they thought they knew where the planet was. Their code was ambiguous over several thousand miles, I would give it; essentially alias. They looked where Venus was supposed to be according to the astronomers, which was 10,000 miles off, and they got a negligible signal which by elaborate mathematics proved that they had reached it. The Soviets naturally very shortly afterward announced they had also reached it at that fictitious distance. Well when we turned ours on, there could be no ambiguity; you couldn't match the codes. The code length is longer by far than the distance to Venus and back because of the code generators that you built. And so when it came in for us, you didn't need mathematics to show it was there. It just came booming up like a good radar signal should. So we told Lincoln right away that we contacted Venus and it is over here with absolutely no ambiguity. I don't know if they ever went back to the earlier data and checked, but they would have found it two years before us had they not had ambiguous measurements. If they could have only scanned further they could have gotten a distance.
Nebeker:
Has the Soviet data been looked into?
Rechtin:
We just sort of brushed it over, "Yeah sure, guys! That's just fine." They probably got the same little glitch or whatever it was.
Noise-Like Signals and Codorac
Nebeker:
How did your positions change at JPL in those years?
Rechtin:
It was sort of a steady progression. Originally I was in guidance and control and helped work on radio guidance for the Corporal. Then I heard about the use of noise as a coded signal. Noise-like signals are better. We called it pseudo-noise, and I don't know whether they still call it that. But it was a directly reproducible noise made by a machine — digital bits, precursor equation. I heard you could use noise as a signal, and that was so fascinating to me that I said I wanted to go over and work with that group if that was all right with everybody. Everybody said sure. Probably the Corporal was going its merry way. Our next vehicle was going to build a Sergeant with inertial guidance and so on. A lot of men worked there and Frank Lehan was then the boss. He stayed there for a few years and then left and I took over that group I was telling you about. We proceeded to handle all these other different kinds of noise problems because at the time the jammers were usually noise jammers. That was statistically a very good thing to do against most signals, jam them with noise. We had to figure out how to get a signal that would penetrate through noise, and it turned out that it was a noise-like signal. You wanted it reproducible and digital and in code streams. Sending code streams through anybody's noise was a generally good idea.
Nebeker:
Was this classified research?
Rechtin:
At the time it was all classified, and we built all of that into a system called the Codorac, a code ranging in communications and command or something like that; it was all classified. We put out quarterly reports, and from these we then put together the whole history of Codorac and annotated every one of those quarters, saying whether some of these ideas turned out to be right or wrong or whatever in retrospect. It was a marvelous annotated history of Codorac, which spanned five years' worth of theoretical and experimental work and building. That later became what NASA called the unified S-Man system. The SGLS Space Ground Link Subsystem, which was its exact equivalent, deliberately made the same for the Air Force, is now the basis of all Air Force telemetry and ranging and lots of things. It is also the foundation of the GPS signaling system, so it was also the system used for Apollo when they went to the moon. Wiener's theory was the best and there wasn't any better that you were going to do. In that sense we were lucky, because a lot of people experimentally trying to find a better control system and receiving system and that just ended all that.
Nebeker:
When did this information become declassified?
Rechtin:
Probably in the early 1970s. It could have even been in the late 1970s when President Carter said that you ought to declassify everything before a certain period in certain areas.
Nebeker:
Has it since been more widely adopted?
Rechtin:
Well, lots of people use the phase locked loop. I have often been called the father of the phase locked loop for that reason, because it was used in all directions. It went into TV systems. It went into all mobile systems because that was what it was designed for. Actually, I not only took Wiener and did a three line proof, but I also applied Lagrangian multipliers to put on the constraints of the real world of position, velocity, and acceleration so that you would have the best possible tracking system in the physical world against heavy noise. It was a precise mathematical optimization.
Nebeker:
It sounds like, of course, a fundamentally very far-reaching result. Did it bother you at the time that this was classified?
National Defense as a Cause
Rechtin:
No, because one of my driving points in my whole career has been the defense of my country. It is a cause for me. I suppose part of it came because I was in a so-called good war, World War II, where the bad guys were pretty clear. The more information got around, the worse they were. Then with the Korean War and then in the Vietnam War, there was all the more reason for me to go to Washington to head ARPA. I felt that with all that was going on the government sure as hell needed help; whether the war was right, wrong or indifferent, it needed technical help. So I had volunteered into that as I volunteered into the Navy before. I took a cut in pay, didn't get any raises for six years, and wound up being flat broke in the standard history of government officials. I went to Hewlett-Packard because it was a company with no government contracts, also because it was headed by David Packard, who had been a deputy secretary of defense when I was there as an assistant secretary. I wrote him and said, "Look, I need to leave the defense department, but with all that I call the morality rules around, it isn't at all clear that I could go into the business that I know the most about." He said, "Well, you might consider coming to Hewlett-Packard. We don't have very many contracts."
So I went there for four years as their chief engineer. It is a great company, profitable, moral, all the things that anybody in free enterprise can and should look to as a definition of a first-rate free enterprise in industry. It has a good set of goals and objectives and so forth, a very well constructed, a consistent profit maker, consistent benefit to the world with the kinds of things that it builds. But I missed the cause because it wasn't clear what cause I was working for there. Better products for a better world were fine, but my cause had been national defense. So I asked Packard if I could continue to consult for national defense and the intelligence community. He said, "Yes that is important for you to do and it is important for Hewlett-Packard to have someone who knows something about what's going on in that arena. If there are products that are necessary for it, we can build them and present them to the company in due course." So I continued my association with the government. I had been there about four years when the presidency of Aerospace opened up, because the then-president was retiring and they were looking for somebody. The kinds of problems that they had required somebody that knew about government.
Nebeker:
Who was your predecessor?
Rechtin:
Nebeker:
I am seeing him on Saturday.
Rechtin:
Good. He had run Aerospace up until that time. It had a set of problems that needed somebody who could talk governmentese, who could talk industry, who could talk non-profit, who could talk intelligence, and who had the clearances. By the time you make the mesh fine enough on that screen not many people are going to come out the other end. I also had some credentials, the various honors that you are supposed to have and the National Academy of Engineering and all the other top certain things. I took a cut in pay; that's the history of my life. I then went to Aerospace, and I was there for ten years. Then I had my cause back again.
Nebeker:
At Aerospace.
The Concept of "Architecting"
Rechtin:
When I went to the University of Southern California my cause was also straightforward in national defense. I saw all these very large complex systems being built. I watched some of them succeed magnificently and some of them fail disastrously. I tried to figure out if there was some way we could tell ahead of time, or if there was something in one situation which wasn't in the other. I must know at least 100 different systems of all kinds and you could rapidly cross off all the common errors: it must have been politics, must have been crummy management, must have been waste mismanagement, and all of the rest of the things that you can hear about which were all in my mind too small to account for what we were seeing. I finally concluded that what we electrical engineers were missing were the architects that the civil engineers had. Somehow in our transition from civil to mechanical to electrical to communications and to software, we had dropped off the idea of architects. The system engineers thought that they were doing that or maybe they wish they were, it wasn't quite clear. Occasionally you can find a system engineer with a talent and interest and brilliance to do it.
In my particular case, in retrospect I was the chief architect of deep space communications and navigation; I was it. In studying what I had done, going back in time, I could see indeed what I was doing because my dad had taught me something about architecture and how it is done. Because of the circumstances or whatever it was, I was its chief architect. That one worked, and then when they were putting the Apollo together, they needed somebody to look at the mission profile, whether there was going to be a circle around the moon, to rendezvous, all that. They brought together a team under Joseph Shea, also a member of the National Academy. It was called the Architecture Group, of all things; this was the early 1960s.
We studied this whole thing as an architectural problem. What kinds of propulsion you are going to have, what kind of missions you can do, and all kinds of things. We calculated that we would loose thirty astronauts before we got one back. That was the best we knew how to do in the early 1960s. It was a good calculation. We took all the best launching characteristics, all the best of this, all the best of that and added all of them up in that fashion and multiplied all this together to get the figure of thirty astronauts. Obviously, it didn't take. There were no losses of astronauts in orbit; there was a loss of three on the fire in the pad, which would have not occurred in space. You look at all these things and put together what you are trying to do, what your purpose was. Kennedy had stated it very clearly. It was natural to have a set of architects sort of sorted out for the brass who had to make the decisions.
One of my reasons for proposing to the rest of the group about how to do the rendezvous was that the problems we had ahead of us were electronic problems, not propulsion problems. Either of the other two would have generated propulsion problems about which we did not know as much. If we want to walk in the direction where we know how to sign, that's a better direction. That's how I meant Bob Siemens, who is another important person in my life, and we as a group did that. In contrast to that was the shuttle program and there was no architect. It was a kluge; it's purpose was not clear. There were a lot of stated purposes, none of which turned out. There were a lot of promises made, including that the shuttle would return two billion dollars a year to the U.S. Treasury as soon as it became operational after four flights, which never happened. They said they were going to fly fifty flights a year and take over all the launches for the whole space program, which didn't make sense either.
An architect should have been there. The architect's job is to reasonably show feasibility. The client makes the value judgments, but unless an objective architect, objective as seen by all the participants, can say what is feasible and then show how to get there, you really haven't completed the first step. The shuttle got in trouble because it promised what it could not deliver. What it did deliver was astoundingly good; it is the finest launch vehicle that we have in terms of its reliability. It was an astonishing engineering feat, but it didn't have any architecture in the back of it. The space station is exactly the same problem now, and I hope to hell we never build it, because no one has stated its purpose. The first thing that an architect must know working with the client is the project's purpose, and we don't know that yet.
Nebeker:
Can I ask you about this concept of systems architecting? I have heard that Bell Labs sometime around World War II and thereafter had this concept of system engineering.
Rechtin:
Yes. It goes back to the early 1900s. As a matter of fact, Alexander Graham Bell, much more so than let's say Thomas Edison, clearly had in his mind what turned out to be a full network. If you look at what happened, I have often used the Bell System as a primary example of good system architecting. The difficulty we had was that there was no formal program, no formal graduate degree no formal set of principles that we could talk to. The metaphor or analogy to an architect wasn't there, and the Bell System didn't call it architecture. They called it a network. They were driven by purpose: the best telephone system in the world. They built a system which progressively evolved over time in very well understood, very well researched, very well calculated steps. They were politically sound; they were to provide the communications to a nation. They were financially sound; you knew whom you could bill, and who was going to pay for it. It was also clear who was supposed to provide it: a controlled monopoly.
In answering those three key questions, they built a network which expanded continuously while the telephone rates went down continuously. It was clear in the mid-1950s that you could extend out in a number of other directions with similar systems architecting. The idea of systems engineering occurred when people began to see systems as something somehow different from just a group of receivers, transmitters and whatever. It's getting clearer now. I like to talk about systems in saying that systems produce something which you cannot produce by just a set of elements by themselves. That means that there are system functions which are not the sum of other things, and that the key then must be the relationships between the parts. That sounds very straightforward now but it has taken us a long time to get to something that fundamental about systems. Otherwise people are talking about systems as any grand collection of things.
Nebeker:
I remember Bill Baker telling me that. I don't know this story well, but at some point Bell Labs was recognizing that what you are dealing with is a large system, and that engineers have to be trained in taking in the big picture.
Rechtin:
That came about easily in World War II and maybe before, because Boda could not have written his book on feedback systems unless they had a system concept, because it was not just an idea of "Put it in the front it comes out the other end." That was a new idea of feedback and the difference between positive and negative feedback. They had already run into problems of stability, because when they put in the wrong kind of feedback, the damn thing oscillated and blew up. So they had clearly seen that when you connected all these parts together, you could produce something. You could get rid of a lot of the problems on the forward link, particularly on the linearities, if you had a feedback loop. That led to control theory, which tended to branch away from the Bell System. It also led to switching theory, which is the core of the Bell System. That became obvious when they found out that there weren't enough telephone operators in the world to pick up all the number of connections they were going to have to make.
In terms of where all of this came from, I made no claims at all that either systems or architecture were my inventions. When you put them together you then define the function of building architectures as architecting. I don't know if I would even call it that word but I was one of the first to use it consistently. I use "architecting" so that people focus on the process that an architect does. If I just use "architecture" it means too many different things, so I invented another word. Some people want to call it "architecturing" but that could be more complicated than we want. I wanted to focus on system architecting as a process. That also avoids another process as to who does it, because there is nothing that says a system engineer can't do architecting, and nothing says a system architect can't do systems engineering. If you are missing that function, then you have a problem. The Bell System didn't confront the problem too seriously because their whole basic architecture from the beginning was essentially the same.
Nebeker:
They weren't building so many new systems.
Rechtin:
They weren't trying to do something drastically different. The first time that we have seen something drastically different was probably the Internet, where its architecture is nowhere near what looks like a Bell System's standard architecture. It's an overlay on it, sure, but its architecture is drastically different. Packet switching is very different than circuit switching. That took a lot of studying, puzzling and some architecting. The information superhighway is a first-order social system, and that is not understood now. Some seem to think now that we have optical fibers, all is home free and we are going to have an information superhighway and everybody is going to have access to everything out to the gigabyte level. Well, no. The kinds of data you are trying to send are so different and they are going to be conflicting in so many complicated ways. There are going to be so many different participants in it, from the good guys to the bad guys. There is a marvelous article written in Scientific American called "The Wire Pirates."
Nebeker:
I think I have read that.
Rechtin:
That one is going to be a classic because it puts down in straightforward, quasi-scientific reasoning what kinds of problems you were going to get. Thank goodness it came along when it did, because the hype on the information superhighway was getting out of control. Now that the media has picked up on this idea, it can be abused. They are finding all kinds of ways that it is being abused and badly.
Systems Architecting and Control Theory
Nebeker:
I am just trying to look for antecedents and related developments to the concept of systems architecting. How does control theory relate?
Rechtin:
Control theory comes in when you start to talk about real time systems where you want a response right away and where generally speaking there isn't time for human beings to get into that. There are always going to be human beings involved; the question is, where are they and how do they enter the system? Increasingly, what we are seeing is that the human being enters through the software. I'll illustrate this with the automobile. I have great fun with this because I tell people that you are sitting down in your car and on your right is this big crank. You think this big crank over here is shifting gears because it makes you feel as though you are doing something profound. You are talking to a microprocessor, and you just simply like this big thing. You don't need one of those; you could have a push button in your hand which would do it more easily, but you got this big thing.
Then you've got this thing on your right foot, and as a matter of fact, your right foot has to do different things. That is a little questionable. Do you really want to do that? When you push down you think you are making the car go faster, so you push down on it. Here you are talking about micro processing. You put your foot on the brake and think you are mechanically slowing the car, and can feel it. You push harder and harder. You aren't doing a damn thing mechanically; you are talking to a microprocessor. You turn the wheel and you say, "Now I am turning the wheels." Only to a limited degree are you turning those wheels, because there is power steering in the back of it. The power steering is smart enough to know high speeds. They are not going to let you turn that wheel and make that occur that way. You cannot do a sixty-mile-an-hour right-hand turn. You suddenly find out that the car is telling you no.
Then you are going to find in a couple of years that the minute you sit down in the car, it reconfigures itself, because it weighs you as you sit down in your seat. It says, "This is the husband of the family. He likes such-and-such a feel to this car." Next time that's the wife or maybe it's the eighteen year old and it's a different car. Now they are getting to the point where they are saying, "Well, people don't like these cars to up-shift and downshift, particularly in the western states, where we climb hills. You get to forty miles an hour and the damn thing wants to shift. Then you slow up a little bit and then it wants to downshift and is shifting all the time. That doesn't make any sense. What you ought to do is change the gear ratios as a function of the slope. Now I can measure the slope, so I'll measure the slope and the gear ratio will be changed, and that's already in some cars. You have a physical feel of things, which is good because the body likes to get information from physical feedback, but in practice you are talking to a software system.
Now there are some obvious goofs. The TV remote handset is a goof. These little Sony recorders are a goof. They weren't thought through in terms of the human being. If there are buttons they should be very large. They should be on a flat surface and labeled "go" and "no-go," or "back up" or something; none of these infinitesimal little buttons. You aren't thinking of the interface with a human being and have made it far too complicated. You ought to make it so that the things that you do the most are the simplest to do, not that everything is equally difficult. Why do you have to push four buttons to get something to happen? A microprocessor can handle that. It needs to talk your language: "I want it on, I want it off, I want it reversed." You need to talk to a little chip which will take care of all this for the most part. So real-time systems and fast response systems are what get you into a lot of the complexities of software systems. If the human being can enter in and make a move, it's different. Then you have a series of things with human beings as the main thing.
People think that the shuttle, for example, is flown by astronauts and pilots and so forth, but they aren't flying that machine at all. It's flown by computer. Whether you can take that astronaut out altogether is a big social argument, not a technical argument. Because in practice when the shuttle comes into the atmosphere, there is no way that a human pilot could conceivably act to come in safely. It is impossible. The aerodynamic conditions are changing so fast that only a fully computerized system can handle it. It is a real-time system, not a steering wheel, a pedal and so forth.
Nebeker:
So if we were trying to map out these different intellectual areas that deal with our systems, control theory is the control without humans in the loops. Is that it?
Rechtin:
Generally speaking, the human makes a few decisions like slow or stop, the gross decisions. But the action speed is as close to real-time instantaneous as is appropriate for the problem. You don't want to stop a train with a screech; you want to do that a little more softly, so fuzzy systems or feedback systems can handle that.
Process of Systems Architecting & Apollo
Nebeker:
Are there other courses these days in systems engineering or architecting that take a broader view?
Rechtin:
They are just beginning to come along. The systems engineering aspect of it has been thoroughly codified, or in other words, put into practice by the defense establishment. They have complete definitions of what systems engineering is and what you are supposed to do with it; there are volumes and volumes describing the methods for systems engineering. However, almost all of them start with the paradigm that says, "Given a set of requirements, what do you do?" Occasionally, you'll see one mostly on communication theorists and artificial intelligence people which starts a little bit differently. Instead of asking for the requirements, it'll say, "What are the purposes?" "What performance are you looking for?" It's a little softer than formal requirements. More often those people will say, "Well, given a set of alternates, I need to choose one." Even the early communications and noise theory people said, "Given a set of alternate receivers, how do I choose among these alternate receivers?" Obvious questions are: where does the alternate come from, who thought those up, why is it that set? Obviously if you had a finite set of alternates, roughly 7+ or -2's usually, you can do an analysis, define a "solution." If the solution is to pick one among seven we have very powerful techniques for doing that. They are very good, very precise. Some say, "That is the best among the set" for the following set of requirements, question or issues. And there has been a lot of work done on just how you do that.
Everybody thinks that you are choosing among alternates. I think even Shannon's paper implies that you are looking in on alternate schemes and ways of doing things. The question is, where did the alternate come from, where did that set of alternates come from? Maybe there was never a set. Maybe there was really only one kind of solution and we had to evolve to it. Where does it come from? Well, the architecture metaphor is pretty good in that respect. I'll play the architect and you'll be the client. You have an interest in something being done, and you presumably have resources enough, at least you hope you have the resources enough, and you have a rough idea as to what you want to happen, but they aren't all fixed in concrete by any means.
This is as good a metaphor as any. You want a new house, you want it in Palo Verdes, you want five bedrooms, and you have $100,000. Sorry, but you have to come back and discuss a number of things on the value side. Do you really need a view? How important is it, because that will roughly increase the cost by such and such. Do you really need five bedrooms, or do you want four and a general-purpose room that you could have a guest in if you wished? Start going back and forth, where you the client are making these kinds of value judgments. Can you afford what you want? The architect is coming back with knowing what the consequences of some of those are, until finally you begin to get an idea of "Well, just what are we going to do? We are still going to be in Palos Verdes." Or do you want to be somewhere else? Do you want to be down in Torrence, which is a fine community in itself? Do we really want half of an acre? Well, with the cost per acre, probably not.
Pretty soon, between the two of us, we have come up with a model of what we would like. With conventional architecting, I would build a little model for you with balsa wood, and bits and pieces of things and say it might look something like that. You start to look at it and I start to look at it. You see if you like it. I look to see if it can be built. After a while, we sort of come to an agreement as to where the match between our desires is. The feasibility is going to be important, a reasonable match, we hope. That gives us a conceptual model and allows us to talk to the builder, for example. Now that paradigm is pretty good, and it may turn out that when we talk to the builder, he can give us a couple of alternates, one of which is that he can start essentially from scratch with you. On the other hand he has built a few houses that are not too dissimilar. If you would like to see them, you can look at them and say what you like and don't like about these. Those we might be able to evolve in the architecture or we might have to start from scratch. If the ground problem is to start from such and such, I may have to start from scratch, and that could be different. If you don't like such things that I propose, your best move is to find another architect, and if you don't like what the builder is proposing, go and find another builder. You and I as client-architect just don't go out and say, "Bid for the low price."
Most systems engineering is based upon government systems which state that there are requirements. You will bid in the following way and you will do such and such; it is a very well established process. You can argue if it is right or not, but it's a very well established, very well-codified, Dewey-decimal fashion up to whatever degree of refinement we want. Almost all of the systems engineers, at least in the defense sector, or national sector, space and so forth, are doing that. That's the operational definition of what a system engineer does. You don't need very many architects, obviously; a handful is all you need for any major system. You want a chief architect, and you want sub-architects who know certain fields very well, who know what's going to be critical. On the Apollo team I was the communications expert. We told them, "Don't worry about communications. We will give you real-time, color television in both directions and it won't influence the rest of your design. Antennas can be small, the power level is going to be reasonable and you can do this as you want." That idea was technically feasible from the beginning. We said so, and the astronauts and others opposed it. They said that they didn't want it. The astronauts said, "We are test pilots. We don't want Big Brother looking over our shoulder. We'll take videos and present them to the world when we come back." They didn't want that, and it's why the first pictures were black and white and not color. There wasn't time to get color in because of the delay in that decision process. It was criticized as a public relations stunt.
In effect, it turned out to be the definition of success of Apollo. All of us can remember. I had been in this business a long time at the time; it was almost twenty years, and I still had butterflies when I saw that foot go down. There is nothing to beat it. When we saw the astronaut hopping across the surface, there was no way that we were simulating that. We were there, it was color TV, it was immediately understood, it was for real, and we had done it. It didn't start out as that being the definition because Kennedy had not specified that level of detail. He said to get them there and get them back. I wonder how many people would have thought to show it to us on color television in real-time.
Nebeker:
That's an amazing achievement.
Rechtin:
All that can be traced back to good architecting in the first place. Some of the failures in the system can be similarly tracked back.
Nebeker:
Your career sort of moved you up in this management of systems and taught you, I assume, the importance of that kind of planning.
Rechtin:
My conclusion was that with good architecting you had a chance of astounding success. With no architecting or poor architecting you stand a great chance of a disastrous failure. It was that clear. In between you can say, "Well, if there was or wasn't an architect it may or may not have made some difference one way or the other." But a larger and larger number of people are beginning to recognize that unless you do that front end in a much different way than our standard regulations say, unless you get that process started properly, you are in trouble. For example, one of the things architecting says you need to do is to keep that architecting function going throughout the whole implementation process, certainly at least through certification. That is not common. We too often give out research contracts for — People try to come up with what the scheme is and then hold a big bidding contest, the liar's contest where some prime contractor unrelated to the first group gets it and starts over. You hope that the original ideas were strong enough that they don't get completely crushed in the process, and very often the architecture will start to drift. Programs illustrate that phenomenon too.
Defending ARPA
Nebeker:
Your work at JPL we briefly covered. Can you briefly describe your years at ARPA? What big projects were you working on there?
Rechtin:
ARPA was at the time a fully operational ongoing agency. My job as I saw it at the time, since we were in the middle of the Vietnam War, was to define ARPA. As a matter of fact, if I have done anything in the various managerial roles that I've had, I have gone back and tried to define what the operation is, particularly for ARPA. ARPA was then, surprisingly, under some attack by people who said, "Why are we spending all this money doing this research and development and looking ten years down the future? We've got a war on. Why does ARPA do some of the things that the services really should be doing?" An argument at the time was that the services were not competent to do them. I threw the argument out. To anybody that wanted to propound it, I said it was ridiculous; I worked with and around the services long enough to know they could do the same thing. So we had to define what ARPA was.
I wasn't told, but just as I had been recruited and was driving across the country, the then Deputy or Undersecretary of Defense, Cyrus Vance, was thinking of abolishing ARPA altogether. That was a grand start. I was told by one of the very wise people in the Pentagon — a surprising number of them I think are still there — "Look. One day you are going to be walking this hall, this is the third floor of the Pentagon, it's the most important floor of the Pentagon, and down the hall is the Secretary of Defense's Office, and you are not at all that far away in ARPA. You are going to be walking down the hall and the Secretary of Defense is going to come down in your direction. He is kind of a friendly guy and he is going to say, 'What do you do around here?'" He said, "You got thirty seconds."
That never happened, but they gave me a close equivalent before Congress. I was only asked to go up before the Congress once. I had previously avoided doing so and had my boss talk as my sponsor anytime I could. I always felt that your customers were better salesmen than you are. I was asked essentially the same question, because some people wanted to abolish our founded committee. One of them was from upstate New York, and it was pretty clear how the questions were going. He asked, "Tell me, Dr. Rechtin." They always put the "Doctor" in front and never show whether it's a compliment or not. It also says, "We don't have a 'doctor'." Anyway, "Dr. Rechtin, why should ARPA exist?"
I told them why ARPA should exist: ARPA needs to exist because, first of all, we have to avoid technological surprise. More importantly, ARPA is the only place where you could start things without having a requirement, where you just think there probably is someplace where this can be applied. The odds of that can be pretty high because the defense department is a complete civilization. It is hard to think of anything engineers are doing that won't be useful someplace, and so we have the chance of getting to a point where there are indeed options and where requirements have a chance to be written. We aren't always sure just where there is going to lead, but it is a marvelous invention to have this. I said that it is a controlled amount and that's what they would always have. I was giving them the rationale. It is a controlled amount; it is in a sense a protection against the necessary rigidity of a full acquisition program where you must have everything in place with ninety-five percent confidence before you start to spend these billions. You want no surprises down that track, so how are you going to do any research? Research says that I don't know the answers, and if I don't know the answers I can't be in an acquisition program, and if the only thing you have is acquisition programs, that's a chicken and egg problem and you can never get the cycle started.
ARPA lets us start something which then gets plenty of review later on. Projects are set up and it lets us explore. We are obviously doing things in the interest of defense and we can think about them. There was a famous case where we were asked by the people and Congress to show the relevance of every one of the research projects in the Department of Defense. I was then in ARPA and handled this one. All these projects came in with all their rationales. Obviously when Congress asked you to supply these, you were supposed to supply some. We looked them over and finally concluded that there were four hundred whose relevance was a bit questionable, so we sent them up to Dave Packard, who was then Deputy Secretary. Well, Dave Packard comes from Hewlett-Packard where they're more than familiar on how things can be used and what ideas there are. Every time they see some interesting thing that might be possible, they go off and try to do something with it. So he looked over this list and he said essentially, "I know what to do with 396 of them." He had four of them left. Well, of course congressional relations were in an uproar: "What do you mean four? Come on now, of thousands you've only got four of them? Give us a set of sacrificial lambs."
During my time before Congress, which preceded that particular event, ARPA had a project which was a mechanical horse. It was far before its time; we have only got around now to where you can think about mechanical systems that can look like bugs or something like that. It certainly wasn't the technique at the time and the project was getting extraordinarily expensive. The jokes were already around town as to how ARPA works and its horse has to have a long cable out the back. They say its logistics were terrible, they compared all this with the standard horse, and so forth. This project was ongoing when I got there. I looked this and said, "This one I am not even going to attempt to defend, kill it." Scientific people were horrified; I didn't have an understanding of the value of studying mechanical horses. That was right. I felt there was a war on and I was an engineer, for crying out loud. Anyway, I got up before Congress and the questioning began. This guy from upstate New York was clearly homing in on this project. He was enjoying what he thought was going to be the pressure on this guy.
Nebeker:
What congressmen or senator was this?
Reorganizing ARPA
Rechtin:
I don't remember. I can look it up, I suppose. But it must have been in 1968. At any rate, I said, "Oh yes, Mr. Congressman, I understand what you are talking about. It was probably the mechanical horse program. I think it was Cornell." I said, "I canceled that one the week I began directing ARPA." A few more questions, and at the end of the session, a guy turns to his fellow congressman and says, "Give that guy anything he wants." That was the end of the discussion about killing ARPA. My immediate predecessors plus one had had the idea that ARPA was really a funding agency for universities, more like a NSF, but with the defense side. That was not the paradigm I was interested anyway. I said, "We are in the middle of a war, and we are supposed to be doing things to help. We ought to be out there doing things which can help."
The relevance argument is kind of brutal for defense because it's making the defense acquisition people very conservative and exacerbating the problem with universities. Universities at the time, particularly engineering schools, were caught in the middle of a bad bind. The students were objecting because they had read the defense department explanations of these projects, showing the relevance to defense. It did not agree with the professor's explanation of why he was doing what he was doing. He may have been looking for more information or had civilian applications probably in mind, so his explanation to the university was always peaceful and quiet. Nobody would get killed by this thing. The defense department said something else, some bright investigative reporter compared these two, and all hell broke loose.
They said that the professors were lying, that they were warmongers, and certainly demanding that all the university research projects showed relevance to a defense department at war was not popular during the Vietnam War. It came to this bunch of other problems, and since I had come up with a description of what ARPA was and ran it that way, I said that our criteria for success had to be clearly defined too. I said, "Look. We are a very advanced business, so roughly half of the time we should probably fail. Otherwise we are being so conservative that the services should indeed do it." The services could always start if you had a set of requirements. They could do the research and do it well and probably use the same people. ARPA did not have the researchers themselves. The services can do a lot of these things, if it is clear as to what it's for.
We were going to be exploring new things, sharing computer time and what became Arpanet and Internet. We were going to be doing things which hadn't been done at all before. It wasn't quite clear at that moment just what the requirements were, but that was okay for ARPA. But half of the time we had to figure that we might fail. Now that doesn't mean we were not successful, because if we knew why we failed I counted it as a success; that was perfectly all right. Desirably the end result should have been something which we could transfer to the services to implement, and that was a success. So if we did transfer it was a success, and if we didn't transfer it we needed to know why. Well, we also needed to work closely with the services so they knew what we were up to, so that those with the needs out there could say, "Well, you are doing this thing. If you don't mind we would like to use it for something else. Do you mind?" The answer was "Hell, no. Take it and leave." So I ran ARPA on rather strict grounds. There were probably a bunch of gravy trains that had been building and I took care of all those.
Nebeker:
Essentially there was quite a change there in the funding patterns.
Rechtin:
I would say so. I maintained the past tradition, a very good one, of having ARPA do sole source contracts. We didn't go out and compete research ideas. I said that didn't make any sense. You went to the person who had invented the idea or come up with the idea or thought they knew what to do. There was plenty of time later on to figure out who was going to build it and make it and do all the rest of the stuff. Clearly, the later change of saying ARPA had to compete everything in the research area, to me made no sense at all to me. Fortunately, I didn't have the problem. I could do it the way it had been done and get brilliant work done by people who conceived it and whom we felt had a reasonable chance. At the other end of the spectrum, however, I also said that the researcher had to show me some results. I said, "I want reports, but I want them in the ARPA criteria as well. Half the time you may not get anything. That's okay. Just tell us what you did and why you did it and what you thought happened. You say it might take you four years. Well, if it's going to be four years, it's okay too. Tell us more or less where you expect to be along that route because if it isn't going to get anywhere, and clearly it isn't going to get anywhere after a year, there is no point in saying we are going to have a four year contract. So you have to at least tell me something, preferably transferable, not necessarily to the services but to somebody else — a good idea, a good equation, a good theory that can be used by somebody else, a device perhaps."
I counted all those and I said, "That's what we are looking for. I do need reports. I don't mean usual progress reports saying you spent so much money, and used so many man-hours. That's not what I am talking about; that's a standard number report. I want to know what progress you have made down your original proposed track, and if you want to change the track that's okay too. Tell us and we'll see whether something happens down that route. That's fine by us, but report." That rapidly weeded out a lot of programs where the professor or whomever the researcher was just sort of using the money for whatever purpose they felt like, like a block grant or something. It wiped all that out, and a lot of people didn't like that either. It made them call me "the Prussian" for different reasons, because they had an engineer in there in the middle of a war, and a nasty war, who needed to produce things of value. I also transferred out altogether the ABM work which ARPA had been doing, very important work, no doubt about it. I transferred all of it over to the Army because I saw ARPA and the Army playing whip saw over that. If I was a congressman I would tell ARPA, "Why are you doing this, when the Army is doing something." I would tell the Army, "Why are you doing this, when ARPA is doing something?" and fund neither of you until you agree as to what you jointly would do, which would cost... So I just transferred the whole shebang to the Army and got ARPA clear of that.
Well, that turned out to be at least a third of the total budget and the people in ARPA were horrified: "You have get our budget back. Our budget will be cut." Grandstanding. I said, "It won't be cut. They'll give us the same amount of money next year as they did this year and we'll be able to do new and different things. That program will go over to Army and the Army will now combine it with theirs, pick the best of both and go on. Both things happened: we got the same amount of money again. We proposed some new things, primarily in information theory and communications and all the rest of that, which went like gangbusters.
Nebeker:
We don't have time for any detailed accounting of this, but what were the largest areas in your time as Director?
Rechtin:
There were a whole set of them. That was one of the characteristics of ARPA at the time because the biggest one would have been the ABM project, the so-called Defender Project. That had occupied a lot of my predecessor's time but it was getting to be a point of very high expense. They were going to have to build big radars and lots of things. It was going to chew up money like mad. So that was one of them, and another one was in the information sciences, which led to all kinds of things. ARPA was the principal funder of the Xerox Parc, the Palo Alto Research Center, and its ideas, which later led to the Macintoshes and everything else, the combination of studying the way people think. There was one that I was particularly proud of. It was run mostly out of ARPA by Steve Lukasik. Ivan Southerland had been the director before that, and now he is world famous for the graphics and all the morphing that you see now. They trace back to this kind of work. There were still our geniuses who come to ARPA. There was the behavioral sciences game, which has naturally taken a beating because of the Vietnam War.
The Vietnam War
Nebeker:
Was networking started at the time?
Rechtin:
Oh yes, it had been started. The Illiac IV had been started. It was ahead of its time because they couldn't build the necessary time of parallel computers and have them all work. It got us into trouble at the University of Illinois when the students came in and broke in and wanted to smash everything. It wasn't a quiet time. Then there was the AGILE project. AGILE was trying to help in the Vietnam War on what I would call the more social side. We worked with the Thai and South Vietnamese, doing studies of what was going on at the human and social behavioral level in that war. What we came up with was often not very popular. We tended to agree with the group that said, "You have to understand the social and cultural environment within which you work if you are going to be very effective in these kinds of wars." The standard approach, the conventional approach, was that it was the Army's job in South Vietnam to essentially throw a shield around that country at its geographical boundaries. If we could do that and train the South Vietnamese army to do the same thing, by their definition that war was won, and indeed it was. They had at about 1972 essentially a country at peace. All the railroads were working, the farmers were back in the fields, and there was a shield. The Vietcong had destroyed itself in the famous Tet offensive because they had all surfaced. Their survival depended on us not knowing who they were, but they all surfaced and that ended most of that problem. By 1972, and this will sound strange to a lot of people, we had won that definition of the Vietnam War.
However, then as a country we made a terrible mistake, saying, "Good. Now we can walk away from it." Congress enforced it by saying that we would give no more aid to South Vietnam at all, economic or military. You might as well have invited the North Vietnamese to rearm and attack, which was precisely what happened. The irony was that the people in the northern part of South Vietnam did what they had done once before; they started to walk south. Everything was so congested that there was no way any army could have operated because they went south in millions. The North Vietnamese army, and their own records show it, to their astonishment could walk all the way down to Saigon without any effective opposition. All they had to do was bring out their arms and more people fled ahead of them and just walked that way. They came in with modern tanks, modern aircraft. They had rearmed to the next level up, essentially, and we refused to do anything. We refused even to go back and give North Vietnam another lesson. We refused to do that. We refused to send spare parts to the South Vietnamese. We essentially walked away from our ally.
By that time, fortunately, because I don't know what I would have done inside the Department of Defense, I'd have to leave. I was broke in 1973 and I was at Hewlett-Packard when Saigon fell. It taught me another cruel lesson that South Vietnam fell. I heard not one word of it at Hewlett-Packard from anybody, but to me it was the first order of catastrophe. It was a prelude to the United States' influence dropping enormously in the world. We had walked away from an ally. "Even the Russians don't do that," I said. In the old superpower days, the general rule was that we would not allow our client states to fall. That was the rule. We should have all understood it sooner, in the case of Korea. The Russians and the Chinese would not allow the North Vietnamese to fail. When we did, they came in, ten million into South Vietnam. When the South Vietnamese failed we were all the way down to Pusan, and we would not allow that to happen. So we drove back in the other direction, but the other side made sure that we couldn't go the other way either, so we essentially maintained stalemates. Well, if you walk away from either one, and announce it as we did before the Korean War had started out, then what happened was that we lost South Vietnam.
That to me was a terrible thing, and it was illustrated best by the Israelis who came to see me. Because they had come to see me as they often did. They would look for friends in the defense department; they would invite you to go out and have coffee or something. They asked me before all this happened in South Vietnam, "Can we count on the United States or not? We are just going around asking people to see what they think, what the feeling is." And I said, "Of course, you can count on us. We are a big country and we stand by our commitments." Well, then South Vietnam failed and they came around again and they said, "We'll ask you the same question," and I hesitated. "We understand and that's why we decided we are going on our own. We are going to do what we think is necessary for our survival." That's why that Mideast war continued the way it did, because the Israelis could not count on the United States and that was terrible. I think probably more wars started and more things happened because they said that the United States walked away. Other countries by occasion have been driven out. The French were driven out of Algeria and Vietnam, but they didn't walk away to leave their allies to take the brunt of it. And we were supposed to be a superpower.
Anyway, that is a long sad story; another lesson learned I guess. So when you asked what I did in ARPA, those are the kinds of things that were sort of day-to-day. As to different kinds of projects, there were all kinds in different areas. The AGILE project was trying to understand the Vietnamese people side of the equation. We had research units in South Vietnam, with South Vietnamese people in it. When we walked away from them, I felt personally had. I am still wanting for a decent story of that war to come out. In my judgment it hasn't yet; the conventional wisdom is that we made a terrible mistake and we were driven out, that the army had to leave in helicopters from the embassy. All you need to do is read the Time history; I am surprised that historians haven't stood up and said, "We'd better say it the way it was by the events that were occurring." We should put to one side the New York Times orders to its reporters in South Vietnam: "You will show that the Tet offensive was a serious defeat for the United States." The message was intercepted by the South Vietnamese and brought to us; it reconfirmed it. The New York Times wanted to make the Vietnamese War a terrible failure.
Hewlett-Packard
Nebeker:
That was certainly a case of a media event that changed so many opinions, that Tet offensive. You told me one reason you weren't particularly happy in your years at Hewlett-Packard. What projects did you work on there?
Rechtin:
I was originally brought in by Dave Packard with a job to do. He felt that maybe Hewlett-Packard should get into the communications business. I was Assistant Secretary of Defense for Telecommunications. He knew me and what I had done. He knew I had been quite successful there in setting up a number of things, including the naval architecture group for communications, which unfortunately the Navy canceled a few years later when the submariner took charge. Submariners don't talk, and so they said we didn't need any communications. So they tore the architecture group apart. That just proves that anything you can do quickly in Washington can be undone equally quickly. Hewlett-Packard brought me in to see if they could get into the communications business because they were building some instrumentation for communication networks and they thought maybe that we should do this. I knew communications and its world pretty well, and so I had to learn about Hewlett Packard. I was there about three months and studied the way they operated and why they operated and what their objectives were and how they treated things.
They didn't know anything about systems. They had a systems division but it was largely putting together Hewlett-Packard instruments, parts, pieces and so forth for a stated set of requirements by something like the Swedish Air Force. It was making no money because that division had to buy its parts from the others and allow the others to take the profits. You were not going to make any money at the system's level. I understood that. I also understood how they created their devices by having engineers working at the bench coming up with these instruments. It was essentially a replication of the famous garage that Hewlett and Packard had started in, literally 5,000 times over and worked like a charm. It was an absolutely great company, and when I left nobody could understood why anybody in his right mind would leave Hewlett-Packard.
Well, at the end of three months I said to Packard, "You don't want to be in the communications business; you really don't. It's not a match to this company. The communications business is controlled by the people who control the networks, because they specify what they need. They have virtually complete control over anything that is manufactured anyplace because they control the standards. Western Electric builds almost all of it; some things they farm out from time to time, mostly things they feel they would rather not do or a specialty of someplace else, but that's small compared to what Western Electric itself does. Western Electric is tied to Bell Telephone Labs in a very strong sound way; it is going very well. They are going to see changes, and when they see changes they will unilaterally change standards in whatever. That would make obsolete whole sets of equipment. You will be the tail on the dog, you will get whipsawed." The Bell System was relatively benign in that respect. The aircraft industry is horrendous in terms of the poor tails on the dog — notorious. I said, "You are completely at their mercy if they decide to go digital all of a sudden," which they did, or if they decided they were going to be switching in a different way, which they did. You really don't want to be in that business.
Here is something off the record. I was also asked to go and talk to what was then called the Satellite Business Systems Organization, which is a Comsat-Prudential-IBM combine. It was going to build communications systems where major divisions and companies would have antennas on the roofs and they could all talk to each other in private communications systems. Dave asked me to go, because one of the partners, I forget which one, sort of wanted out. I went to talk to them and came back and said, "You don't want to be in that at all. It's going to lose a couple hundred million a year at least for quite some time." It's because they had missed the central idea of why companies decentralize into separate divisions; they had missed it completely. In my modern terminologies, it wasn't architected. They saw this technological possibility, but when a company decentralizes, why do they do it? They do it so that you can have relatively autonomous units, and the units become even more autonomous with time. They are connected to the central with very limited communications. Only the essential stuff goes back and forth, and almost never to each other. So there is no market for wide band communications of that type.
Furthermore, you are competing with AT&T, who can loan you a transponder, and then you are competing with a copper wire underground. It's not going to play; it really isn't. This was when everybody was saying was a grand new scheme. Packard said, okay and did not make an offer at all. As it turned out, SBS lost $400 million a year. They are in the soup for well over $1.5 billion, as I recall, and it isn't in operation. I tried to think of a way it could be used, old ARPA-style, because I felt that there is a way if they really wanted to do it, but there was only one customer who might have a need for that where the cost didn't count as much, and that was the Department of Defense. If you wanted to connect all the major industries supporting defense and all the major defense installations to something of that sort, that might make sense because it would be relatively survivable. It was also certainly an alternate to the Bell System Net, which was what you preferred to use. But it would be a straightforward system and everybody having his own antenna meant he was completely independent of the environs. That for defense purposes would make some sense, but nobody picked up on it. I don't know where it is now. I think they pawned it off on MCI or somebody.
It was something which, not understanding architecting as well as I do now, I could have picked up, because the purpose wasn't there. There is an old rule that if a system doesn't have a purpose it won't live. Architects start with the purpose. Equipment makers and inventors and innovators start with some product that they think is going to be a world-beater and find out what the purpose is last. Then you put it on the table and ask if anybody wants it, and you may be surprised at who wants it. It can have very little to do with what you thought, becoming out wildly successful in an area you never thought of. Hewlett-Packard's hand-held calculator was an example of that. Hewlett-Packard had done a market study of demand for hand-held calculators? We went to A.D. Little and all the best survey people. It was one of Bill Hewlett's ideas. They all said, "No, there is not much of a market for it." It was this little thing that would add and subtract and maybe do a couple of little programs. Why would anyone want that, when they have the Freedens and the Marchants and so forth, and they can get the numbers easily enough? Why would they want this? Particularly at $545 apiece, nobody is going to want them.
Well, at Hewlett-Packard they had what was called the next bench syndrome. The next bench syndrome was that if you had an idea, you make it on your bench and you turn to me at the next bench, and ask me what I think. If I think it is a good idea, we'll proceed. Hewlett said, "I think it is a good idea. Does anyone else think that it's a good idea?" Of course, when the boss thinks it is a good idea the other people will say it's a good idea. They said, "We'll do something modest. We'll make maybe a few thousand of them this year and we'll see what happens." As you see, what happened was that in the second month they were making 10,000 a month and it just took off. It wasn't for engineers, which was what Hewlett-Packard and the next bench guy thought. These were all kinds of stuff. You were able to carry this thing, and it sold at $545, no questions asked. Then competitors came in. Texas Instruments came in and the price dropped steadily. But now if you want one of the original H-P handhelds it would cost you several thousand dollars. They are historic. Of course, now the cost of the chip is only about ten dollars.
HP and Smart Systems
Rechtin:
This brings me to another important development in our whole world, which are smart systems. We brushed on it before about software, but what's also happened is that systems have become very smart. They are doing the drudgework which human beings used to do in the automobile, knowing exactly when to shift and so forth, and they picked up on all of that. But in much more important areas they have become smarter systems. Hewlett-Packard recognized that in the mid-1970s and began to put smarts into their instruments. No longer did you get data by watching dials, and meters and writing it down the way all graduate students have been told to write the numbers, painfully writing them out and finally putting them in a report and making mistakes as you go along. Finally, you put out a report as to what this particular measurement was. Well, Hewlett-Packard figured out that you could put a little part of the hand-held calculator inside one of those things. They saw that soon all you would have to do is punch a few buttons on this machine saying what experimental routine you wanted it to do, connecting this instrument to something and saying what you want it to do. It would not only make the measurements, but also would display them and print out your final report. Well, that cost Hewlett-Packard another 10% on the cost of the device and they could sell it for two to three times that total sale, because the value to the customer is huge.
Nebeker:
And Hewlett-Packard was ahead of other instrument manufacturers?
Rechtin:
They were a decade ahead. Their standard was to be three years ahead of everybody and that still is their standard. If you look at their product line, half of it wasn't in existence three years ago. They made smart instruments, smart voltmeters. You no longer hear about a voltmeter. It's a multimeter, and furthermore it's a smart one. It self-calibrates and refuses to take signals that are too extreme; it's self-protecting. You can program it in a variety of ways. You can get it to print out charts that are pie shaped, bar shaped, curve shaped, anything you choose. Compared to the cost in man-hour dollars for the old-time Ph.D. researcher trying to do something plus the technicians to help, plus the typist, plus all this and that, the advantage was so huge and this was so fast. You got the paradigm that by adding a small cost by way of smart systems; it was ten dollars a chip no matter what's on it. You can enormously increase the value of the system to the customer and the customer is willing to pay for it. Another Packard rule was, "We will make money from the first device we sell, not after 4,000 of them are grabbed in market share"; none of this under-pricing.
Nebeker:
You can get away with that if you are the leader.
Rechtin:
You are damn right that you can, and they figured it out. It is a marvelous construct for corporation. They also refused to go on the stock market to get funds. They grew only out of their own profits, so they were completely independent of the financial markets. So they weathered all these ups and downs in grand style and are now at ten billion dollars a year or something like that. When I was there they were at about one and a half billion. They only had twenty divisions, and I think they now have 100 divisions. To convince Packard on the SBS, I said, "Do you know how much communications you have among your present twenty-odd divisions? Anything they have to do other than make telephone calls, which they can do cheaply, or any data they have to send they can get down on a single teletype line after hours. That's all they need. Now you tell me where the market is for you to put up big antennas on your roof.
Aerospace and Government Contracting
Nebeker:
We have to move fast here, unfortunately. It's all very interesting. What can you say about your ten years at Aerospace, looking back on that?
Rechtin:
Well, as you can see, when I got into management, the trick was to do architecting of management. You may get a somewhat different perspective from Ivan Getting if you talk to him about it. It was a company which at that time was about seventeen years old. It had weathered a lot of storms and had been embroiled in controversy. It was set up because industry objected to TRW being not only the systems integrator and engineer but also having the option to build some stuff. They felt that wasn't right, so they wanted change. Congress mandated a non-profit corporation, which turned out to be Aerospace. Ironically, the ballistic missile business never did move to Aerospace, because at the time there was only one ballistic missile of any consequence that was being really developed, and that was the MX. That was being done by TRW, and it was deliberately grandfathered. Maybe people assumed there were going to be further ballistic missiles. I don't know. What happened instead was that the space program was beginning to crank up and they needed launch vehicles. So Aerospace took ballistic missiles as a good starting point, but not as ballistic missiles. There was some ballistic missile work done, there were some projects looking at re-entry phenomena and so forth, but relatively smaller. Ivan Getting was very involved with the long history of ballistic missiles, which he felt was of very high national importance. Seventeen years later, by the time I got there, it was a real debate as to why Aerospace should be in the ballistic missile business at all. I think Ivan expected me to defend that because he said that was a national problem, an international resource.
I came to a different conclusion. I felt that what had happened instead was that we were now in the satellite mission business. By that I meant weather, communications, surveillance, navigation, and that the end product of the Air Force and ourselves was then satellites in orbit performing these missions and performing them very well. That was the core of our business, not ballistic missiles. Ballistic missiles were causing us a pain because there was a MBP big argument about them. As I said, there was only the old MX, and worse yet nobody knows where to put it. That was its architectural mistake; they did not solve that problem in the beginning. The MX is a marvelous missile, very well designed and able to do all the things anybody ever said and probably some more, but nobody knows where to put it. Call it a social problem, if you will, but the architecture hadn't been complete. It's in the book and described in just that fashion. I have had no objections from anybody about what I have said. I felt that was chewing up manpower and generating controversy, and I felt we had to leave that.
We also had another group of serious problems: the relationship of Aerospace at FCRC, the Federal Contract Research Center, and the Air Force. The Board was of two minds, but Ivan was a single mind. He felt that they should get out of the FCRC business and become a private contractor and compete for essentially the same business if they wanted to. They were just going to tell the Air Force that they were sick and tired of limitations on people and dollars and everything else which gets imposed every once in awhile. The relationship was clearly sour, in bad shape. An engineering portion of that was that the Aerospace people, as had their previous TRW counterparts, believed just like they did and still do at JPL, that they as engineers knew better what was needed than what the customer felt. Instead of having the customer do technical direction of the builders and the contractors, they thought that they should be doing it. They wanted to do technical direction. The Air Force didn't want them to do technical direction and there were consequently large volumes written as to the exact role of Aerospace and who was allowed to call which conferences, and whatever. This was technically about who was in charge.
We also had all kinds of affirmative action problems. That's a completely different history, one of which I am very proud and we don't have time for here. I made affirmative action work. It worked brilliantly. The company benefited enormously, the people benefited, the Air Force benefited. Everybody benefited in that, I tell you. There were no preferences given. They were a whole batch of problems, all of which led to Ivan saying in a meeting with the Air Force generals, "Look. Aerospace is a national resource. We are a national resource. We shouldn't be bothered by these other problems. Why don't you go and tell the affirmative action people to go away, that we shouldn't be put under those sets of restrictions." He wanted to tell the Air Force that we didn't want to be in FCRC either. The Air Force by that time was getting a little nervous because we had a lot of non-defense business. For the Department of Energy we had roughly 20% diversified, which the Air Force had asked for only five years before in the 1973 recession. We were to try to keep ourselves together by doing outside work, but now all of a sudden they didn't want it. I was told by the then Assistant Secretary of the Air Force for R&D, "You will be out of all of that business by December or you will have no contract at all. And I'll hold up our present contract until then." The sign date was October. Welcome to Aerospace.
Fortunately, I had been asked about this job in the previous May, and they had sent me a very well constructed paper on what their problems were. They looked pretty intractable on the surface, and I could see why they would want out. They would rather go private and compete than to stay in this kind of environment. I looked at it and came from JPL knowing strategies from a lot of other non-profits and what they did and how valuable they were. I looked at the affirmative action and all these problems ahead of time, at almost three months in advance, to study what they had told me. When I went in, the first thing I did was see the general. I was selected on Saturday, and on Monday morning my first task was to go over and talk to the general who was my counterpart and to find out what his impressions were. I told him we were going to be an affirmative action company, we are going to be the first to call Aerospace an affirmative action company, not an equal opportunity company, but an affirmative action company. I recommended to the board after they had elected me that we stay as an FCRC. They should not attempt to leave, and that was in the government's interest and in the company's interest. I said they were in a much better position than they thought.
I said, "Yes, it is annoying and we'll work on those problems," and I worked every one of them, all the restrictions. I got rid of the manpower ceiling for all practical purposes. I got out of the building restriction which said we weren't allowed to build the building without a special approval by a House subcommittee. I got rid of all those things. We previously weren't allowed to grow, but I managed to expand the technical staff by a factor of three, and nobody objected that we would grow. I managed to expand our facilities by 50%, and nobody had thought that we had grown. I managed to solve the affirmative action problem quietly by a bunch of things. But most important I had to redefine the role of Aerospace. I said that we are architect engineers. I gave them my first speech when we assembled. I said, "We are architect engineers. Our tradition does not go back seventeen years or even twenty-seven years; it goes back 4,000 years. We are architect engineers. We are the objective people who are working with the client, in this case the Air Force, to make the value judgments, to show and help assure that these things are feasible and well done. That's our job. We do not technically direct, we do not issue contractual statements, we do not have contracts coming out here." We didn't at the time. But, I said, "The reason for that is what our role is. We are the architect engineers for the whole national security space program for all practical purposes — that's us."
I said, "Look. The builders which we had about seventeen years after the start of this whole business are very good. They have extraordinary confidence; they can do system integration. We do it in a particular way, there are thirteen things that the Air Force thinks are crucial for Aerospace, and they have listed these." We had to be ultra secure. We had to have clearances into every place, we had to do this, and we had to do that, these distinguished Aerospace. If we weren't here, they would have had to invent us. There was nobody that could compete with us against that total set. They could pick at any several sets, but they could not compete with the total unless they had a structure just like ours. That's a major strength and it was set up with that kind of purpose. I know that nobody calls us architect engineers but that's our role. It solves the technical direction problem, and it solves the problem of who makes what kinds of judgments. It solves all kinds of problems. In the back of my mind, I said, "If I ever have to refer to that volume of how the Air Force operates, I have failed. I don't want to see it. I want it to go away. I want a relationship which is so automatically close and proper as a rationale that it will work.
Within eighteen months I had accomplished what I knew I had to. First, I got elected by the company, not the board. That was not a conspicuous election, but if you are the president, you will know it only because people are doing what you ask them to do. If you lead and show what the purposes are, they will happen. They will recognize that you are the president, but it takes some time. After eighteen months I was Dr. Rechtin, President and CEO of the Aerospace Corporation, hands down, no debate, no comment. After seven years of that —I was there ten — people came to me and said, "We don't understand how we got here. We are a marvelous company; we are on the top of the world. We got all these good things, affirmative action is now in, all the suits have gone away, and other companies are looking to us to find out how we do all these things." Our steal ratio is what I define of how many people we could steal from our competitors in the personnel market, engineers and so forth, compared to how many they can steal from us. The steal ratio was never less than five to one in our favor. My job at Aerospace was essentially as their chief executive, as the chief strategist, as the chief architect, which I felt only a CEO or president could do. Otherwise lots of other people could have done some parts someone would have had to do anyway.
I wrote, started, did several things. Every three months, after our board meetings, I got together with all managers of level two and above, which is essentially hundreds of managers and told them what had happened and had an open Q&A. All they had to do was write a question down on a piece of paper and pass it forward. I said, "I don't care what the question is. I am not going to look at it as to who might have asked it, because you could be asking for somebody else. If it was something that was worrying you, ask anything you want." It was perfectly open, and I answered everything that I could. If it was classified, I said, "That is going to get into the classified area, but I can tell you in rough terms." I answered every question. There was never a question I couldn't answer for some mysterious reason. I wrote standard pieces roughly every six weeks on one of our major areas or something, including affirmative action. I think I wrote ten of those over the ten years, including one that I was particularly proud of, called "Re-affirmative action." When the Republicans were in last time and attempted to knock it down, I reaffirmed our position as a company with affirmative action.
I also wrote one on, "What is the Single Most Important Thing That Aerospace Does?" We certify readiness for launch. If that were the only thing we had, I could justify everything else we do. It's not that we do general systems engineering; that's not enough. You have to have a function which is crucial. When there is a launch vehicle in the pad, particularly some of the larger surveillance ones, you have on the order of one to two billion dollars sitting there on that pad, and we decide whether or not we think it's ready for launch. The Air Force asks me, the chief, "Are we ready?" We are collectively ready, and did that once a month roughly for ten years at two billion a shot. Now, the company has to be very good at doing a lot of things, in order to do that. I said, "That's what's important, and that isn't even in our charter. Nowhere does it say that we are supposed to certify readiness for launch." But it says what all the meetings are about, what all the decisions are about, what all the records are, it says why we have engineers doing research on space, everything; it says, "Are we ready?" So that is a focal crucial point. We are not just a company around in order to be sort of a general support, or technical arm of the Air Force. There is a crunch time, the buck stops. So at Aerospace that was the kind of job that took my time.
Nebeker:
Well, it's very informative.
Rechtin:
That was Aerospace. I went to USC because I concluded, having looked at it in enough detail over certainly the last five years at Aerospace, that we were missing the architecting. This was even at Aerospace because the Air Force chose not to have Aerospace actually do the architecting and working with the customer in that way. Things tended to come down to us and to the Space Division as tasks to do, and so the fraction of architecting that was actually done at the Aerospace division level was in my mind too small. Too many things had been ordered by ARPA. ARPA had sent money down for a low altitude communication system, much like many of the ones you are hearing proposed today. I got nervous about it and I said, "I don't think that's going to play properly; there are too many different operational problems. They are misconstruing distance with difficulty. The synchronous is far better for doing almost everything they are talking about." There was only one exception, the slight delay in voice communication. Most communications is not voice, but data and surveillance stuff and so on. It didn't seem quite right, so I asked Fred Bond to do a run and find out what the implications were, costs and benefits and so forth for this low altitude satellite system.
The first numbers that popped right out said that each individual satellite is only roughly between one and two percent efficient in terms of how much time they actually spend doing something useful, instead of relaying or doing nothing in the middle of the ocean or somewhere else. "One to two percent," I said, "That's a horrendously bad number. One to two percent is not going to make a system play at all." The synchronous communication satellite was pretty close to a hundred percent. It had fixed beams and knew where all the customers were. Everybody knew where it was. There was no relaying involved; it was the only relay in a sense and it didn't have to relay to anybody else. You didn't have to have elaborate calculations as to where all the other satellites are to figure out which way to get from point A to point B, through which satellites at which time. With exposure time to a customer at only ten minutes at best, you can see that this whole thing was not going to make economic sense. So I sent the word back to Aerospace, which chose not to work on it. Nobody had ever refused to work for money, or for ARPA, which is a gem anytime you get any one of those, like freewheeling. All hell broke loose. The Air Force, when I sent it over to them, forwarded, "Rechtin has done it. He said he wasn't going to work on it." Word went up to the headquarters of the Air Force. "They are refusing to do something. Now we have to tell ARPA that Aerospace has refused. If they refuse, we're not real sure we want to do it."
They sent it over to ARPA and three weeks later they fired the guy who came up with that idea. He hadn't done his homework. The message sent back was perfectly straightforward, it said, "We don't think it ought to be done until you have worked out a few system numbers such as..." Then they ran out the system numbers and she blew, so I'll predict the same for you, as a matter of record, stating that Iridium will find exactly the same thing. There's this big hoorah about lower altitude satellites, but they are going to find them horrendously more complex and far more expensive. Their capacity is very low, their views that they can make of other satellites are very limited, and they are going to suddenly find themselves having the altitude of those satellites go up and up to at least 10,000 miles. They are going to run into radiation belts and then they are going to find out the competition from true synchronous satellites, which will cheerfully give you a transponder at the drop of a hat. You can do all this stuff much more easily and much simpler ways.
IRE and IEEE
Nebeker:
A final question: I gather that you joined the Institute of Radio Engineers.
Rechtin:
Yes, way back when I was a graduate student.
Nebeker:
Right. And you have been an IEEE member since the merger.
Rechtin:
Yes, forever.
Nebeker:
What have IRE and IEEE done for you? What they have meant for you?
Rechtin:
An enormous amount. Among other things, they have gave me the Alexander Graham Bell Award and they gave me the Fellow Award. In our business those are real marks of enormous accomplishment. I have been through the peer review system. You choose carefully, wisely and well. It helps define the community within which I work of 100,000 people, more or less.
Nebeker:
What of its conferences and publications?
Rechtin:
If I hadn't had the IEEE Spectrum article on systems architecting, we wouldn't be anywhere close to where we are. That got out to 100,000 people, and suddenly people said, "You know, that is pretty rational. We've got to start thinking about that." And that led them to buying my book, so that is a very recent contribution. In the earlier times, it was the forum by which we could talk to each other. It was in the information theory transactions that I first published discussion of how you showed that Wiener's solution was a three line proof in Laplace transforms. It showed how you could optimize for moving systems. I was naive at the time. I let my junior engineer have his name first rather than mine. As I said, that is really the only significant paper I ever published. That was also IEEE, and that was called. "An Optimum System for Operating a Wide Range of Signal Noise Ratios." It combined a number of different ideas that we'd had. The junior engineer had built all the stuff and had taken the necessary data and showed them what I said should have happened. It was a remarkable paper, still hard to find. So information theory section was a spawning ground for a lot of us, and control theory was another. I almost wrote a book in that period, and went to the conferences. I am not an IEEE participant in the sense of heading sections or whatever. I haven't felt that wasn't my role, also because I had more than enough management to do in whatever jobs I had.
Nebeker:
It served you well in what it was trying to do.
Rechtin:
No question about it. It is a premier society. I sympathize with the question of what you are going to do about software and computers, because they are increasingly important. I'd say that if I had advice to give, it's for the IEEE, almost no matter what it costs, to make sure that the software community stays with it. If the software community is the centerpiece of system design, and if system design now is increasingly electronic, we should keep that community together rather than watching it separate. It is an unfortunate fact of life at the moment that the systems engineers and the software engineers won't talk to each other. I gave a talk on that particular subject. There are a lot of things that ought to bring them together. But the systems engineers keep thinking of the software guys as a subsystem someplace that glues things together. The software people keep thinking that the hardware people are getting in the way since 80% of the cost of the systems isn't software. The two of them don't talk to each other, and I am trying to tell them both, "Hey guys, pay attention to each other, learn about each other." The software guys need to understand systems and they don't. The systems guys need to understand software and they don't but I think the next generation coming along will. My advice to IEEE is to work hard on the upcoming generation, the roughly fortyish types. Try to convince them that they are of one community and the most important single community in the systems business, including social systems.
Nebeker:
That is a significant suggestion. Thank you very much.
Rechtin:
Thank you for coming.
- People and organizations
- Corporations
- Engineers
- Government
- Inventors
- Research and development labs
- Universities
- Profession
- Business
- Business process re-engineering
- Contracts
- Customer relationship management
- Computer industry
- Defense industry
- Decision making
- Innovation management
- Project management
- Research and development management
- Engineering and society
- Military applications
- Cold War
- World War II
- Education
- Educational institutions
- Law & government
- Engineering education
- IEEE
- Awards & fellow activities
- Publications
- Automation
- Control methods
- Control systems
- Control theory
- Feedback
- Embedded systems
- Human-computer interaction
- Communications
- Satellite ground stations
- Environment
- Radar
- Radar theory
- Engineering fundamentals
- Systems engineering and theory
- Adaptive control
- Signals
- Phase locked loops
- Noise
- Signal to noise ratio
- Standardization
- Aerospace engineering
- Aerospace control
- Command and control systems
- Military aerospace equipment
- Satellites
- News
