• Hi Guest! Forum rules have been updated. All users please read here.

Westinghouse postwar radar reliability

overscan

Administrator
Staff member
Joined
Dec 27, 2005
Messages
11,517
Reaction score
917
Reliability Engineering, Airborne Radar and Typhon
Of course other programs that I worked on like the Aero 13 and the APQ-20, no. Aero 13 and well it was something 21.

Hochheiser:

Well I can cheat. I can look at what you wrote down - the Aero 21B.

McAfee:

Yes, it was the Aero 21B. Did a lot of analysis, looking at parts that were failing. We did shop follow to try to determine what were the trends on some of the items that they were building, especially ones that were having high failure rates and what we could do to determine what the cause was and how we could prevent that. Of course back at that point in time reliability engineering was "a new field". And the reason was that during World War II, they had a lot of equipment that was very unreliable and especially when they got into the electronics area that things failed pretty often. In fact, there was a statement that everything had a 5-hour mean time between failure and electronic equipment would always have a 5-hour mean time between failures. So what we were trying to do was to look at ways that we could improve that. We didn't do the design or the development. But we did analyze the activities and what was going on and tried to determine how one could reduce the probability of failure.

Hochheiser:

So then did the other groups in Westinghouse call you in because your group was reliability, the people who knew about this sort of thing?

McAfee:

Yes. We were a service organization which was on call to the other organizations. And not always liked, especially when you went in and told somebody that ‘gee I've looked at this circuit and you're overstressing all of your parts in that circuit.’ And it was sort of like, ‘what do you know about that?’ But that was fun. Nobody ever threw me out.

Hochheiser:

[Chuckling]

McAfee:

But I'm sure there were times when they would have liked to. But it was an interesting time. We moved on to other programs. I first started in the Air Arm Division where we had airborne radars and so forth. So everything was very, well, comparatively small at that point in time.

Hochheiser:

You're going to stick something in an airplane; you've got real size and weight issues.

McAfee:

Yes. You had to have - you've got the size, you've got the weight and you have the power constraint. Then I moved from that activity to the Electronics Division working on a program called Typhon. Typhon was a ship borne radar that had klystrons that were taller than I am. And they had a lot of them. So when we ran our first reliability analysis on that system, it was one of the things where you added up probabilities of failures to determine how long the system would work before it failed, the probability that that system would fail was greater than 1. So we extrapolated those results and said the system will fail 22 minutes before you get it together. Well that of course wasn't the situation but the idea was it was a very complicated system that used a lot of high-powered parts. Of course this led us to look at what could be done to get the failure rate down. So we came up with a concept called reliability with repair. They had strings of klystrons so if you had one fail you could move that one off line and put another one in before the system went down. That was not a total set of redundancy, but one of the first steps towards putting redundancy in the systems.
AWG 10, APQ 120
Hochheiser:

How long would you work on a particular project in reliability? It looks like you were working on Typhon for a fair number of years, is that correct?

McAfee:

Well I worked on the Typhon program about three years. And then it was obviously on its downswing. They were only going to build a couple of them. There were going to be sea tests and so forth on it but basically the engineering work was pretty much finished on it, except for the follow-ons that everyone did. So at that time I transferred back into Air Arm Division - I think it was still called Air Arm at that point in time - to work on the AWG 10 program.

Hochheiser:

What was the AWG 10?

McAfee:

The AWG 10 was airborne radar that was, I guess, the follow-on to the APQ 72 and the Aero 13B. It was a pulse Doppler missile control system where you were looking out the nose of the airplane, to detect targets in the distance, determine if you had friends or enemies out there and what to do.

Hochheiser:

Now was this for a particular aircraft model?

McAfee:

Yes. It was for the F4. The APQ 72 was for the F4 and the AWG 10 was the follow-on basically to that. So I went from this huge ship borne area where you could walk around and get lost - back to something where it was a comparatively small box that you put into the nose of an airplane. And basically that was a lot more fun to work on than the big systems.

Hochheiser:

Why was it more fun?

