Month: May 2011

J-2X Progress: Engine Assembly, Volume 5


The first car that I ever owned was a “goldenrod” 1974 Ford Pinto. My uncle Johnny was a car salesman for Buick at the time. He sold new, bright, and shiny machines in his showroom, but, of course, they took in trades of all shapes and sizes and conditions, many of which they would not dare put back on their own lot. My little Pinto was just such a vehicle. I bought it from the obscure and hidden back lot for $500 with absolutely, positively no guarantee that it would continue running until the end of the week. While it was only eight years old, back then (sad to say) autos simply didn’t last as long as they seem to today, particularly if driven hard in the weather of the northeast. So I spent months and months of afterschool hours and weekends replacing rusted panels and floorboards with broad swaths of fiberglass. Also, despite the fact that I was never a true gear-head, I was able to open up the hood and do some work on the engine. It was a straight four cylinders and as simple as could be. You could reach into the engine compartment and easily find and touch just about every greasy major component. 


Just a couple of years later, my mother bought a new Saab.  When I opened the hood of that sleek machine, I couldn’t find anything.  The engine was turned sideways, apparently, and the compartment was completely stuffed to the gills with overly clean, boxed-up things that I couldn’t identify, and lines zigging and zagging in all directions.  It was fuel-injected and front-wheel-drive and all kinds of other jet-engine craziness that my cozy little, oil-burning Pinto was not.  So I closed the hood of that pretty blue Saab and I decided that I’d never make it as a modern mechanic.

Why am I bringing this up?  Because some of the latest pictures from the assembly of J-2X Engine 10001 reminded me of my confusion in looking under the hood of my mother’s car.  Only much worse.  Yikes.


I’ll get to the progress we’ve made with the big pieces, but first I want to talk briefly about what looks like a chaotic explosion of confusing stuff all over the engine pictures. I will begin by telling you a secret:  There are two reasons that we test rocket engines. First, we test rocket engines so as to impress our friends, most of whom are geek engineers like ourselves or people otherwise excited by loud noises made by neato, exotic machines (i.e., lots of NASCAR fans). 

Second, we test rocket engines to gather data. Lots and lots of data. Many gigabytes of data. We measure pressures, temperatures, rotational speeds, flow rates, and dynamic vibrations both in terms of acceleration and in terms of strain. As part of the development program, we test in order to prove that what we thought was true when we created and analyzed the design is in fact true with the real hardware. And anywhere where we were mistaken, we need to know as quickly as possible so that we can recalculate our margins of safety and, if necessary, make adjustments to the design for the next development engine to be tested. Testing rocket engines is not cheap, and, of course, neither are the engines themselves, but we need to acquire this thorough, unassailable understanding of the engine long before we would ever imagine strapping a human life to something with such awesome power. 

This need for data explains much of the “bloom” of seemingly ten thousand little lines and wires snaking hither and yon all over the engine.  Some of these small lines carry pneumatic pressure for actuating valves or providing purges, but lots of them are related to the many, many measurements we’ll be taking during the upcoming hot-fire test series.  In fact, these early development engines will be far more heavily instrumented than any engine we would ever fly because, again, their whole purpose to generate useful data (well, that and to impress our friends). What is truly amazing to realize is the fact that every one of these lines has a specific shape and route; every one of these lines is designed, not randomly configured; and every one of these lines represents a documented step in the assembly process. 


Now to the big stuff.

The first big assembly news to share was the arrival of the regeneratively-cooled portion of the nozzle (usually called the “regen nozzle” around here). In the pictures above, on the left you can see the assembly technicians preparing to lift the regen nozzle out of its shipping container. On the right is a picture of some preparations being made to the nozzle before the rest of the engine is stacked on top. If you’ll remember, the rest of the engine was previously being assembled on a simulator of the nozzle. Interesting little side note: In order for the technician to get into the position you see in the picture on the right, she had to crawl under the elevated assembly platform and stand up inside the nozzle. In the picture below you can see the stack of the engine on the actual regen nozzle.


