Tag Archives: J-2X rocket engine

Welcome to the J-2X Doghouse: You Dropped a Bomb on Me, Baby!

Posted on by .



The Gap Band, 1982!  Yep, just recalling those wise lyrics and the electrofunk music of my youth and I’m up and dancing and strutting around in my office like a goofball.  Luckily, nobody is watching.  So, is there a point to this opening other than imposing on you the painful image of a middle-aged bureaucrat getting down and getting funky in his office?  Yep, there is.  Here it goes:  The next J-2X Engine 10001 will be a bomb test.

You read that correctly: Bomb Test.

Now, I could probably weave a complex and fanciful tale explaining how “bomb test” is really just a creative government euphemism, but we’ve been straight with each other before, right?  So, the truth is that for this next test we will be mounting into the main combustion chamber a 100% genuine bomb, a small explosive device.  And, yes, we will detonate that device to set off an explosion.


Other than proving once again that we’ve got a cool job and that we’re really like a bunch of 14-year-olds who like to make loud smoke and fire, there is actually a technical reason for doing this.  Way, way back in February, some 20 articles ago (“”-2X Extra: Shiny Metal Pieces”), I briefly mentioned the possibility of combustion instabilities in the gas-generator.  I likened them to the melodious sounds from a pipe organ although combustion instabilities in rocket engines are far, far from melodious.  Indeed, they can be dangerous and destructive.  Our bomb test is a means for characterizing the combustion stability of the J-2X engine.

In order to understand combustion instabilities in a very general way, we have to take about a dozen steps backwards and get to some really basic physics.  The issue comes down to one of natural frequencies and resonance. 


Have you ever tried to push a kid on a swing?  Almost immediately, instinctively, you know that there is a particular rhythm with the swing and if you push in concert with that rhythm, the magnitude of the swinging motion will be increased.  If you try to push at a different rhythm, the kid just kind of sits there in the middle, bobbing around and getting annoyed.  The swing has a natural frequency and if you match that frequency, you get a big response.  That’s resonance.  If you fight against it, your energies are dissipated without much else happening.  Everyone can picture that, right?  That’s a simple, common, shared experience.  Good.

Next, we’re still going to use a rope, but in a little different manner.  In the diagram below, you see someone – i.e., you – holding onto a rope that is secured to a wall.  If you jiggle the rope with no rhythm (i.e., if you jiggle it kind of like how I dance to The Gap Band), not much happens.  It will wiggle and move, but with no organized pattern.  But very quickly, again almost instinctively, you can find the rhythm to make the rope define, back and forth, a single, graceful arc of movement.  With a little practice, you can then jiggle the rope at exactly twice that first speed and get it to make the shape shown in the middle.  And, if you’re really good, you can jiggle it at three times the speed of the first one and get the shapes shown on the bottom. 


If you do this, you will have demonstrated the first, second, and third natural modes of the standing waves for that length and properties of rope.  You cannot get those shapes by inputting any random jiggle on the end.  You have to input a specific forcing function, tuned to a specific frequency, and you will get the desired results.  Your forcing function must resonate with the mode.  Just like with the kid on the swing, if you input the wrong forcing function, nothing much happens.

Another point to consider — in addition to considering the forcing function — is that the rope has particular characteristics that define its natural modes.  But anyone who has ever picked up a guitar knows this, right?  Each string is a different thickness, each is pulled tight to a particular tension, and by putting your fingers on different frets, you alter the effective length of the string.  So, each string, when made the correct length and plucked, vibrates in its first natural mode to yield a particular note.  Because the guitar string is fixed on both ends, what you get when you pluck it is like the top picture in the jiggled rope discussion, the first natural mode.


Now, we’re going to make the jump from wave shapes in ropes to pressure waves in air.  Imagine rather than a string showing wave patterns, pressure variations in air.  Can’t image that?  Okay, then imagine someone talking to you.  Sound travels via fluctuations of pressure in the air.  When you talk, you tighten or loosen your vocal chords, make them vibrate like a guitar string, and sound emanates from that physical vibration turned into pressure variations in the air.  This is the jump from structural vibrations to acoustics but it’s still dependent on the notion of waves and frequencies. 

Okay, so rather than thinking about your vocal chords, imagine playing a trumpet.  You make your lips vibrate in the mouthpiece and, at certain particular frequencies, you can make the trumpet sing clear, bright notes.  You supply the forcing function; the forcing function matches a natural frequency of the column of air within the trumpet; and you create standing pressure waves that sound like music to everyone in the vicinity.  Quite simple.  And different instruments have different natural frequencies.  A tuba will never sound like a trumpet.  Why?  Because it has a different natural frequency and responds differently to different forcing functions. 


So, we started with a kid on a swing and now we’re talking about trumpets and tubas.  And what does any of that have to do with a bomb in a rocket engine?

Let’s review.  In our discussion we’ve learned that things have natural frequencies.  A rope has a natural frequency.  The space within a tuba has a natural frequency.  Everything around you has natural frequencies.  And we’ve learned that if you input a correct forcing function to a system, we can get organized results by working in conjunction with the natural frequencies.  We can get resonance.  A child swings high on the swing.  A rope makes neato patterns when jiggled.  A trumpet blares a high-C over the cheering crowd.  Okay, so here’s the kicker: all this stuff that we’ve discussed is exactly what we DON’T want to happen in the rocket engine combustion chamber.

Just like any other semi-enclosed space, a combustion chamber has natural frequencies.  These frequencies relate to all three dimensions in space (longitudinal, radial, and circumferential since chambers are typically cylindrical) and to the “stuff” in the space (for a tuba that “stuff” is air, in a combustion chamber it’s the propellants and, primarily, the combustion products).  These characteristics together define many, many potential natural frequencies, or modes, where the chamber could “sing.”  The forcing function is the combustion itself, which makes lots and lots of noise at many, many different frequencies and at extraordinarily great magnitudes all jumbled together.  So, you have lots of potential modes and lots of very powerful, very high-energy forcing functions.  Should these combine such that one feeds the other, then you could get resonance.  Again, resonance is what happens when you push the kid in the swing at the right rhythm.  But, taken to the extreme, a situation of resonance in an environment like a combustion chamber can continue to grow out of control until it becomes destructive.

Everyone’s favorite example of destructive resonance in practice was the Tacoma Narrows Bridge collapse in 1940.  The bridge was a suspension bridge, which means that it was kind of like a long, heavy, hanging piece of rope made of concrete and steel.  Well, it turns out that when the wind blew across the bridge at the right speed, it excited a natural mode of the hanging roadway.  As the forcing function blew, the bridge oscillated in response, more and more, quite violently, until, ultimately, the structure crumbled into Puget Sound.  These were not tornado-like winds.  They weren’t even unusually high winds.  They just happened to tune into the natural frequency of the bridge and the bridge responded by tearing itself apart.


Lesson:  Big vibrations can be destructive.  The bridge was fine when it was built.  It was fine for several months thereafter.  But when the right forcing function came along, it was disaster. 

This is as true in combustion chambers as it is for suspension bridges.  In order to avoid this, we build into combustion chambers such things as acoustic cavities, which are sized cavities that are  tuned so as to damp known natural frequency vibrations should they arise.  We also use physical barriers across the faceplate of the injector so as to disrupt the establishment of radial or circumferential pressure wave patterns.  These are features that we build into the design to help ensure that the space within the combustion chamber is not excited into any organized pattern that could build up to destructive levels.  We simply don’t want the chamber to sing. 