McAfee:

It was a bigger challenge. You had less space to do something. You had a lot of functions you needed to do. The big question was, how could you put more and more into a smaller and smaller place?

Hochheiser:

And I guess in some sense that must have made the reliability questions more complex.

McAfee:

It did because what did you do with the heat that you had to get away from the parts to keep them from failing? How could you miniaturize the parts to get them down to this point? And if you look at technology today versus what we had back then, what we were putting into something that was the size of your Coke bottle, today is about the size of a pinhead.

Hochheiser:

Right.

McAfee:

We've come a long way in that.

Hochheiser:

Do you recall any particular reliability problems that you needed to solve on the AWG 10?

McAfee:

Well the AWG 10 was one of those technology transfers where we were going from tubes to semiconductors. And so it was a question of how did you analyze that technology and so forth. The other problem that we had with the AWG 10, well not a problem but a challenge, was that they had a built-in test situation where they were trying to isolate failures in flight so you could do almost instantaneous repairs when the plane landed. The question was do you use a relay tree which everybody knew would work or did you use the new LED technology that was coming in. Well we had information on failure rates on the relay system; we didn't have any information on the LEDs. So we opted for the relays. We had 248 relays in that tree, almost but not quite, in series to do all this testing which later proved to not be anywhere near as reliable as the LED’s. It just proved that when new technology comes up, take a hard look at it and probably use it because it may be a whole lot better and more reliable than the old technology. But when we made the decision we didn't know. Of course one of my friends later told me he would never forgive me for making that decision [Chuckling] because of the problems with the relays being intermittent and so forth.

Hochheiser:

Was the next project the APQ 120?

McAfee:

Well the APQ 120 was really the big brother of the APQ 72. It was a different version of it which included far more functions, more modes of operations, and had a higher reliability requirement by a considerable amount. And in fact I think the APQ 72 had a mean time between failure of about 5 hours. We had a goal of something like 38 hours MTBF on the AWG 10 and 20 hours MTBF on the APQ 120. Well that seemed not too bad. People said ‘well gee, you know basically it's only an increase of 4 or 5 times the old requirements.’ But if you analyzed it there was something like 7 times as many parts, 6 times as many functions to do, 3 or 4 more modes of operation so it ended up with about a 23 to 1 increase in the reliability requirement. So that was pushing it just a little bit.

Hochheiser:

But were you able to reach those targets?

McAfee:

Eventually. It took a while. The initial analysis showed us meeting 13 hours MTBF, on the AWG 10 which was the minimum requirement with the goal being 38 hours. We started out about there and it grew over the period of time as we found new ways of doing things and found problems that existed in the system and eliminated those and simplified the system in some ways. Ultimately we met the 38 hour MTBF requirement, but it was a struggle. It was always interesting in how things could go. We would run various tests. One test would work, the next one wouldn't. And then you would say, ‘what happened?’ And sometimes trouble shooting those things was not easy. And since they never happened the same way twice, it made it even more interesting to come up with something that was coherent to try to eliminate some of those problems. So it was always a challenge. And the other thing was that whenever you solved a problem, there were always at least two more that cropped up. And sometimes the problem you thought you solved, the solution caused the new problems. It could be a double-edged sword. But a lot of fun.
 

pathology_doc

CLEARANCE: Top Secret
Joined
Jun 7, 2008
Messages
850
Reaction score
47
I know I'm bragging, but I can't resist showing off this thing I randomly scored from the Internet many moons ago.

20191006_182413.jpg
 

RanulfC

CLEARANCE: Top Secret
Joined
Mar 6, 2009
Messages
670
Reaction score
94
You're bragging but that book holds bad memories for me... Our Airborne radar instructor would threaten to throw it at someone when he and the Dutch senior technical chief would get into their daily argument during class :)
(I felt bad for the guy because he was only 'dumbing' it down be cause we really did NOT need to know yet exactly how the radar systems worked while the STC not only knew but refused to let him dumb it down. Fun, but scary times :) )

Randy
 
Top