As described in the statement of task (see Appendix A), the committee was asked to address the criteria and assumptions in the formulation of the current reusable booster system (RBS) plans and the ability of current technology plans to meet technical readiness milestones. At the present time, very little detail is available on the structure of the reusable booster system (RBS) development plan. In the absence of these details, the committee examined programmatic issues likely to arise. This chapter provides an overview of these programmatic considerations and identifies best practices from previous launch vehicle development programs.
To begin, it is recommended that the RBS program be conducted in phases that are specifically structured to systematically reduce and retire risk. The program should have predefined go/no-go decision points structured as on-ramps for the next phase, once the technical and programmatic risks are reduced to the level specified at the completion of the preceding phase. The main RBS program risks defined by the Air Force and augmented by the committee are listed in Table 5.1.
The following subsections include a suggested program structure for risk retirement and identified on-ramps, and address other important programmatic considerations and observations.
Although several different, high-level RBS development plans were presented to the committee, no detailed consolidated plan was provided. For this reason, the committee generated its own systematic RBS development program plan for retiring risk (Figure 5.1). The committee believes that the Pathfinder phase and the reusable booster demonstrator (RBD) conceptual design and technology efforts that support it should be completed through initial flight testing before committing funding for the remainder of RBS development. In addition, the committee believes that the demonstrator phase and the RBS-Y conceptual design and technology efforts that support it should be successfully completed through initial flight testing before the RBS-Y design is initiated. The complete RBS development program is separated into eight phases, some serial and some parallel. On-ramps are provided between phases and at the completion of some phases to assure that risk reduction goals are sufficiently accomplished to adequately support the subsequent phase.
TABLE 5.1 RBS Development Risks in Perceived Order of Criticality
|Development Risk||Section In Which Addressed|
|1. Rocketback maneuver||Section 3.3|
|2. Hydrocarbon engine using oxygen-rich, staged combustion cycle||Section 3.2|
|3. Upper-stage separation||Section 3.6|
|4. Adaptive guidance and control (AG&C)||Section 3.5|
|5. Integrated vehicle health management (IVHM)||Section 3.4|
|6. Techniques to enable rapid ground processing||Appendix F|
FIGURE 5.1 Committee’s proposed RBS development risk reduction phases. NOTE: AGN&C, adaptive guidance navigation and control; CDR, critical design review; Fab & Assay, fabrication and assembly; IVHM, integrated vehicle health management; PDR, preliminary design review; Prod & Ops, production and operations; and RB Demo, reusable booster demonstrator.
Development of adaptive guidance and control (AG&C) capability is critical for supporting the RBS Pathfinder. This technology must be sufficiently mature for incorporation into the first Pathfinder flight to demonstrate the return-to-launch-site (RTLS) rocketback maneuver plus glideback and landing. Accomplishment of this would partially retire Risk 4 in Table 5.1. If this technology is not ready, it will delay the first Pathfinder flight and could jeopardize the RBS program. Extensive integrated testing of AG&C, combined with Integrated Vehicle Health Management (IVHM) and booster actuators in a simulation laboratory, is essential in developing booster flight
software to accommodate potential subsystem failure modes. Critical is the availability of mature AG&C for incorporation into the RBD to assess booster rapid ground processing, fully retiring Risk 4.
A preliminary version of IVHM is required to support AG&C during the Pathfinder flight tests. Development of an evolved IVHM version will be needed for the RBD to support both flight tests and the demonstration of ground turnaround operations. Appropriate IVHM sensors will need to be integrated into the design of the new ORSC engine to meet operability requirements for reusability. This partially retires Risk 5. An IVHM version must be available for the RBS-Y booster and demonstrated through the full-scale testing to fully retire Risk 5. Extensive integrated testing of IVHM, combined with AG&C and booster actuators in a simulation laboratory, is essential for developing booster flight software.
This subscale reusable booster flight test article addresses Risk 1 primarily and Risk 4 secondarily. Its main purpose is to demonstrate the feasibility of the rocketback turnaround maneuver, although at lower Mach numbers and altitude. If Pathfinder can demonstrate vehicle aerodynamic control and propellant control for engine feed during turnaround, that would partially retire Risk 1, and AG&C for flight control would partially reduce Risk 4. To reduce risk to the Pathfinder flight demonstration phase, the RBS development program should consider flying at least two competing concepts. This increases the opportunity for success and is likely to lead to more robust design(s) for the RBD booster. If neither of these Pathfinder vehicles can successfully demonstrate the rocketback turnaround and RTLS maneuver, then the RBS program development approach will need to be reassessed. This is the key on-ramp to committing funding for continued RBS Program development.
Development of a reusable oxygen-rich, staged-combustion (ORSC) hydrocarbon rocket engine for RBS is likely to be conducted in two phases: a U.S. version of the Russian NK-33 (i.e., the AJ-26) to achieve some level of reusability and an upgraded and modernized version of the AJ-26 or a new ORSC engine development. A new ORSC engine improves reusability and incorporates IVHM; which provides input to the AG&C to accommodate in-flight anomalies and enhance operability for rapid booster ground turnaround.
126.96.36.199 AJ-26 Engine Development Phase
This phase is conducted in parallel with the RBS Pathfinder to support the RBS demonstrator phase. Using the NK-33 engine as a point of departure, it develops a completely U.S.-built ORSC LO2/RP-1 rocket engine (AJ-26) that can satisfy the RBD reusability goal. If this U.S. version is not available, a back-up position would be to use several NK-33 engines to perform the RBD flight demonstrations.
188.8.131.52 New ORSC Engine Development Phase
This phase is conducted in parallel with the development of the Pathfinder and RBS demonstrator development. This engine is considered a new development by the U.S. aerospace industry and introduces a new design which requires design, development, test, and evaluation and technology development specifically in materials and processes and incorporation of IVHM sensors. Further development of the AJ-26 could conceivably satisfy this requirement. New material is required to eliminate the coating process utilized on the U.S. version of the AJ-26. The new material is required to be compatible in an oxygen-rich high-pressure environment. An ORSC engine is required to reduce coking, thereby enhancing engine reuse. It is essential that any new material selected will satisfy the LO2 compatibility requirement and be properly characterized as well as reasonable in cost to procure and manufacture.
To enable AG&C, IVHM sensors will have to be incorporated into this engine to provide in-flight health assessment. The cost of the new engine development and risk mitigation has been identified in the program planning. Successful completion of this phase will fully retire Risk 2 and retire the engine part of Risk 5.
This phase starts once Pathfinder has successfully demonstrated rocketback turnaround, and continues in parallel with the ongoing new ORSC rocket engine development. The RBD consists of a larger, but still midscale demonstrator vehicle that is focused on demonstrating rocketback turnaround and RTLS at conditions closer to the full-scale booster (additional retirement of Risk 1), further development of AG&C (Risk 4), demonstration of vehicle-level IVHM technologies (Risk 5), and initial development of rapid ground processing operations (Risk 6) for reflight. RBD is also used to demonstrate second stage separation, using a small upper stage (reduction of Risk 3). The new ORSC engine development and RBD phases will need to be successfully completed at approximately the same time to authorize the start of full-scale RBS-Y development. This achievement would constitute the second primary programmatic on-ramp supporting design of the RBS-Y.
The two Y-vehicle flyback boosters and the large expendable stages, payload fairings, and ground infrastructure (one launch processing facility at the Cape Canaveral Air Force Station [CCAFS]) are full-scale prototypes of the RBS. This development work constitutes a full program of System Requirements Review, Preliminary Design Review, Conceptual Design Review, and production authorization. The vehicles are developed and flight tested to validate the full program requirements and retire all of the remaining risks. Based on the experience gained during Y-vehicle flight testing and ground operations, improvements are identified for the production phase to better achieve all of the RBS goals and objectives. If this phase is not successfully accomplished, the program can be reassessed.
The remainder of the Booster fleet (six vehicles as per the baseline or two vehicles as per the committee’s recommendations; see Section 184.108.40.206) is produced and the two Y-vehicles are modified to incorporate the lessons learned during the previous demonstration phase. Boosters continue to be produced, but at a reduced rate, second stages and payload fairings are authorized, and the launch complex and support infrastructure at both CCAFS and Vandenberg Air Force Base (VAFB) are modified. The RBS fleet continues to operate to meet Air Force and other government mission requirements as do commercial missions if they are executed from the same facilities using the same vehicles.
Incorporating important lessons learned from other recent launch vehicle programs (primarily Evolved Expendable Launch Vehicles, EELV) into the RBS development strategy will prove to be beneficial.
A straightforward method of tracking risk reduction uses a time-phased red, yellow, green chart. Each risk is depicted as a line item, and reductions (moving from red to yellow to green) are predicated on successfully accomplishing specific events or demonstrations (the risk reduction plan).
These charts are kept up to date by the engineering department to reflect accomplishments and shown at every internal and customer program review. This approach is somewhat subjective, but provides mutual visibility for management and the project engineers on a real-time recurring basis. More complicated analytical methods tend to get lost in the process of data generation and do not provide better risk reduction visibility. An example developed by the committee and applied to the Pathfinder project is shown in Figure 5.2.
FIGURE 5.2 Example of a chart showing risk reduction of the rocketback return-to-launch-site (RTLS) maneuver. NOTE: AGN&C, adaptive guidance navigation and control; CFD, computational fluid dynamics; IVHM, integrated vehicle health management.
The outstanding launch reliability records of both the Atlas and Delta EELVs have been achieved, in part, by each program institutionalizing a Continuous Improvement philosophy. This happened first when both Atlas and Delta were commercial programs but has continued when they were combined under United Launch Alliance. This approach, which enjoys a program budget allocated for changes and for a supporting nonbureaucratic change process, coupled with a rigorous Systems Engineering process, allows improvements to be implemented quickly. When difficulties arise in procurement, manufacturing, or launch operations, fixes can be identified and analyzed and are presented to an Engineering Review Board (ERB). Estimated implementation costs and a phase-in schedule are included. The contractor’s Program Management then makes a yes or no decision, and provides the budget needed for implementation.
Excluded from this process is the requirement to estimate the cost savings resulting from the change and preparation of an Engineering Change Proposal (ECP) for customer approval and funding. In most cases, the cost savings are difficult to capture, because the problem being addressed by the change affects the hidden factory (hard-to-build or operate hardware that causes quality problems). Continuous Improvement implementation on the Atlas program resulted in cost savings that were significantly greater than the cost of making the changes. These changes have also resulted in a more robust vehicle, more streamlined launch operations, and a workforce that is continuously engaged in fixing problems and improving the product.
Careful and complete identification of the subscale development article configurations (Pathfinder and RBD) is extremely important to ensure that subsequent full-scale vehicle designs understand what has been tested. As changes are made to these flight test articles, they must be well documented.
Configuration control must be rigorously maintained on the full-scale RBS elements. This is fairly straightforward for the expendable upper stage and payload fairing, which are discarded during every mission. Changes on these items must be documented as they occur, but there is no need for retrofit. For the reusable boosters, however, configuration control must be carefully managed to make sure improvement changes are incorporated across the fleet. During Y-vehicle operations, many changes will undoubtedly be identified. Some will require immediate incorporation to maintain flight status, while others will await the block change for the first production booster. Once several production boosters have achieved flight status, the two Y-vehicles will be retrofitted to incorporate all the current design changes. If a continuous improvement philosophy is adopted (see Section 5.2.2), changes to production vehicles will continue. To better manage this, a leader-follower approach to booster use may be advantageous. If one booster is used for recurring missions, while the others remain in ready status, the nonimmediate changes can be incorporated into the stored boosters without impacting flight operations.
The RBS program will be large enough that it does not escape considerable cost scrutiny throughout its development and fielding. The standard cost management techniques, including earned value management, should be incorporated from the start, with on-ramps for meeting cost objectives that are as rigorous as the technical on-ramps. Two funding philosophies should be incorporated: the program should be budgeted at 80 percent should-cost confidence, and the program should carry a 25 percent management reserve of cost-to-complete at each stage of the program until transition to a fixed-price procurement for the operational vehicles.
One of the biggest problems with the oversight process, including the Nunn-McCurdy system, is that most space systems find (or put) themselves in a position where the capabilities to be provided are “essential” to national security. Therefore, the remaining question is whether there is an alternative way to achieve the capabilities at lower cost. Once a program has spent billions buying down risk, it is highly unlikely that a lower cost option going forward can be found. The Space-Based Infrared System, the Advanced Extremely High Frequency satellite, the Mobile User Objective System, National Polar-Orbiting Observational Environmental Satellite System (NPOESS), and even EELV today are programs that experienced enormous cost growth yet were/are essential and were continued after Nunn-McCurdy breaches, including being restructured, because there was no better alternative. Eventually, decision makers above the program level decided NPOESS was simply in too much trouble and had to be terminated. SpaceX is offering the possibility of an alternative for EELV, in the future if not in the near term, subject to demonstrating the required launch reliability.
Therefore, one of the most important cost management tools is to ensure that RBS is not allowed to become essential until the risk is sufficiently low and cost confidence is quite high. To achieve this, it will be necessary that the current Air Force launch system(s) or mature alternative vehicles be maintained in production while RBS is in development.
RBS will be an Air Force-managed program, and direct involvement with development contractors, hardware manufacturers, and operations will be required. The following committee observations are based on experience with recent Air Force-managed programs.
An independent program assessment (IPA) should be conducted to provide input into a go/no go process leading into each succeeding program phase. Ideally, the IPA will have total, unrestricted access to all support data and personnel of the government and contractors, and will be responsible only to the milestone decision authority. Experience has shown that program managers rarely recognize if their program has run into sufficient trouble that it should be terminated or substantially revised. Instead, they argue for a new baseline of cost and schedule in order to proceed with a clean, “green” program. It is also noted that large independent reviews toward the end of a program or just before a launch do not tend to add value or uncover problems early enough to make a difference.
In addition to IPAs at the beginning of each major program phase, the demonstrated best practice is for technically competent government representatives to be imbedded into the contractor’s development and mission support processes. These government representatives attend ERBs and other technical meetings and make their feelings known in real time. This allows the program to respond positively without causing a downstream disruption. The approach was used effectively by NASA on the Centaur program and again later with Atlas as a commercial program. Co-located Aerospace Corporation engineers have been shown to be equally effective representing the Air Force on EELV.
Even with imbedded government technical personnel, Air Force management needs insight into program progress and requires periodic reviews. During development and initial Y-vehicle operations, these formal program reviews typically occur quarterly. A standardized format, showing schedule, risk reduction, and cost status, plus identification of major accomplishments and problems, is normally used. The imbedded government technical advisors should also participate in these reviews and give their opinion to both the contractor and the Air Force on progress and problems.
During ongoing stable launch operations, the use of formal status and other reviews should be significantly reduced. To meet RBS rapid ground processing goals, a cultural change will be required. This will necessarily involve reevaluation of and significant revisions to the many launch readiness and range safety reviews currently required for expendable launch operations.
Different processes are suggested for approval of Requirements Changes and of Continuous Improvement Changes, as explained next.
220.127.116.11 Requirements Changes
The normal ECP approach should be used for Air Force-imposed or contractor-proposed changes to requirements. The formal ECP process serves as a brake on requirements creep and on the contractor’s proclivity to spend all the available dollars on a cost-plus development. ECPs are funded by government dollars that result from requirement changes or other changes that may help the contractor’s bottom line but provide little cost savings to the government.
18.104.22.168 Continuous Improvement Changes
ECPs are used on most government programs for all types of changes, which is ineffective for CI changes. In addition to identifying the technical need and cost of implementing the change, the ECP also must identify the expected benefit of making the change (reliability, performance improvement, operational improvement) and the expected cost savings. As discussed in Section 5.2.2, CI cost savings often involve quality issues associated with the “hidden factory,” which are impossible to quantify. The ECP seeks additional budget from the government
to fund the development and implementation cost associated with the change. This bureaucratic process takes an inordinate amount of time and often results in ECP rejection.
The recommended approach to facilitate CI is to provide budget within the contractor’s development and recurring budget for making changes without resorting to the ECP process. Imbedded government representatives should participate in the ERBs that assess and approve improvement changes and voice objections to both the contractor’s management and the Air Force, if necessary.
With the current emphasis on cost, the potential exists for the current EELV production monitoring conducted by the Defense Contract Administration Services at United Launch Alliance’s Decatur Manufacturing facility to become increasingly adversarial. Such a situation increases contractor costs, slows production, and results in demotivated production employees, which is not conducive to obtaining the highest quality launch vehicle hardware. The government is encouraged to find an imbedded oversight approach that works in cooperation with the contractor to identify and fix problems without resorting to excessive adversarial and bureaucratic reporting and resolution methods.
A very fundamental question to be addressed by the Air Force early in the program with regard to operations that will drive many design and fielding decisions is the following: Will the operational system be operated by military personnel with contractor support or by contractors with military oversight? Since the earliest days of the intercontinental ballistic missile program, those systems have been operated by the military. Some early space launch systems were operated by the military (e.g., Thor). However, for more than 40 years the government launch systems have been operated by contractors with NASA or Air Force oversight: the space shuttle, Atlas I, II, III, and V, Delta I, II, and IV, Titan III and IV, Pegasus, and Minotaur. Since an RBS capability could lead to much improved operability, it would be surprising if the Air Force did not consider using this program to transition to “blue suit” operations for this responsive and flexible segment of their launch capability. The discussion below is based on the assumption that at some level the Air Force will conduct RBS operations.
22.214.171.124 Air Force Operations
The Air Force, with a military and civilian mix, would conduct all operations required to process the RBS for launch, mate the payload, conduct the launch, recover the reusable portions of the system, and restore them to the condition where the RBS is ready to be processed for another launch.
126.96.36.199 Contractor Role
The contractor would maintain a “depot-level” repair capability to accomplish the maintenance tasks that are determined to be beyond the cost-effective level of military personnel that may have an average duty assignment of 3 to 4 years. This may be the same capability that would accomplish the major refurbishment of flight or ground systems when that is required. The contractor would maintain on-site technical staff to assist in anomaly resolution and other issues that might arise in pre-launch or post-recovery processing.
188.8.131.52 Concepts for Operations
The approach used for reusable portions of the RBS will have significant impact on cost and the availability of the underlying industrial base. At one end of the spectrum, all the fly-back-boosters anticipated for use over the lifetime of the system might be bought in a block, with considerable savings because of the quantity. However, this would almost certainly require a total restart of the production capability if a subsequent procurement was desired
many years later, with possible “new start” costs. A more sequential approach of delivering, perhaps, one vehicle per year would result in higher unit costs but would offer a much better opportunity for incremental improvements and continued production, as launch rates or other requirements dictate.
NASA conducted 135 space shuttle flights over 30 years, an average of 4.5 per year, with a fleet of 3 to 4 orbiters. Because of modifications and refurbishments, the “mission ready” fleet probably averaged fewer than three vehicles. While on average the orbiters flew a little more than once a year, the real use was probably more like two flights per year when the vehicle was operationally ready.
The RBS is intended to be much more reusable than the orbiters—perhaps 10 times more so. With an anticipated launch rate of about 10 per year, it seems like a vehicle fleet of four reusable flight sets, with each vehicle able to be flown from either launch base, would be sufficient to meet anticipated needs, continue operations after loss of a vehicle, and surge, if required. An open production line to replace any losses (and perhaps perform depot-level maintenance) would sustain the industrial base while providing a robust operational capability.
The committee believes that the initial RBS fleet size of eight vehicles (four at each coast) is too many. Based on the rationale presented in the preceding paragraph, an initial fleet size of four (three at CCAFS and one at VAFB) is likely sufficient, and this can be re-analyzed as the program moves toward production. This retained production capability and reduced initial fleet size is intended as an example approach that would help reduce the initial investment while maintaining program strength and flexibility.
184.108.40.206 Payload Capability
Developing a single launch vehicle to meet the full spectrum of payload delivery requirements has always been an unachievable goal. Families of vehicle elements have been fielded to meet a wide spread of requirements, but systems that are optimized for medium-class payloads are almost always far oversized for small payloads and require substantial change to meet the heaviest requirements. For example, Delta IV Heavy services a small, albeit extremely important, niche requirement. An Atlas V Heavy would need to be fielded to satisfy the same requirement with that family.
Although the Air Force may be required to meet the full spectrum of launch, the committee believes that burden should not be applied to the RBS. Specifically, the committee believes that the RBS would best be designed to meet the current EELV medium-lift requirement and not sized to accommodate the heavy-lift requirement. It is recommended that in constructing a phased development plan that the issues associated with the need for the RBS to satisfy the heavy-lift requirement be resolved prior to initiation of the development.
220.127.116.11 Commercial Use
A launch system that is as efficient as the RBS is intended to be very attractive to those wishing to provide access to space for commercial payloads. The Delta II, Atlas II, Titan III, and EELV systems did this through joint operations with the Air Force, with varying degrees of success. In most cases, government launches were conducted by contractor teams with government oversight, and commercial launches were conducted by contractor teams and contractor oversight. The potential commercial use of RBS could be addressed by the Air Force as it develops its operational concepts since, in the case of the RBS, the vehicles may be owned by the government, regardless of who does the hands-on operations.
The program described to the committee seems to presume a single contractor in each phase of the program: flyback demonstration (Pathfinder), engine development, RBS demonstrator, Y-vehicle prototypes, and production. The committee interprets this to mean that the contractor that does the engine development would continue into demonstration and production, and the RBD contractor would also build the Y-vehicles and the eventual production vehicles. While this is probably the lowest initial cost approach if all goes well, that benefit is achieved at the expense of both competition and alternative paths to mitigate risk. If RBS is successful, it will be the primary
launch system for the vast majority of national security payloads for decades. The most optimistic motivation to replace or supplement the RBS would be if the launch rates got sufficiently high that it was worth the investment to build a second system. A new space launch system could be introduced to take advantage of new technologies that could not be introduced as RBS improvements or if the RBS became so expensive that an alternative would be cost effective.
The caveat “if all goes well,” however, is not an insignificant consideration. Experience with aircraft programs suggests that when a fundamental change is desired (such as from fourth- to fifth-generation stealth) it has been beneficial to continue with two options well into the program, including flight test. With aircraft, there is a presumption that eventual production quantities make this continued competition cost-effective in the long run. Whether or not that has turned out to be true, there is little doubt that a better end unit was achieved than if a single contractor had been chosen based on paper designs and some component hardware. If the RBS flyback booster is the highest initial risk, the program should consider demonstrating it with two (or more) designs and take the best qualities determined from both, incorporating them into the demonstrator. This implies, as a minimum, two different Pathfinders with government ownership of all the resulting data. It would be beneficial if the same development and fly-off strategy be applied to the demonstrator vehicles for the same reasons.
In addition to a better technical outcome, a single Pathfinder that crashes, for whatever reason, early in flight test probably kills the program. A single Pathfinder that is unable to demonstrate the rocketback turnaround and RTLS maneuvers almost certainly kills the program, even if there was another approach that would have been successful but was not pursued because it did not appear better on paper.
The apparent program approach of single contractors may appear to be lower cost, especially in development, and therefore an easier “sell” for the initial investment, but it has far more technical and, in most cases, programmatic risk. It would be desirable for the RBS program to maintain competition as long as practicable to obtain and retain the “A-Team” from the contractors, foster innovation as each contractor strives to deliver the better product, sustain a larger industrial base for when reusable systems finally dominate the market, and achieve a lower life cycle cost.