And this, finally, is where the bomb test comes in.  We use this kind of test to help prove that the features we’ve included in the combustion chamber do indeed suppress the formation of destructive oscillations.  During the test, we will set off the bomb.  It will act as a broad spectrum forcing function with sudden input of energy.  We need something as extreme as a bomb explosion to perform this energy input because there’s already so much energy being released in the combustion chamber.  It’s not like we could toot a horn at it and try to find some particular frequency.  That would be like trying to whisper to the person next to you while sitting in the fifth row of a rock concert.  It ain’t gonna get through.  So, we set off the bomb and if we have a mode lurking in the chamber that is not sufficiently suppressed by our design features, it ought to poke its head out of the noisy response that follows the explosion.  We will analyze the pressure oscillation and structural vibration data and look for notes that might “sing.”  We don’t expect any to be destructive based upon many years of design experience, but even if we identify any that don’t die down quickly we will have cause for further assessment. 

To wrap this up, I will use one more image that helps me whenever we talk about “instabilities.”  Through the whole discussion here, I’ve talked about vibrations and oscillations and natural modes and forcing functions and resonance, but what does that have to do with stability or instability? 


In the image above, I have drawn two situations of stability.  In both cases there is a ball sitting at rest between two hills.  For the ball on the left, if you perturb the ball slightly to the left or to the right, it will roll back to the middle and sit there peacefully.  However, for the ball on the right, if I perturb it much in either direction, the ball will crest one of the hills and fall into oblivion.  Thus, both situations shown are stable, but the one on the left is more intrinsically stable than the one on the right.

Similarly, the Tacoma Narrows Bridge was stable when it was built.  But given the right perturbation, it was knocked out of valley of stability and became destructively unstable.  Also, we know that the engine is stable.  We’ve already run several tests and it’s been fine.  While we don’t expect anything dramatic or destructive to happen on our upcoming test, this notion of “how stable” is what we’re examining with the bomb.  We are using the bomb to knock the ball off the center of the valley and then we’ll measure how quickly it comes back to rest, i.e., how deep and steep is the valley of our stability.  This is a measure and demonstration of the robustness of our engine design.

J-2X Progress: Mission-Duration Test

Posted on by .

Five hundred seconds is exactly eight minutes and twenty seconds.  Nope, that’s not rocket science.  But that was what I had to keep in mind as I watched the stopwatch application on my smart phone during the last J-2X test.  Eight minutes and twenty seconds.  That seems like a really long time when you’re counting every second.

Let me set the scene.

At the NASA Stennis Space center you have collected the directors from seven of the ten NASA field centers around the country.  You have representatives from the NASA headquarters in Washington, DC.  You have a live feed being picked up by NASA TV and broadcast into the living rooms of thousands or millions of dedicated NASA TV junkies.  You have dignitaries in suits and technicians and test conductors in jeans and Hawaiian shirts (test-day tradition), reporters with notepads and cameras from every paper and television station in the greater New Orleans and southern Mississippi area, and, sitting in his ceremonial throne, the Grand High Exalted Mystic Ruler of the International Order of Friendly Sons of the Raccoons.

Well, okay, that last part about the Exalted Mystic Ruler is just fictional (bonus points to anyone who gets the 20th-century cultural allusion without Google help), but that’s the way that it felt.  This was test A2J008, the seventh planned hot-fire test of the very first development engine and it was time to play show-and-tell.

Does everyone remember show-and-tell in elementary school?  You bring in something that you think is neato or special and, by getting up in front of class and talking about it you reveal something about yourself and you accidentally practice public speaking and presentation.  Once, when I was seven years old, I brought in my new baby brother, or, well, my mother did so at my behest.  I wish that I could remember what I said about him.  I imagine it was something like, “He’s short, cranky, and smells funny.”  Today, at least he can say, he’s taller than me.

J-2X is our new baby brother — of a sort to carry forward the analogy — and we’re showing him off to the world.  Through the first six hot fire tests of engine E10001, we accumulated a total of 225 seconds of test time.  For test A2J008, on November 9th, our show-and-tell for the world, we scheduled a test lasting 500 seconds, which is the mission duration requirement for the engine.  Here is what I saw during the test, while holding the stopwatch, standing out in the field in front of the test control center:

Can’t see anything?  Okay, I’ll expand the picture in pieces starting on the left.

This is the hydrogen burn stack.  All of the excess hydrogen coming from the facility or from the engine before, during, and after the test needs to be burned off.  This is all bleed flows and waste flows that you cannot avoid when dealing with a cryogenic propellant.  If you let hydrogen accumulate anywhere around the facility, then “BOOM” you’re eventually going to have an explosion.  Talk to the guys who work out in the test areas and they’ll tell you plenty of tales of such things.  What is amazing as you’re standing out in that field to watch the test is the radiation heat coming off that thing.  It was a chilly day and yet you almost feel like you’re going to end up with a sun-tanned face.  It feels like the sun while you’re on the beach except that as warm is it makes your front side, your back side is still chilly from the blustery November breeze.  Kind of an odd sensation being both overheated and chilly at the same time.

In the middle of the picture is a sign for anyone who was born without that instinctual reflex for self-preservation.  While it would seem obvious to me to not walk in front of a roaring rocket engine throwing out a plume reaching hundreds of feet in the air, the fact that they have a sign like this suggests to me that for someone, somewhere, at some time, this was not so obvious.  An unfortunate thought…

And, on the right-hand side of the picture, in the distance, is test stand A-2 with the engine firing.  In the middle of the picture below, there is a tiny, very white spot in the middle of the test stand.  That’s the flame coming directly out of the engine nozzle.  In the bottom right corner of the picture below you can just see the edge of one of the liquid hydrogen barges.  For both liquid oxygen and liquid hydrogen, for extended duration tests, the propellant tanks on the test stand are not quite big enough to hold all of the necessary propellant.  So, during the test you actually transfer propellants from these barges into the test stand tanks.  So, the engine is draining the test stand tanks while you are simultaneously re-filling them from the barges.  With all of this going on, you start to appreciate the coordination necessary to pull off one of these tests.

 

When you’re standing there being halfway cooked by the burn stack, several hundred feet away, the roar from the engine is nearly deafening.  Many people wear hearing protection.  Others of us are aging rock-n-roll fans.  I honestly don’t think that anyone gets a complete sense of how powerful these machines are until they see, hear, and feel one of these tests.  All of the performance numbers in the world simply do not have the same visceral impact as when the engine lights and the initial sound wave runs over, around, and through you and you watch the flame bucket fill with billowing, thick, white steam.  Even twenty years after having seen my first test in person, I still cannot help but stand there like a bedazzled goof and say to myself, “Wow.”

Here, below, is a picture of the test from the other side of the stand.  Why is this important (other than the sign on the fence clearly advertising what you’re looking at)?  Because this is the side from which all of the non-NASA folks, some of the NASA dignitaries as well – including an astronaut representative – and the local press corps watched the test.  


So as to not keep you in any more suspense, the test came off perfectly.  The full, planned duration of 500 seconds was achieved thereby effectively tripling out test experience to date.  The coverage on NASA TV was good.  The bigwigs clapped and cheered with infectious excitement right along the rest of us.  And the press corps wore out their thesauruses trying to capture just a slice of the actual experience.  It was a complete success on all fronts.