Now, with the regen nozzle in place, lots more stuff could be added to the assembly. In the collage below, five big items are shown in the process of installation: (1) the liquid oxygen pump discharge duct that carries liquid oxygen from the pump to the main oxidizer valve, (2) the oxidizer turbine discharge duct that contains within it the helium heat exchanger, (3) the turbine cross-over duct that carries hot turbine drive gas from the hydrogen turbopump turbine outlet to the oxidizer turbopump turbine inlet, (4) the main fuel valve, and (5) the fuel pump discharge duct that carries liquid hydrogen from the fuel pump to the main fuel valve.


And that’s just a small sampling of the flurry of assembly activity over the last few weeks. I like the fact that I was able to include pictures showing some of the folks working hard to get this thing put together. They’re doing an extraordinary job. The result of all this work is something that is really, truly starting to look like a rocket engine. The pictures below show what you’d see if you took a casual stroll around the engine. Note that the regen nozzle is covered with a black, protective tarp and there are other protective coverings all over the engine, so this isn’t quite as gorgeous as it could be, but for us rocket geeks it’s awfully compelling.


So, that’s where the engine stands. Almost all of the big stuff is installed, with just a couple of notable exceptions. Additionally, lots and lots of little stuff has also been installed. Over the past few weeks, it’s come a long, long way. As a reminder, take a look at this:


But, then, I guess everything eventually comes a long way with a little bit of hard work.  Take, for example, how I’ve been blessed to evolve through the years:


With all due respect to the Ford Motor Company and their venerable line of Pinto automobiles, that’s one heck of a leap even if it did take a long time. I just bet that my Uncle Johnny would be proud to think that he was there at the start of the whole thing.

J-2X Extra Rocket Alchemy: How Paper Becomes Precious Metal

Alchemy isn’t practiced much these days in the medieval sense.  That’s a shame.  A little extra gold would be useful.  But there is little doubt in my mind that alchemy is exactly what is going on behind the scenes, deep within the dungeons of NASA as we develop a rocket engine. 

How do I know?  Because I have been one of the chief alchemists for J-2X (…in fact, I kind of like that title: “Manager of Alchemy”).  No, we don’t start with a heap of scrap metal and end up with bars of gold or the philosopher’s stone.  Rather, we start with a heap of paper and end up with a rocket engine – and, well, a larger heap of paper.  As much as bending and grinding and welding and balancing and casting and torquing, the story of the paperwork is big part of how a rocket engine comes to be.

Hold on!  Yes, I am endeavoring to present here a blog article about paperwork and, further, I am endeavoring to make it (reasonably) interesting.  Really.  All along I have tried to convey the complexity and scope of what it takes to design and develop a rocket engine.  It ain’t easy.  That’s why not everyone does it and even we don’t do it very often.  And, like it or not, paperwork is what makes it all happen.

Here is how we at NASA develop launch systems:

Joe Mega-genius wakes up with a vision for what NASA ought to be doing.  He alone has the image in his mind for a launch system for exploring space.  He single-handedly directs everyone at NASA and every contractor as to what to do, what analyses to run, how thick the metal of a feedline needs to be, how the launch pad should be configured, the shapes of the knobs on astronaut’s control panels, the material to be used for the springs in the check valves on the engine, everything.  He personally takes care of all management and business and procurement activities so that there is a single, non-contradictory point of contact for everything.  And nobody at any other NASA center or Congress or the Administration questions what he says so he gets all the money in the world to spend as he sees fit because, after all, he is Joe Mega-genius.

All it takes is one brilliant focal point and everything falls into place easily.

Guess what:  That’s a lie.  This is not how it works.  Further, that is NEVER how it worked.  Never.  All cinematic or mythological approximations of that scenario are, simply, myths.  Nobody can know that much or do that much.  It takes many, many people and (good) paperwork is the key to get many, many people successfully coordinated. 

Note that specifically what I want to talk about is the paperwork that enables and facilitates development.  That is somewhat different than the many products that result from a development effort other than the hardware itself.  Perhaps we can talk about all of those other products at another time.  I also don’t want to talk about the paperwork at the highest levels, between the Federal Administration and Congress, the Office of Management and Budget (OMB) and agency authorization bills and appropriations bills, etc.  Interesting stuff, but not quite right for this blog (to say the least).

