DUKSUP was a high fidelity 3D performance and trajectory optimization code whose primary purpose was to access various technical matters surrounding how the launch vehicle flew. Although it could be used for broad, low fidelity mission studies for potential missions, DUKSUP was not built for (it nor was it easy to use for) such applications. The code produced data which was generally used in the following analysis areas: Performance, Trajectory Design, Launch Window, Range Safety, and Ground Tracking Station Coverage.
1. Performance Analysis
Performance analysis was the primary product of DUKSUP. Performance analysis meant quantifying how much spacecraft mass could be delivered to a particular orbit. Because DUKSUP could calculate vehicle performance to the same accuracy and precision (and arguably better) as the contractor, and doing so through a trajectory optimization algorithm which was fundamentally different from the contractors’, it provided NASA engineers and management confidence and certainty in this critical area of launch vehicle development, integration, and launch. This meant LeRC was not dependent on accepting the contractors’ analyses at face value. Further, government engineers frequently did analysis in advance of the contractor (sometimes before the business contract was in place), supporting NASA planning and guiding the subsequent contractor efforts to support launch.
The steps in performance analysis consisted of:
x modeling the launch vehicle operation through an input file
x modifying DUKSUP if necessary to accommodate the vehicle definition or the problem to be solved x performing the 3D run
x analyzing the results
x providing them to the contractor and payload user, deliberating on how to use the data x determining the next steps
The last two parts were done in the venue of the “Performance, Trajectory, and Guidance” (P,T,&G) working group, sometimes chaired by LeRC, other times co-chaired with the spacecraft center. It was this close collaboration and sharing of job responsibilities which was a real strength of the LeRC-approach to launch vehicle program management. It meant, among other things, that civil servants -- frequently those chairing and managing the technical work --- had firsthand experience in what they were managing.
Typical performance analyses applications included:
x Maintenance and verification of benchmark performance (see section X.B.), including interface control documents (ICD)
x Performance impacts of vehicle hardware modifications, flight operations changes, or anticipated hits x Performance partials (sensitivities to changes)
x Calculation of performance margins (Flight Performance Reserve (FPR), Launch Vehicle Contingency (LVC), and Launch Time Reserve (LTR)
x Assessment of contractor performance documents (i.e. the Horses, Ponies, & Colts) x Performance assessments of major reviews
x Launch support: Firing Tables, updates prior to day-of-launch updates, ADDJUST support x Post-flight assessments, including mission success satisfaction
x Maintenance of NASA’s official repository for all ELV data, including performance comparison models for launch vehicles, ELV reference library, DUKSUP, and ELV reference guide
x Feasibility assessments for future missions
x Data for the official performance commitment letter from LeRC Center Director to Mission Program Manager
Deserving of elaboration is the performance commitment letter of the last bulleted statement above. This letter was issued by the LeRC Center Director to the Program Manager of a new mission who had received Authority to Proceed. In it, a benchmark mission was specified (orbital elements, spacecraft weight, mission peculiar chargeable, launch date (if interplanetary), etc.). This was a guaranteed performance which LeRC provided the spacecraft project in the form of a signed letter by the LeRC Center Director. These DUKSUP-generated data were trusted by NASA Headquarters. Should the launch vehicle loose capability to the point where it could no longer perform to the value specified in the letter, it would be LeRC’s responsibility to spend whatever funding, accommodate whatever schedule (but still make the launch date), and provide the necessary people to satisfy what was defined in the letter. Further, it was LeRC’s policy to guarantee “3σ” (i.e. ~99.87%) performance to the spacecraft organization, unlike the increasingly common specification of “confidence levels” of programs today. This meant that a flight performance reserve (FPR) had to be calculated statistically from all known dispersion sources. Thus the performance commitment agreement LeRC entered into had major implications for the spacecraft mission, the launch vehicle contractor, and for the reputation of LeRC. A lot of effort was always placed on the DUKSUP analysis, which was at the center of this performance agreement, and the analysis was never wrong.
2. Trajectory Design
Intimately tied to performance analysis was trajectory design. Indeed, the trajectory optimization produced the performance data. As was discussed in Section VII, the trajectory DUKSUP designed satisfied all intermediate constraints, achieved the final orbit conditions, and maximized performance. Section X.C. discusses how DUKSUP was called upon to design trajectories which sometimes exceeded the contractors’ abilities. “Shooting matches” were sometimes performed where LeRC and contractors attempted to reconcile differing results, comparing trajectories (sometime phase by phase), in order to understand why different results were occurring. This helped find errors that one party might have made or potential advantages of the optimization which one party might not have noticed. Sometimes, overlooked constraints or misunderstandings between the user, contractor, and/or LeRC were discovered during the trajectory design analysis. Figure 24 is an excerpt from a DUKSUP trajectory output file for a Titan IV/Centaur trajectory to geostationary orbit.
3. Launch Window Analysis
The launch window can be a function of many things: sun lighting constraints, cooling constraints (eclipse), Earth relative orbit element satisfaction of experiment criteria, performance limitation (interplanetary target), and others. For a launch window constrained by performance, as was usually the case for interplanetary missions, numerous DUKSUP runs were used to generate the definition of the daily launch windows. Figure 25 is an example of an interplanetary launch window generated from DUKSUP output for the Cassini mission to Saturn via Titan IV/Centaur. 12 This meant running DUKSUP with varying hyperbolic targets (C3 and declination) for each day, and varying the right ascension to generate the window. Performance penalties were then generated. Launch window analysis typically specified fixed window time lengths (such as the amount of propellant excess (PE) needed for a “one hour window”) early in a missions’ design life. The process was then inverted closer to launch (how long each daily window could be based on whatever fixed PE was available).
4. Range Safety Analysis
The Range required trajectories (nominal and dispersed) and the impact of hardware locations (both nominally and due to failure) from launch through orbit insertion. DUKSUP could calculate some, though not all, of these trajectory-related data which were eventually incorporated into the Range Safety Data Package generated by the contractor. Ground tracks were calculated for the nominal ascent. Dispersed trajectories were not calculated, though they could be done if the modeling data were available. The instantaneous impact points (IIP) (the landing locations should thrust be terminated) of the vehicle were also calculated, though the error ellipses for jettisoned hardware were not. Figures 14-16 are examples of IIP traces generated from DUKSUP output for early ascent, African bulge flyby, and continental African overflight. DUKSUP was not used for the related trajectory analysis (steepest lateral, steepest ascent, etc., and the tumbling turns). All of this analysis was used to support requests for flight plan approval, hazard analysis, and day-of-launch Range Safety support.
5. Ground Tracking Station Coverage Analysis
Visibility by ground tracking stations worldwide during ascent and orbit was vitally important, particularly during mark events. DUKSUP calculated elevation and view angles from ground stations to the vehicle throughout the trajectory. Figure 26 is an example of ground tracking station elevation angles for the CRRES mission on Atlas/Centaur.13 Section VII.D. also discusses how the code could optimally constrain the trajectory to be within a specified angle to a specified tacking station. This data was used by the LeRC launch vehicle program to ensure that telemetric data could be available for capture. It was also available to user community should health assessment or uplink capability be required.
B. Benchmarking
Closely related to Section X.A.1. above is benchmarking of performance analysis. Although we used the capabilities of DUKSUP to provide management with the payload implications of imposing constraints and trajectory modifications to improve performance for specific missions, we also maintained what we called “benchmark” trajectories for each mission. These were used to readily track the payload impacts of launch vehicle changes. The benchmark trajectory was typically chosen to be representative of the mission at the time the benchmark was established. Inevitably, the real mission evolved over time, but the benchmark ground rules did not change. The stability of this benchmark trajectory allowed the engineers and management to track the impact of vehicle changes from a constant baseline. Otherwise, it would not have been possible to have a clear idea of the implications of the on-going vehicle changes, such as hardware weights, operational decisions, and vehicle improvements. Such changes were constantly a part of the life of an on-going launch vehicle project. In addition, we were always able to relate the implications of vehicle changes on the benchmark trajectory and payload to those on the current mission.