Congratulations to the Pratt & Whitney Rocketdyne J-2X development team, the NASA SSC test crew, and the NASA Marshall Space Flight Center project management team.  While I had every bit of confidence that we’d be successful, with so many people watching our show-and-tell exercise, those 500 seconds — eight minutes and twenty seconds — ticking away on my stopwatch seemed like a whole lot longer.  Whew! and Yahoo!


 

 

J-2X Extras: Here Comes the Bride — Vehicle Integration

Posted on by .

I just got back into the office a few days ago after a long weekend in Philadelphia. My wife’s niece got married. It was a beautiful venue and a moving service and good food, fabulous band, great party, and celebratory beverages flowed freely. Our niece looked gorgeous and her new husband was suitably handsome. A good time was had by all! Congratulations Ashley and Carmello!

And in the midst of all these festivities, an analogy came to mind regarding J-2X (well okay, perhaps not truly in the midst of the festivities, but certainly as part of the next-day hangover).  It’s not a perfect analogy, but it kind of works on a couple of levels.  I am referring to engine-to-vehicle integration.  Here, follow my thinking…

The wedding itself is a great big project.  Everything needs to be figured out, from the biggest stuff (Where?  When?  Who to invite?) to the finest details (What food is to be served at the cocktail hour?  What are the different lighting schemes for the service and for the dinner?).  So too is the development and launch of a great big launch vehicle.  When the engine and the stage come together and the mission comes off as planned, it’s beautiful.  Launch day is just like a well planned, well coordinated wedding.

Also, beyond just the singular event of the wedding day, there it the issue of everything that follows, i.e., the marriage.  And that is a matter of compatibility.  The most spectacular venue for the service and the best food for dinner and the grooviest band for the reception doesn’t guarantee happily ever after.  Things have to work together on many levels in order for success to be found in a match, whether that’s two people married or the engine and the stage coming together and successfully fulfilling a mission.

(Okay, so how’s that analogy working for me?  Not bad, huh?)

So what’s “vehicle integration”?  Well, it’s lots of stuff.  On the one hand, it’s the basic engine requirements.  After all, who says that J-2X ought to generate 294,000 pounds-force thrust at vacuum conditions?  It’s not as if us engine folks get to randomly pick a power level requirement out of thin air.  It comes from an integrated, comprehensive mission analysis of the vehicle.  While we like to think that the engine folks run the world, the truth is that without a vehicle and a mission to dictate requirements, we’d be nothing more than an expensive science project.

But beyond this, how do we interact with the stage?  I would suggest that there are four essential categories of interaction:
• Integrated analysis
• Boundary conditions
• Induced environments
• Operations

The first area, I’ve already discussed in part.  Integrated vehicle/mission analysis is used to establish the basic requirements for the engine.  Beyond that, though, you have other analyses such as contingency and hazards analyses that examine what happens if something goes wrong.  How should the vehicle respond if there is an issue with the engine or the stage or with how the engine and stage interact with each other?  So, in addition to defining upfront what the pieces should do, integrated analysis looks at how the actual, designed parts will interact under different circumstance.  Note that an output of integrated analysis often leads to the category of induced environments discussed below.

Next, you have boundary conditions and these are the most straightforward consideration.  In order to figure out what you need here, all you have to do is draw a box around the engine and see what stuff has to go into or out of the box to make the engine-vehicle combination work.  In fact, that’s basically how we started in creating the Interface Control Document (ICD) for J-2X.  That’s where you capture all of the agreements between the engine and the stage.  Here’s a piece of that “what’s crossing the box” diagram:

This diagram shows the fluids (liquids, gases) that cross the interface with the stage.  You have, of course, the propellant flows of liquid hydrogen and liquid oxygen, but then you also have the propellant tank pressurization flows that are used by the stage to keep the tanks pressurized during flight.  There are also gases used for pneumatic control of the valves and to perform purges through different phases of the flight.  There is a dedicated line that handles high-pressure helium for spin-starting the engine.  And then there are drain flows back to the stage for disposal of excess hydrogen and oxygen.  This latter category is necessary for safety reasons since, for an upper stage engine, it’s usually enclosed within the vehicle for much of the mission and you don’t want to build up an explosive mixture of fuel and oxidizer in the intertank area.

For each of these interfaces, we have to define throughout the different phases of the mission acceptable pressure ranges, temperature ranges, flowrates, and fluid qualities (purity, particulate contamination, etc.).  Both sides have to agree that these values at this interface will happen during the mission or else someone might make an erroneous assumption and either the engine or the stage could fail to perform.  Sometimes, we need to specify even more detail to ensure mission success such as the two-dimensional velocity profile of the propellants as they enter the engine.  Something like this can drive significant design effort on one side or the other (or both) so such details are rarely trivial. 

Now, add to this one set of interface just for fluids additional interfaces for electrical power, control and data transmissions, and then the actual physical connections (including not just the forces and moments applied to these connections but the actual physical designs themselves in terms of dimensions and materials, bolt-hole patterns, and seal configurations).  After you’ve done all that — fully negotiated and agreed to by both sides — you then have an ICD, one of the bedrock documents in the life of any engine.  It’s like a really, really detailed marriage license that goes on and on between the engine and the stage: who cuts the grass, who does the laundry, who sleeps on what side of the bed, who cleans the litter boxes, who opens the pickle jars, who has the remote control come football season…

The next area of consideration with regards to vehicle integration is induced loads.  In truth, these are really just another boundary condition, but we often break them out separately for convenience of tracking and documentation.  What we’re talking about here are loads: structural dynamics, acoustics, and thermal loads.  Rocket engines and launch vehicles make lots of rumbling, roaring noise and lots of smoke and fire.  That’s part of what makes them kinda cool (right?!).  But it’s also the kind of stuff that can cause damage if not properly accounted for in the design. 

Above is the output from an integrated analysis looking at thermal conditions of the engine during a stage separation event.  In this case, depending upon the design of the stage separation system, there were situations where the engine was getting exposed to damaging thermal loads.  In other words, the stage was imposing a load on the engine that jeopardized mission success, so the stage design was altered.  All of the elements of the vehicle have to live with the environments created by everyone else.  So, this is not too much unlike figuring out how to live together after getting married.  You learn, for example, that the combined environment of stogie smoke, an overgrown lawn, and blaring NASCAR on television apparently do not constitute the most congenial, constructive induced environment at home…

The last category in my simplified breakdown of vehicle integration is that of operations.  This comes down to who does what, when, and how.  Bringing together a whole vehicle requires quite a detailed set of instructions.  It’s a lot more than “Insert tab A into slot B.”  And the pieces that you’re assembling come from several different project office and different contractors located all over the country.  So, on the one side of the issue is the technical matter of how you do the whole thing, but on the other side, just as importantly, you have the issue of who is responsible for performing the tasks.  With tasks come manpower, roles and responsibilities for facilities and tooling and, before you know it, meaningful expenses.  Thus, (ta-da!) you’ve got more negotiations and agreements and documentation.

So, engine-to-vehicle integration is, in the end, like a long, complex, heavily negotiated, analyzed, and documented marriage.  Perhaps then, other than the documentation part, it’s probably like most successful marriages over the long haul.

