Top Down Design Of Rockets

This is an excerpt from the NASA report on the first shuttle disaster. It is from an appendix that RichardFeynman wrote. See http://history.nasa.gov/rogersrep/v2appf.htm

The usual way that such engines are designed (for military or civilian aircraft) may be called the component system, or bottom-up design. First it is necessary to thoroughly understand the properties and limitations of the materials to be used (for turbine blades, for example), and tests are begun in experimental rigs to determine those. With this knowledge larger component parts (such as bearings) are designed and tested individually. As deficiencies and design errors are noted they are corrected and verified with further testing. Since one tests only parts at a time these tests and modifications are not overly expensive. Finally one works up to the final design of the entire engine, to the necessary specifications. There is a good chance, by this time that the engine will generally succeed, or that any failures are easily isolated and analyzed because the failure modes, limitations of materials, etc., are so well understood. There is a very good chance that the modifications to the engine to get around the final difficulties are not very hard to make, for most of the serious problems have already been discovered and dealt with in the earlier, less expensive, stages of the process.

The Space Shuttle Main Engine was handled in a different manner, top down, we might say. The engine was designed and put together all at once with relatively little detailed preliminary study of the material and components. Then when troubles are found in the bearings, turbine blades, coolant pipes, etc., it is more expensive and difficult to discover the causes and make changes. For example, cracks have been found in the turbine blades of the high pressure oxygen turbopump. Are they caused by flaws in the material, the effect of the oxygen atmosphere on the properties of the material, the thermal stresses of startup or shutdown, the vibration and stresses of steady running, or mainly at some resonance at certain speeds, etc.? How long can we run from crack initiation to crack failure, and how does this depend on power level? Using the completed engine as a test bed to resolve such questions is extremely expensive. One does not wish to lose an entire engine in order to find out where and how failure occurs. Yet, an accurate knowledge of this information is essential to acquire a confidence in the engine reliability in use. Without detailed understanding, confidence can not be attained.

Note the conclusion: testing is much cheaper if you design your rocket bottom up rather than top down, and you are more likely to develop a reliable rocket.

If ComponentBasedDesign? (something I use in Synthesis) is BottomUpDesign is the reverse implication that Analysis is part of TopDownDesign, correct?

Yep, BottomUpDesign of rockets works for us (http://psas.pdx.edu).

It's interesting- I'm not sure that you can generalize from Rocket design to software design though. That said, I do think that bottom up design is often a better approach for building software.

It's worth noting that "BottomUpDesign" is actually part of an iterative process that begins with "TopDownConcept?" and continues with "WhatCanWeBuild?" and "WhatComponentsArePossible?" -- keeping in mind that the goal has already been established from the top.

Remember, the process doesn't begin (in this case) with somebody tinkering with turbine blades, motor nozzles, and fuel burn rates, finally concluding, "hey, I can build a rocket with this stuff!" (Although there are examples of this kind of invention/discovery.)

The goal (go to the moon, put something in orbit, bomb an enemy) has already been established; the decision to build a rocket occurs during the TopDownConcept? stage, along with range and payload concerns.

The BottomUpImplementation? is quite sound ("okay, we need motors that will develop this much power, sustained for this much time, to lift a payload with these structural constraints in order to deliver said payload to the target, so let's begin by determining the limitations of our materials and methods") and achieves consistently reliable results and shorter, less costly debug cycles.

ForthLanguage development follows this pattern. In fact, for years, since learning the fundamentals of Forth, my programming has reflected this thinking.