Let’s start with the assumption that we have a mission.  Let’s say that it is simply this: Get XX payload to low earth orbit.  Okay, simple enough.

How?  Well, there are lots of ways to launch something.  There are different rocket configurations using different propellants in different combinations.  Each potential solution brings with it certain positive and negative aspects, consequences far and wide.  So, we have a trade study and come up with a “best” solution.  That “best” solution has a particular configuration and piece parts that all have to work together.  So, we write down what those various parts all have to do.  Those are the top-level requirements.

 

So, we start with one mission objective and now we have requirements for the launch vehicle itself, for the launch pad, and for the launch control center.  If we just focus on the launch vehicle, we then have to further break down the requirements into separate groups for the payload section – including, of course, a crew element if we’re putting people in space – and the various stages and boosters.  And, on those stages there will be engines, so you have to break down the stage requirements into separate groupings for the engines and the tanks and propellant feed systems and the structures and the electrical systems and guidance and control systems. 

Thus, you start with one extremely broad mission and, in just a few steps, have dozens of separate groupings of requirements for dozens of different things that all need to work together.  At each step along the way, you need to figure out a conceptual design, i.e., a series of plausible configurations and functions for the various components, and then assign those necessary characteristics as requirements before you take the next step downwards.  And if you should decide at any point along the way that you want to change something higher up in the chain, then, boom, you have repercussions throughout everything below. 

This whole process is called requirements decomposition.  The management of the process represents a huge task at the early part of a development program and remains important throughout as you head into the verification phase where you demonstrate that every requirement has been fulfilled.  In the diagram below, you see the decomposition process.  Every place where there is a dashed line and a red dot I’ve loft out details, i.e., lots more stuff. 

 

What is the result of all this by the time it gets to, say, the J-2X?  Well, for J-2X we’ve got just about 200 requirements dictated to our development effort from the vehicle project level.  These requirements cover performance characteristics and physical properties and functionality and safety and operations considerations and standards as to how things are made and analyzed, plus a bevy of items dedicated to how the engine effectively interacts with the stage.  These requirements define, at the top level, what the J-2X shall be when development is complete.

Now what?  You’re at the beginning stages of a development effort and you’ve got in hand a book of requirements to fulfill, so what do you do next?  You make plans. 
• You create a plan for the overall development effort.  This includes how many development engines are you going to build and test, how many tests you’re going to run, where you’re going to run those tests, what you’re going to do in terms of testing at the component level, what analyses are you going to do, what level of non-destructive and destructive evaluation will you be performing on built and/or tested hardware. 
• You also make plans for how you’re going to manage the office and manage the various “office disciplines” such as risk management, business management, systems engineering and management, and configuration management. 
• You have an overall plan for how and what safety-related assessments and analyses are going to be done and by when.  This needs to be tightly coordinated with other elements of the launch architecture since the whole notion of safety is a wholly integrated consideration.
• You have to generate a clear plan and process for how decisions are going to be made since nearly all big decisions have budgetary or schedule or technical risk implications.  To enable these processes you issue charters to delegate formal authority for decision-making boards. 
• And there’s much more…

So, that’s how you get started.  In the beginning, you don’t usually have any hardware.  All you have is paper (or, these days, computer files).  And you’ll hear lots of people complain about “paperwork this and paperwork that,” but without this foundation of documentation, nothing else can follow.  What does come next beyond this foundation is that you fulfill your plans.  You do the design, do the analyses, create the drawings, fabricate the hardware, assemble the engine(s), and then test the hardware to demonstrate that you’ve met the imposed requirements. 

Thus, just as the rocket engine is itself a complex machine, so too is the infrastructure coordinating the efforts of hundreds of people to arrive at the final product.  In some ways, it’s even more complex than the rocket itself: imagine a shiny rocket engine rising out of a pile of paperwork.  It is truly, in the end, almost alchemy.