Inside The J-2X Doghouse: A2J006 &Turbopump Thrust Balance

Posted on by .

Okay, before I even get to the subject of thrust balance, I want to report that J-2X development engine E10001 got back into the stand and that the next test, A2J006, was conducted.  The test went the full planned duration of 40 seconds and the issues that caused us to remove the engine after the previous test all appear to be fixed.  In other words, it was a complete success.  Here’s a video for your viewing pleasure:

 

https://www.nasa.gov/multimedia/videogallery/index.html?media_id=113620611

 

Now, speaking of issues on E10001 that appear to be resolved, I want to talk about turbopump thrust balance.  While I hadn’t previously mentioned it, the data from the first several tests showed that there was a thrust balance issue with the oxidizer turbopump (OTP).  So, that naturally leads to the question:  What is “thrust balance?”

 

Here is a crude drawing of a turbopump for this discussion (And, please, save your cards and letters telling me that I am a terrible artist.  I will already catch plenty of grief from the turbo guys over this drawing.).  The arrows are intended to illustrate fluid flows.

 


 

I’ve drawn this in three colors because a turbopump can be thought of as having three fundamental elements.  The first element, the one in blue, is the part that spins.  This is the rotor onto which is attached the pumping stuff (i.e., the inducer and the impeller) on the pump side and the turbine stuff (i.e., the disks and blades) on the turbine side.

 

The second element, shown in green, is the part that doesn’t spin.  This is the housing.  It is the shell within which the rotor spins.

The third element, shown in red, is the bearings. 

 

Whenever you’ve got one thing spinning and another thing stationary, you’ve got to have some way of communicating between the two pieces.  Maybe the rotor just spins and slides around in some kind of restraint holding it in place.  Well that might work except that you can’t put grease into a cryogenic oxygen environment and, should too much heat build-up due to friction, then you’ve got a very combustible situation.  Mix heat with a pure oxygen environment and anything and everything will burn, including metal. 

 

What we do instead is typically use ball bearings between the rotor and the housing.  In some other pumps we use roller bearings that look like little cylinders rather than little balls, and there are other solutions as well.  These bearings do two things, they allow the rotor to spin and they hold the rotor in place.  So they need to be loose enough to spin yet tight enough to maintain control of a heavy hunk of metal spinning at over 10,000 rpm.  How much force the bearing put on the rotor to maintain control and, conversely, how much the rotor puts back on the bearings is called the bearing load. 

When you are designing a turbopump, you design it so that the bearings have a specific load, and that means more than just a value, it also means a direction as shown in the sketch above.  You design the whole bearing package assuming that you know the magnitude and direction of the forces loaded through the package.  This then allows you to do some calculations that tell you, “Yep, I’ve got the rotor properly and sufficiently controlled.”  Those calculations are part of what is often referred to as rotordynamics (and, by the way, NASA MSFC has some of the world’s best experts in that area).

 

Question: How do you get different bearing loads in a turbopump?  Answer: Pressures.

 

Here is a nifty little fact: Pressure is all around us.  We don’t feel the atmospheric pressure of 14.7 pounds-force over every square inch of your body because, well, it’s always been there.  That’s the environment within which we’ve evolved.  Now, go to the bottom of the ocean and you’ll find a whole other pressure environment, one that would crush our delicate bodies into mess.  The basic principle to remember is this: Pressure applied over an area equals force.

 

Within a turbopump, you are explicitly manipulating pressure.  That’s the whole purpose of a pump: to move fluid through the use of pressure.  So, in the pump end you have a low pressure coming in at the inlet and a very high pressure at the outlet.  On the turbine end, it’s the opposite since on that end you’re extracting energy (and therefore pressure) from the fluid.  So, on the turbine end you have high pressure at the inlet and lower pressure at the outlet.  Thus, throughout the turbopump, you’ve got pressures of all sorts and those pressures are pushing on the different pieces of the rotor.  This means that you’ve got all kinds of forces pushing on the rotor.  Some of the forces push the rotor towards the turbine end.  Some of the forces push the rotor towards the pump end.  Getting the right balance of forces is called your thrust balance.

 

 

 

So, what’s the “right” thrust balance?  It is the one to which you’ve designed your bearings.  You design your bearings to have a certain load and a big part of that load is determines by the thrust balance on the rotor.  So, if your thrust balance is off, i.e., not what you intended, then your bearing loads are off and you’re therefore not controlling the rotor the way that you wanted.  In the worst of circumstances, an out-of-control rotor represents a catastrophic situation.  In less-than-worst circumstances, operating with a thrust balance significantly different than the design intent could lead to unexpected wear on components and therefore limited operational life. 

 

The next question is this: How do you create the thrust balance that you want and need to accomplish all this? 

 

That’s a matter of designing the internal guts of the turbopump and analytically modeling all of the internal flows within these guts.  In addition to the big flows coming into and out of the pump and turbine, you’ve got internal flows around seals, between pump or turbine stage, and through the bearings (as coolant).  When operating, the whole turbopump is full of fluid.  And, everywhere you have fluid, you have a pressure; and everywhere you have pressure applied to an area, you have a force.  So you calculate pressure drops through small passages or through seals and figure out a whole detailed map of different pressures and forces throughout the whole unit and you can understand your thrust balance.  And then, as necessary, you manipulate your clearances and seals and passages designs until you achieve the thrust balance you need.

 

 

 

Getting back to the E10001 OTP, what appears to have been the issue was that we had some seals that were too tight.  The tight seals overly restricted internal flows and, basically, messed up the intended force balance on the rotor.  This could be seen in the data collected from the testing.  Remember when I said several articles ago that this engine is instrumented to the max so that we can learn all about how it is working.  Here is a case where special instrumentation identified an issue.  The interesting part is that these seals were kinda sorta fine in terms of design but the processing of the material of which they are made — it feels like hard plastic — was not quite refined enough so that when subjected to operational conditions it changes dimensions and actually tightened up. 

 
 
 

Prior to test A2J006, while we had the engine out of the stand, our contractor Pratt & Whitney Rocketdyne was able to partially disassemble the engine and the OTP just enough to change out the seals in question and then get the whole thing buttoned up and ready for test in record time.  They truly did some excellent work here.  And the success of test A2J006 is the proof!

 

J-2X Progress: Engine 10001 Testing Status

Posted on by .

When last I discussed with y’all the status of testing on the first J-2X development engine, E10001, I showed you a video of our first mainstage test, A2J003. That article was posted just over a month ago. So, what’s been happening since then? Hopefully, this brief article will catch you up to where we are.

First, we had test A2J004 in early August. This test went the full, planned duration of 7 seconds. This was our first test with any sustained duration at mainstage conditions. Lots and lots of good data. The Datadogs and the analysts were absolutely giddy for days and days afterwards.

We then had test A2J005 in mid August. This test was scheduled for 50 seconds duration but it was cut off at 32.2 seconds due to a not-totally-unexpected redline cut. This redline cut was similar to the one described for A2J003. In fact, it was the same parameter although the test conditions were different. You can stomp your foot, or kick at the air, moan, whine, whatever; it doesn’t really make any difference (…which is not to say that we did any of this … well, okay, maybe a little whining…). This is all simply part of the learning process with a new engine. It is expected, necessary, and educational. Deep breath and all is well.

Here is a video of test A2J005: J-2X Fifty Second Test

