Space Shuttle Performance Evolution
Lesson 17: Designing for The –ilities and Cost
The –ilities and Cost Must Be On the Design Table If We Are To Be Successful Challenge Requirements and Constraints
Penetrate Competing Concepts with Sufficient Fidelity Select the Right Concept
The success of a launch system is measured not only by its physical performance parameters such as how much payload it can lift to orbit, but by its reliability, its operability, how much it costs, and numerous other attributes. A successful system must be designed from the start for these ―-ilities‖ and costs as well as for physical performance. In order to do this, the designer must be provided functional relationships that connect the design variables available to him/her with how they affect vehicle‘s future operation—its -ilities and costs. We call this ―putting the –ilities and cost on the design table‖ (or more currently, ―on the CAD system‖). The –ilities and costs can then be part of the system optimization along with physical performance.
Examples
Space Shuttle Day of Launch I-Load Update (DOLILU)
Designing Considering the Total Life Cycle
How We Previously Designed for the –ilities and Cost
How We Should Design for the –ilities and Cost
We will first look at the Shuttle Day of Launch I-Load Update process as an example of operational complexity not foreseen in the initial design, then compare how we have
designed for the –ilities and cost in the past with how we should design for them in the future.
Shuttle Day of Launch I-Load Update
Wind biasing as a means of reducing structural load was discussed in Lesson 6 on the Balancing Act. There we noted that the Shuttle was intended to be designed with enough structural strength to allow launch using a trajectory biased for the monthly mean wind.
Because of the aerodynamic anomaly described in Lesson 4, the Shuttle in fact wasn‘t strong enough to be launched with monthly mean biasing, but required biasing for the winds
measured on the day of launch. A Day of Launch I-Load Update (DOLILU) process was required, which entailed significant operational complexity and expense. Wind biasing involves calculating the guidance parameters based on the bias wind, and loading them into the flight computer. With monthly mean biasing, this process can be accomplished and verified well ahead of launch day, but with day-of-launch wind biasing, all this must be done in a short time span based on winds measured a few hours prior to launch. [Norbraten, 1992]
Figure 17-1 shows some example elements of the DOLILU process for Shuttle. At several times prior to launch, balloons are used to measure winds and atmospheric parameters. The wind measured at L minus 3:45 hours is smoothed and used to bias the first-stage guidance commands so that if the vehicle in flight should experience that same wind, there would be no wind-induced loads. In actuality, the wind will change between the time the balloon measures it and the vehicle flies through it, but biasing to the balloon-measured wind will minimize the wind-induced load. The biased first-stage guidance commands that have been generated must be verified, approved, and then loaded into the flight computer prior to launch. The trajectory command set is called an I-load.
Figure 17-1. Elements of Day of Launch I-Load Update (DOLILU) Process The biased trajectory profile must be assessed to ensure that when the vehicle flies that profile, the loads will not exceed the structural capability. This requires taking into account the many vehicle parameter variations and the variability of the wind between the time of balloon measurement and launch. These variations are combined statistically as
―knock-down‖ factors on the structural capability to produce load indicator boundaries called Q-planes as a function of altitude. The simulated response of the vehicle using the I-load must lie within these boundaries; otherwise, the launch is no-go. An additional Q-plane check is made using the wind measured by a subsequent balloon closer to launch (L minus 2:00 hours). There is sufficient time before launch to make this verification check, but not to create an updated I-load set.
Figure 17-2 shows some of the process, with the balloon releases indicated by stars along the timeline leading up to launch (L-0). Wind data from the L-3:45 balloon is combined with other information to create the I-load for the onboard flight computers. For redundancy, two organizations independently generate I-load input in parallel, which must compare
identically before this flight-critical item is loaded onto the flight computers. The load is them read back to the ground systems for confirmation.
Figure 17-2. Shuttle Day of Launch I-Load Update Data Flow and Timeline
“Some graphics on Figures 17-1 and 17-2 are from a presentation on DOLILU Operations by Brian Harrington, USA, April 20, 2005.”
Although the process has been streamlined from earlier DOLILU approaches, it is clear that the Day of Launch I-Load process requires significant operational effort and complexity. Because the Shuttle is not structurally robust, the program has to pay the
operational cost of this process to safely achieve a reasonable launch probability. This is an example of operational complexity not in the original plan.
Design Considering the Total Life Cycle
In the past we typically focused our design activities on the physical performance of the vehicle, then assessed the design for operability, reliability, and cost. What is needed is to design for the total life cycle, which means designing not only for performance, but also (and concurrently) designing for the –ilities and cost.
Figure 17-3 shows a listing of typical metrics of design—those attributes that measure how the system performs, operates, and costs. We can collect them into three categories:
(1) Performance, which describes how the physical system behaves, (2) The –ilities, which includes attributes such as safety, reliability, manufacturability, operability, etc., and (3) Costs, which includes various measures of cost. Because our systems are highly
interconnected, changing one of these attributes typically will affect the others, within the same category as well as in the other categories.
Figure 17-3. Interacting Metrics of Design
In order to obtain a balanced design that meets –ilities and cost goals as well as performance, we must take a systems design/optimization approach across all aspects of the life cycle (Figure 17-4).
Figure 17-4. Design Considering Total Life Cycle
How We Previously Designed for the –ilities and Cost
The previous design approach is illustrated in Figure 17-5, showing the initial concept being designed iteratively for performance, then subsequent assessments and adjustments being made for –ilities and cost. The –ilities and costs are harder to predict than are
measures of physical performance. This process is iterative and sequential, and produces a less than ideal design.
Concept
Performance Prediction
―-ilities‖
Prediction
Cost Prediction
PREVIOUS DESIGN APPROACH
Sequential, Iterative, …..
Figure 17-5. Previous Design Approach
How We Should Design for the –ilities and Cost
What is needed is a comprehensive process that addresses downstream –ilities and costs concurrently with performance. As discussed earlier, we describe this as ―putting – ilities and costs on the design table‖. In order to do this, we need to have functional relationships that provide the designer with measures of costs, operability, reliability,
manufacturability, etc., as a function of the design parameters that the designer can choose (Figure 17-6). Another design process improvement represented on the figure is integrated system analysis that where possible unifies analysis of subsystems, design functions, and discipline functions that are currently compartmentalized.
To optimize the total system we need functional relationships from the -ilities and costs related back to the design parameters.
DESIRED DESIGN APPROACH
Figure 17-6. Desired Design Approach
Obtaining functional relationships between the –ilities/costs and design parameters would enable an ideal concept assessment process illustrated notionally in Figure 17-7. Here the different concepts or designs are mapped into an attribute space (represented
simplistically on the figure as three-dimensional) that includes all metrics. Comparisons and directions for improvement would be direct, enabling unified design for the total life cycle.
Concept A
Figure 17-7. Functional Relationships Enable Design Solutions for Multiple Concepts
Obtaining the functional relationships needed for the above process is a challenge—
only a few are currently available. Based on historical or other data, people in all technical areas should work to identify functional relationships that connect the –ilities and cost to design variables, thus working toward making the –ilities and cost concurrent ―design-to‖
attributes along with performance.
A key message from Lesson 17 is:
Work toward making the –ilities and cost concurrent “design-to” attributes along with performance.