Tag Archives: vehicle integration

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.