However, after test A2J005 shutdown — several seconds after shutdown — we had a “pop.” These are not uncommon when ground testing rocket engines so let me use yet another automobile analogy (since I use them so often) to explain.



 

Just a few years ago, I was still driving my 19-year-old pickup that I bought just before grad school. Towards the end of its long and glorious life, my little red truck developed a habit of rumbling and grumbling to a stop long after I’d turned the key to “off.” Residual gasoline fumes and air and hot metal combined into a sequence of “blurrr, blurrr, cough, cough, blurrr … POP” (and the neighbors just loved that!). In essence, a similar thing happened on A2J005.




In flight, the shutdown environments are quite different than on the ground. When you’re way, way up in the atmosphere — or even outside of the atmosphere — the surrounding environment is effectively a vacuum, which is a very useful means of sucking out any residual propellants from the engine after shutdown. On the ground, residual stuff (leftover propellants and fuel-rich combustion products) doesn’t get pulled out as efficiently. We can and do push it out with inert gas purges, but they’re not always as effective as we’d like. And so, on A2J005, we didn’t get everything pushed out as well as we’d like and we had a “pop” — or, actually, a “POP.” Technically speaking, it was a detonation in the “lox dome,” i.e., the oxidizer manifold volume feeding the main injector.



The bottom line is that we had some damage. It wasn’t anything that couldn’t be fixed and so, we’re fixing it. We didn’t bend any metal or anything like that. It’s more of breaking something that’s kind of like really tough plastic. Throughout this article you’ll see pictures of the engine being pulled out of the test stand because we couldn’t do the repair in place. After removal, we then took the engine back across the NASA Stennis Space Center to the assembly facility. In other words, we took it back to the garage for a tune up and we’ll be back in business soon. In fact, E10001 will be reinstalled by mid-September and we’ll be back into testing right around the start of October. Oh, and we’ll be doing a better job of avoiding pops based on what we’ve learned about purge rates and durations.



So, that’s where we stand. Two things to look forward to in the future: first, the upcoming report on test A2J006 after it happens, and, second, a discussion of another change we made to the engine while we had it in the shop. That latter discussion is an interesting technical tidbit regarding the internals of turbomachinery. So, “Don’t touch that dial!” and keep your set tuned to this station…



(I think that my grandparents had this exact set! Ahh, the good old days of vacuum tubes and horizontal hold.)



Inside The J-2X Doghouse: Engine Control — Open versus Closed Loop

Posted on by .

As I was driving to work this morning, I came up over a rise and saw suddenly appear in my windshield, over towards the left on the other side of the road, a police cruiser with a radar gun mounted in the window.  Even before I could think about it, the pressure of my right foot on the accelerator lessened.  I then instinctively looked at the speedometer and found that I was traveling 48 miles per hour on a road for which the speed limit is 45 mph.  Thankfully, the officer apparently forgave me the 3 mph violation and continued to wait where he was for a better opportunity to serve and protect the community. 

 

What I find interesting about that little episode was the immediate, unthinking response I made in response to seeing the cruiser.  In terms of control systems, that could be called a feedback loop.  My senses received data, my brain rapidly processed that data and then sent a signal to react to the data, and then my calf muscles responded by easing up on the throttle.  The car, in turn, slowed to respond to the lower throttle.  Never mind, of course, that if I’d been really, really speeding all this would have been too late (and I would have arrived at work very angry), there was nevertheless a closed-loop response that is not too dissimilar to what we do for rocket engine control … in some cases.

 

First, let’s get familiar with a couple of terms –

 

Open-loop: We typically refer to something as open-loop when we have instrumentation that measures conditions in the engine but the engine itself does not respond to those measurements.

 

Closed-loop: We typically refer to something as closed-loop when we have instrumentation that measures conditions in the engine and then, potentially, the engine takes action based upon those measurements.

 

It is based upon those definitions that I would call my response to seeing the cruiser closed-loop since I responded and did something with the data.  Another example would be the more modern systems that are used to monitor and control automobile systems.  It used to be that you had a temperature measurement stuck in the coolant loop.  You could watch the temperature rise, but until the system went kaput and boiled over leaving you stranded alongside the road, there was no active, closed-loop control.  Nowadays, if the computer in my pickup truck sees that the engine temperature is too high, it will take action to try and protect itself.  For example, it will inhibit the use of the air conditioning system since that represents an additional power requirement on the engine.



 So, what do we control on a rocket engine?

 

One thing that we control is power level.  On the Space Shuttle Main Engine (SSME), power level is controlled in a closed-loop manner.  This means that the main combustion chamber pressure is measured as an indication of thrust level and in response to that measurement a valve is opened or closed to increase or decrease the engine power level.  On the J-2X, power level is controlled in an open-loop manner.  This means that we measure the main combustion chamber pressure but we don’t have any feedback loop where we control a valve to ensure that we’re on target.  Instead, should we happen to be off on power level, we have to physically change an orifice in the engine between tests.  The “feedback loop” is data analysis and a guy with a wrench.  Which approach you choose to take are dependent upon your requirements of performance and affordability. 

 

Another thing that we control on a rocket engine is the mixture ratio (i.e., the ratio of oxidizer to fuel).  Given that on a rocket you are carrying both your oxidizer and fuel with you in the vehicle, you certainly want to make sure that you consume your propellants in the correct ratio to get the most uumph out of them.  Again, on SSME we control mixture ratio in a closed loop manner.  There is actually a small flowmeter on the SSME and, using the data from that flowmeter (and some associated calculations), we move a valve on the engine to dial in the correct mixture ratio.  It’s a pretty nifty system.  Also again, on the J-2X, we have an open-loop system for mixture ratio just like we have for power level.  We test the engine, look at the results, and, if necessary, make a physical change to the engine in the form of an orifice.

 

Because of these two areas, power level and mixture ratio, SSME is usually referred to as a “closed-loop engine” and J-2X is usually referred to as an “open-loop engine.”  Now, this terminology is not entirely correct since there are some closed feedback loops within the J-2X control system pertaining to engine health and status diagnostics, but we all know how enduring shorthand designations can be.  Also, engines don’t have to be one or the other.  They can be half-and-half.  The engine used on the Delta IV vehicle, the RS-68, sort of falls in this category. 

 

How you choose to design your engine control system is driven by your requirements.  Put real simply:  The SSME is all fancy-schmancy because it had extremely tight power level and mixture ratio precision requirements and because it was a reusable engine.  The J-2X is intentionally more simplistic because it has looser precision requirements and because it is expendable (and throwing away orifices is a whole lot cheaper than throwing away valves if your requirements will let you get away with it).  Requirements drive design.

 

Note that I will save the fun topic of engine diagnostics — and the potential for long philosophical meanderings within that realm — for future posting. 


 


 

 

Let’s end this posting with a fun little exercise.  Above is a simplified schematic of a gas-generator cycle engine kind of like a J-2X.  I have shown in the schematic two orifices #1 and #2 (highlighted in yellow).  With those two orifices, we can calibrate the engine.

 

Scenario:  Power level too low, i.e., measured main combustion chamber pressure too low.

·         Solution:  Increase the size of orifice #1.

·         Explanation:  By increasing the size of orifice #1, I will deliver more oxidizer to the gas generator.  This will deliver more power to both turbines thereby increasing how much propellant gets pumped into the engine.  More propellants pumped in equals more thrust and greater overall power level.

 

