What I think mjessick is saying is you just de-optimize the transfer orbit changes to "waste" the excess delta-V provided by the solid motor.
That is a good, very succinct, way to put it.
My solution would have been to add ballast mass to the upper stage. That would work, wouldn't it?
The problem with adding weight in practice is that affects both stages, and most importantly the first stage launcher somewhat also (shuttle or Titan for IUS missions.) In practice, the missions are designed in series if at all possible to isolate the upper stage design from the launch trajectory. The launcher keeps margin to get to the agreed deployment state, the upper stage then corrects any dispersions and uses its own margin to do the same so the payload gets exactly where it wants to no matter where in the 60 day launch window, or which orbit rev deployment happened, or whether the stack was deployed from the shuttle on the first or second day, or...) This is to get all the design and analysis work done in the 2 years or so available by all the different disciplines and geographically separated groups required. Starting earlier runs into diminishing returns (wasted money) since there is then more chance for mission delays or something major to change.
If you were to try and change some ballast in the upper stage the only way it would work would be to stay just at some obsolete maximum margin point. Any change at all away from that point design and you are eating into propellant margin and increasing the chance that you will run out of RCS fuel to trim any stage 2 dispersions. This would result in the payload being deployed some m/s short of the desired orbit. It is worse than might be expected, because part of the guidance design using results from the flight controls group is to decide on conservative cutoff limits to leave enough RCS propellant margin for 3 sigma attitude control dispersions to complete the rest of the planned RCS attitude maneuvers after the end of the second RCS burn.
Edit: Since you need an adaptive algorithm to respond to changes as they happen to adjust the remaining trajectory, there wouldn't be much point to adding ballast. It would just eat into propellant margins. I think ballast might have been added if the payload were ever to come in far out-of-range light on mass, but it usually turns out the other way!
If the ballast isn't always right at the CG (which changes during burns anyway), this causes a change in the expected attitude control RCS usages (these are slow (back in the day) 6DOF runs: maybe 24 hours for 400 Monte-Carlo cases. Remember, these trajectories take 6-7 hours or so of simulated time) and this would then cause rework by the guidance designer if the RCS fuel expenditures during the various mission phases changed much.
For IUS MDL design, we did preliminary design, operational design, and final design phases.
Preliminary Design: 24 months before launch or so.
Show feasibility,
Determine basic guidance strategy: how will the Gamma Guidance algorithm be operated? Which set of the available constraints and control variables should be selected in each of the 8 or so guidance mission phases? Are there any software changes (non-data) required? (Almost never, although we added a large change that added tables of time dependent JPL designed targets used for all three planetary missions, and one very small mission specific guidance patch for Ulysses.)
Initial targets (Non-Linear Programming algorithm inital guesses) for expected payload mass and launcher trajectory (orbit and expected dispersions), and maybe a few other point cases.
This is mostly 3DOF work for guidance, IIRC. Because you didn't have the detailed vehicle and particular motor center of gravity changes available anyway to make it very useful to do 6DOF work.
(Mass properties changes during rocket burns
is one major real world annoyance that isn't simulated
much or not at all in Orbiter yet, I believe.
Gamma Guidance included a Kalman Filter and several
subsystems to adapt to conditions during the SRM burns.)
The guidance 3DOF and 6DOF simulations used a FORTRAN version of the real guidance algorithm. The attitude control simulation used fixed burn solutions no matter what the previous dispersions were (IIRC), but had more detailed payload modeling for flexible payloads.
Operational Design:
a much larger effort (perhaps up to a year, this is the big effort) that was intended to do detailed designs with whatever current information was available to cover the full expected range of values for every unsettled parameter. Uses generic parameters since what you are mainly concerned about is the box rather than the "nominal". IUS properties, launch trajectory, wide range of payload masses (particularly for payloads still under construction). For GEO missions, you might not know the final launch period precisely (e.g.: which months) so you might have to do the operational phase to cover the entire year of sun orientations, depending on how delicate the payload was.
Includes 6DOF work intended to cover the mission box to show feasibility and determine solutions for any possible forseen problems.
Final Design: 6 months before launch or so
Uses up-to-date data for the specific IUS vehicle, the assigned motors, all variable hardware items, the specific RCS tanks and load configuration, etc., and only tested for the agreed launch period. This phase may have to iterate if something critical changes (would be a big deal). This is a point design. Everything that might come up should have been considered during the large operational design phase and workarounds and methods decided ahead of time. There isn't much time at all to "turn the crank" and actually do the design. You are waiting for "final" certified input data to become available and then it is off to the races to get your part done and pass on your results to the next group waiting for it.
We used the best information available at that late date before launch when the software and data had to be finalized. Any changes after that point (launch dispersions, say an Abort to Orbit, or payload mass property changes) had to be handled by the onboard flight software
in flight. Flexible, configurable,
adaptive: Gamma Guidance! :thumbsup:
