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.