Scenario: Power level too high, i.e., measured main combustion chamber pressure too high.

·         Solution:  Decrease the size of orifice #1.

·         Explanation:  The exact opposite of the previous scenario.

 

Scenario:  Mixture ratio too low, i.e., the flow of oxidizer is too low in proportion to the flow of fuel, as measured by the test facility.

·         Solution:  Decrease the size of orifice #2 and decrease size of orifice #1.

·         Explanation:  By decreasing the size of orifice #2, I decrease the amount of flow that is diverted around the oxidizer turbopump turbine.  I therefore increase the flow through the turbine thereby increasing pumping power of the oxidizer side.  So I increase oxidizer flow to the engine.  However, by increasing oxidizer flow to the engine and doing nothing else, I’ve probably messed up my overall engine power level so I’ve got to back down a little bit by decreasing the size of orifice #1.

 

Scenario:  Mixture ratio too high, i.e., the flow of oxidizer is too high in proportion to the flow of fuel, as measured by the test facility.

·         Solution:  Increase the size of orifice #2 and increase size of orifice #1.

·         Explanation:  The opposite of the rationale for the scenario immediately above.

 

See, being a rocket scientist isn’t that difficult, really.  Now you too can calibrate an open-loop rocket engine.

 

 

P.S., I read in the paper this morning that NASCAR racer Kyle Busch had his civilian driver’s license revoked for 45 days for doing 128 mph in a 45 mph zone.  Well, at least I wasn’t going that fast when I came over the rise this morning and saw the police cruiser.  Then again, I wasn’t driving a $400,000 Lexus LFA sports car like Mr. Busch was…

 


 

 

 

J-2X Doghouse: Okay, So We Ain't That Smart — Yet

Posted on by .

Welcome back to the J-2X Doghouse.  We’re going talk about some test results and test data, exactly what Data Dogs love most to do.

Back in the day — back before I had the carefully regulated, federally mandated, and strictly enforced lobotomy that allows people into the ranks of management — I was once an analyst.  And, since it seems so long ago that it doesn’t sound like bragging anymore, I will admit that I was pretty good at it.  I absolutely loved the process of using fundamental physics or empirical correlations for fluid dynamics, thermodynamics, and heat transfer all together to simulate in computer coding how things function in the real world.  Whereas many people enter the field engineering because they like mechanical things or electronic things, there are some of us who relish the seeming purity of problem solving in abstraction.

 Over the years, working on many diverse projects and building many diverse mathematical models to simulate many diverse systems, I came to the realization that my models always appeared most unassailable and brilliant when there was no test data against which to compare them.  To put it bluntly, test data always proves that you simply ain’t as smart as you thought you were.  But, that’s okay.  If that wasn’t the case, then you wouldn’t bother to test.  The whole point of testing to gather data and learn more.

With all due respect to the Serenity Prayer, this ought to be the analyst’s prayer relative to testing:

Grant me —
— the results to validate that which I do understand
— the data to explain that which I did not understand
— and the openness to accept that I can always understand better

That last line is critical.  Ignoring data contrary to what your model output is a seductive, addictive, and dangerous path to follow.  We don’t/won’t do that.

That brings us to the subject of test A2J003 of the J-2X development engine E10001.  This was our first test to mainstage operation.  The planned duration was to be seven seconds.  On Tuesday 26 July, right around five in the afternoon, the test ran for 3.72 seconds and then shutdown.  We did not accomplish the full duration.  Why?  Basically because we ain’t as smart as we thought we were.  We had analytical models telling us that performance would be X, but the hardware knew better and decided on its own to perform to Y.  Here is a cool video of the test:

J-2X Engine Test A2J003

A more detailed explanation of what happened is that the engine shutdown due to the measurement of a pressure too high in the main combustion chamber.  The measurement crossed a pre-set “redline” and the test controller unit took the automatic (and autonomous) action of shutting down the engine in a safe and controlled manner.  The high pressure in the main chamber was caused by higher than expected power coming out of the oxidizer pump.  This, in turn, was due to more power being delivered to the turbine side than expected.  It comes down to a fluid dynamics phenomenon (pressure drops) and what we have is not inherently bad, just different than expected.  So, in essence, we used our models to predict that the pressure in the main chamber would be at a certain level — indicating a certain power level — but the different performance of the hardware resulted in pushing us away from our analytical prediction.

  • Here is the good part:  We learned something.  We learned that our model needs to be updated and we collected the data that will allow that to happen.
  • Here is another good part:  We got enough data, despite the short duration, to recalibrate the engine for the next test thereby making it far more likely that we will hit our target. .
  • Here is yet another good part:  We had a successful demonstration of the test controller redline system by safely shutting down the engine.  The engine looks fine.  The controller did exactly what it was supposed to do and protected the hardware.  In fact, for these early tests we have the redlines clamped down pretty tight specifically to protect the hardware as we learn more about the engine..
  • And here is, finally, yet another good part:  Other than the power applied to the oxidizer turbopump, most of our other predictions with regards to hardware performance appear to be awfully darn good.  So, we’ve got a preliminary validation for much of our understanding of the engine.  Indeed, this is a brand new engine and we have just accomplished mainstage operation in the second hot-fire test.  That is truly unprecedented..
  • Here is the bad part: We have to spend a few minutes explaining to folks not directly involved that despite not achieving full duration, the test was in reality a total success.

If that, then, is the bad part, I can live with it.  I can live with admitting that we ain’t as smart as we thought were.  Why?  Because now, after the test, we are indeed smarter.  And we will continue to get smarter and smarter about the J-2X design until, one day, we will be smart enough to say that, yes, we understand this engine so well that it is safe enough to propel humans into space.

J-2X Progress: Pardon Me

Posted on by .

I’ve lived in the South for about 20 years now.  Over that time, I’ve heard and learned all kinds of quirks of regional dialect and colloquial sayings.  I’m quite sure that I’ve even picked up a few myself.  Oh well.  One particular expression shared with me by a former training partner in the gym was a compliment.  She told me that I had good “home training.”  That is a shorthand way of saying that my parents taught me to have good manner. 

With that in mind, and in consideration of what we’ve been calling the first hot-fire test of J-2X development engine E10001 (i.e., the “burp test”), I respectfully and bashfully declare:


 

In the early evening of Thursday, 14 July, E10001 generated a burst of ignition and thrust with something like a 30,000 pounds of force — enough to toss five or six crew-cab pickup trucks into the air.  That’s one heck of a burp.  Yep, we were successful.  NASA Stennis Space Center in Mississippi, coordinating with the Upper Stage Engine office at the NASA Marshall Space Flight Center and with Pratt & Whitney Rocketdyne in Los Angeles, California conducted a full-duration, 1.9-second test.  Here is a picture of what a burp that big looks like:

 


 

Here are a couple of pictures of the engine prior to the test.  These are taken from a deck inside the test stand basically looking down on the engine.  The nozzle extends through the deck to the next level below.

 



 

You’ll note that there’s some misty fog hanging around the engine in those pictures.  While it is true that most of the time you can almost see the thickly humid air of southern Mississippi in July, this is something different.  This fog is being created by the presence of cryogenic propellants in the lines.  These lines are so cold that they effectively condense water in the air around them, even at a distance, to create a fog.  Here are some close-up frosty pics of lines chilled down prior to test:

 

 

Out of one end comes smoke and fire while the other end is frosty cold.  This is a good illustration of the broad span of environments that exist within a rocket engine.

So, what’s next?

As exciting at this brief test was, what we didn’t do is light the gas generator and get the turbomachinery up to full speed.  That’s the goal for the next test.  In addition to spinning up the turbopumps with helium and lighting the propellants in the main chamber, as we did for the burp test, we’ll take the next step in the start sequence and light off the propellants in the gas generator.  This will provide the turbopumps with the power necessary to reach mainstage, steady-state operation.  And that — those initial few seconds of mainstage —  will be our first glimpse at genuine engine operation like that which will propel spacecrafts into orbit and then outwards across our solar system.

J-2X Progress: The Burp Test

Posted on by .

On my very first home computer, I had a silly little program — made by the marketers for the Monty Python brand name I believe — that turned the keyboard into collection of funny or disgusting or borderline obscene simulated sounds of bodily functions.  Several keys triggered a variety of sneezing sounds.   Another set of keys activated a broad range of burping sounds.  Another set of keys set off sounds inappropriate for further discussion within a NASA blog.  And, of course, there were handful of sounds that simply left you scratching your head.  I guess that one should feel heartened by the notion that even at a time when the sterile realm of machines seem to be taking over our lives, we still revert to our childish fascination and amusement with the functions of our quirky bodies. 

 

And so, in that light, I give to you the J-2X Burp Test.  No, that is of course not the official name.  The official name is the “J-2X Ignition Test” or, even more formally: Test A2J001.  That really rolls off the tongue doesn’t it? 

Etymological dissection of “A2J001”
     • “A2” because the test is happening on NASA Stennis Space Center test stand A-2.
     • “J” to distinguish this from 30 years of Space Shuttle Main Engine Testing data records related 
        to test stand A-2.
     • “001” because, well, it’s the first test

The first test of the first J-2X development engine will have a duration of 1.9 seconds between the time that the engine receives a command to start and the time that the engine receives a command to shutdown.  That is not a long time.  It is, indeed, not a whole lot more than an extended, impolite belch considering that the engine is designed to ultimately roar for a full eight or ten minutes for full-duration tests.

So, why do such a seemingly silly little test?  That’s a valid question and the answers back are just as valid.  We have a wide range of objectives for this test.  For example, this will be the first time that cryogenic propellants (liquid oxygen, liquid hydrogen) will have been loaded into the engine and the lowest reaches of the facility feedlines.  Remember, these fluids are so cold that they make metal shrink.  You have to design the engine and the facility to resist or accommodate this thermal stress.  And while you continuously check for leaks as you assemble the engine and the facility, nothing is ever quite like a good cryogenic chill for finding where seals might separate. 

Also, during a chill test you want to make sure that you can get the engine cold.  I know that that sounds funny, but it is possible to have enough ambient heat going back into the metal of the hardware such that it overwhelms the capacity of the cold fluids to take it away.  Essentially what happens is the cryogenic fluids boil when they hit warmer metal.  Boil?  Like water in a pot on the stove?  Yes, but remember that liquid hydrogen boils at about 420 degrees below zero and liquid oxygen boils at about 300 degrees below zero (both Fahrenheit).  What you want is for the hardware to get so cold that the boiling stops.  This is accomplished by continuously flowing new, fresh, cold stuff through the hardware via a bleed line.  During the chill test, you monitor the conditions within the engine and of the fluid coming out of the bleed line.  When you get to a suitably cold, steady state situation, then you’ve successfully chilled the engine.

Why is this important?  First, you run this test to make sure that you actually can chill the engine.  Not only do you design the engine to run, you have to design it to be able to get to this chilled state during a launch sequence.  Second, the engine needs to be chilled because if you have any boiling liquid in the pumps when it is time to start, that boiling represents voids in the fluid.  The movement of the pump will exacerbate these voids and potentially convert even more of the liquid into gas.  The pumps are not designed to pump gas and so the result is that the engine could go off mixture ratio, or it could fail to start, or it could even head rapidly towards a far more exciting failure situation.  Like a good martini, really chilled is really good.

Next, after the long chill, like a long, filling meal, comes the … BURP …

The 1.9 ignition test will demonstrate: the use of the helium spin-start system, ignition of the augmented spark igniter and the main injector, and the functioning of the start continue logic software.  Now, explaining one at a time — 

In your automobile, you’ve got an electric motor that, when you turn the key (or push a button these days in some fancy cars), spins the motor to life.  We’ve got essentially the same thing on the J-2X.  There are different ways that this could be accomplished, but one of the cleanest and simplest is to use the inherent functionality of the turbines and provide a burst of power in the form of high-pressure helium.  The helium flows through the turbines, spins up the pumps, and thereby builds pressure throughout the engine making it primed for the rest of the start sequence.  The important features that will be demonstrated with the planned short test is the careful timing of the sequence and the tailoring of the pressure profile supplied to the turbines to yield the desired pressure build up on the other end, in the pumps.

The augmented spark igniter (ASI) is, effectively, a torch lit off by a pair of spark plugs.  This small hydrogen-oxygen torch resides in the center of the main injector and it is what lights off the propellants in the main chamber during the start sequence.  Just like you don’t start a campfire by holding a match against the biggest log in the pile, the ASI provides the kindling to get the main fire going.  The burp test will demonstrate the effective discharging of our high-tech spark plugs and achieve ignition of the ASI and the main chamber.  They will not be lit for long, but just long enough to characterize the process.

Just like everything these days, the J-2X and the entire test facility element are run by software.  Streams of 1s and 0s are taking over everything.  And while J-2X does not have an exceptionally complex control system, there are a handful of absolutely critical feedback loops that must function properly.  The “start continue logic” is composed of a set of criteria that tell you, as the engine progresses through the start sequence, that it is okay to continue with the process.  Being not “okay” in this case means that you could be facing a catastrophic situation and that you must halt the engine starting process in order to ensure safety (of the engine, of the test stand, and, in flight, of the vehicle and crew).  Now, for this short test, it is extremely unlikely that we would be building up enough energy to damage much of anything even if things did go awry, but what is important is the demonstration of the closed loop of imposed software limits, measured parameters, the application of software logic, and the confirmation that all is well.  Considering that the engine and test facility is being entirely controlled by a group of people in a secured building that is hundreds of yards away, making sure that you’ve got complete control of the test facility and test article, and complete insight into what’s going on via instrumentation, is pretty darn important.

So, that explains the strategy behind the first test of J-2X E10001.  What we will not be doing is lighting the gas generator.  That would be the next step in the start sequence: spin up the pumps, open the valves, light the main chamber, and then light the gas generator.  We will then be just one step away from ramping up to full power.  We’ll save that step for next test. 

To be entirely frank, this first won’t be very impressive for uninvolved bystanders, it probably won’t even be as much fun for a lot of people as would be the silly/disgusting bodily function sounds on my very first computer, but for those of us down in details, this burp test is a vital full — dress rehearsal before the real fun begins of genuine, mainstage engine testing.  It represents yet another significant milestone on our path towards completing J-2X development.  Go J-2X!

 

J-2X Extra: The Rocket Engine Development Life Cycle

Posted on by .

Everyone has in their personal histories certain events that they can look back on and say, “That’s where things changed for me.”  Some of these could be planned rites of passage like the first day of kindergarten, joining a little league team, getting your driver’s license, and high school graduation.  Others are not necessarily foreseen or planned but seem in retrospect like inevitable events such as a championship football game, falling in love, or your child being born.  Everyone has a history, a story.  It is the narrative of how we come to be who we are.  Believe it or not, rocket engines also have a life story of how they come to be.

Below is a timeline of a rocket engine development life cycle (and, yes, that is actually what we call it: “life cycle”).

 

The first thing that you’ll notice from the drawing is that there are a bunch of NASA-typical three-letter abbreviations.  Sorry for that, but I promise that I will explain them.  Generally, think of these three-letter abbreviations as milestones or as gates through which the engine development project much pass.  For the rocket engine, these are its planned rites of passage.  The gray bars below the timeline of milestones describe the general activities during different phases of the development effort.  Note, however, that these are general notions and every engine development project is different.  For example, if what you’re doing is a change to an existing engine or if you have components already developed lying around and waiting to be incorporated into an engine, then perhaps you could do earlier component testing.  Also, not shown on here are such things as subscale or laboratory testing.  These too can often occur earlier in the life cycle thereby informing the design of the system.  On the other hand, if you’re starting entirely from scratch, then you’ve got to do a good bit of work before you would even know what to wring out in the laboratory.  In that case, everything can get pushed outwards to the right.

The first milestone gate in the life cycle is Authority to Proceed (ATP).  For activities as substantial as rocket engine development, we don’t go off willy — nilly and decide for ourselves when to start such a thing.  While that might be fun for a little while, it is a generally accepted and overarching rule — of — thumb that prison is something we should to endeavor to avoid.  There is a whole chain of command that ultimately flows down from Congress and the Administration.  Thus, at ATP we essentially get a formal charter to fulfill certain objectives such as, in this case, develop an engine.  Also, with that charter comes the authority to spend time and money in pursuit of the objectives.  The authority part is key.  And so, not much can happen until ATP.

Next, you have the milestone of the System Requirements Review (SRR).  Before you can design something, you need to know what it is that you need and expect it to do.  Now, some requirements development had better have happened at a higher level before you even began the project — otherwise, how would you even know that you need to start developing a rocket engine versus, say, a rocking chair? —  but getting a set of valid, system-level functional, performance, physical, and safety requirements is extremely important.  In addition to the system requirements pertaining to the engine, the other stuff that is part of the SRR is a whole slate of the programmatic documentation that forms the infrastructure for the organization responsible for the development effort.  This review therefore establishes the foundation of the product and the processes for the development effort to follow.

For all of these “reviews,” what these represent is, usually, one great — big meeting, sometimes taking several days, multiple smaller meetings, detailed review, comment, and response periods on documentation and drawings and analyses and test data, and a final, formal series of technical and programmatic board meetings airing any issues found, citing accomplishments identified, and declaring the success or failure of passing through the gate.  They are periods of intense activity and high internal and external scrutiny.

The next milestone in the timeline, the System Definition Review (SDR), is sometimes combined with the SRR.  The objective of the SDR is to demonstrate that you have a concept for the rocket engine that is plausible, feasible, and achievable given programmatic constraints.  However, since you need to have something in your head that is plausible, feasible, and achievable as part of the validation of your requirements set, separating SRR and SDR does not always make sense.  For J-2X, for example, we conducted the two of them as a joint review.

The first true design review is the Preliminary Design Review (PDR).  The question at this review is, at its root, pretty simple:  Do we have the right design?  Now that we’ve spent some time doing analyses, performing trade studies between subsystem design concepts, perhaps running component or subscale tests, laying out the initial drawings, can we say with sufficient confidence that we have a functional design that meets our technical requirements within the limits of the time and money we’ve been allocated?  To me, more than at any other moment in the development life cycle, this is that pivotal point.  If you fail here, everything stops, as it should.  It means that you’ve been working on the wrong design.  Start over.  However, if you are successful, then you start ordering materials to start building the engine and you commit to completing the design.  The stakes are very, very high.

The next milestone is an interesting one.  For many, many development efforts other than rocket engines, the Critical Design Review (CDR) is The Design Review.  For these other projects, it represents a true completion point for the final, to-be-flown design and it often takes place after prototype fabrication and testing.  But for a rocket engine development effort, the CDR takes on a somewhat different flavor.  This is because just building a rocket engine for testing can take several years and the necessary extensive test program that can also consume a couple of more years of activity.  Thus, for a rocket engine, the CDR is focused on getting the right design into the test stand.  The question to be answered is this:  Are we still on the right path, with the design essentially finished, to commit to the rest of the effort?  Therefore, you review not only the design (and associated matured analyses) but also all of the planning documentation that explains how the engines that you are already building will be used to demonstrate that the design meets all of the imposed requirements.  In essence, you have to prove that all of your ducks are in a row because now you’re getting into some serious welding, grinding, shaping, and cutting of metal. 

Note that because CDR is not the final review of the flight design for a rocket engine, there can be a handful non-milestone check-point meetings during the years that follow the CDR.  For J-2X, we held one such meeting about a year after CDR in order to help come to closure on any actions lingering from the design phase and to review our maturing go-forward plans.  We may have another one prior to going into what we call certification testing with what we believe to be the true final, to-be-flown design of the engine.

The final, formal milestone for a rocket engine development project is the Design Certification Review (DCR).  At the end of this review process, the engine is declared to be certified for spaceflight.  So, what is reviewed?  It is a combination of several things.  The first part is known as a physical configuration audit.  This is basically a demonstration that you can (and have, and will continue to in the future) build what the design drawings prescribe.  The second part is known as the functional configuration audit.  This is a review of all of the collected evidence demonstrating that the engine fulfills all of the functional, performance, physical, and safety requirements imposed at the very beginning.  The evidence is a wide array of test data, analyses, and/or inspection results.  And the final portion of the DCR is a review and approval of all of the other products related to the engine design.  These include operational manuals and, most importantly, all of the reliability and safety analyses and assessments, plus an assessment of the quality and configuration management systems in place to ensure continued high standards during subsequent engine production.  Overall, when you complete a successful DCR, you are stamping the entire development effort as a success and pointing towards a future of successful launch operations.  It is therefore both an endpoint and a point of transition.

So, how long does all this activity take?  Well, that depends strongly on whether you’re just making limited modifications to an existing design or if you’re starting from scratch.  Using these scenarios as extremes, you usually can get to PDR in one or two years.  At PDR you start the process of test engine fabrication.  For very simple engines, fabrication can be as short as a couple of years.  For other, complex and large engines, fabrication for a first unit can take as long as five years or more.  Again, depending on how much new stuff you have to prove out, your test program could be as short as a year or as long as three years or more.  Thus, the duration between ATP and DCR could be as short as three or four years or as long as seven or eight (or, historically speaking for truly new and different stuff, even longer).  And that is all dependent on getting an appropriate funding stream…but that’s a discussion for another time…


If you’ve made it through to the end of this article, you now have a high — altitude perspective of what makes up the life cycle for a rocket engine development effort.  Successfully guiding that whole process from one rite of passage to another, from ATP through DCR (within budget and schedule), the entire development life cycle, sometimes seems like herding cats, but that’s the essence of project management.  Luckily, as you can see from the picture above, I’ve had some experience with the whole clowder of cats thing.

Page 2 of 41234