Launch failures: payload separationby Wayne Eleazer
|
The spacecraft people tended to trust their own guidance hardware more than they did the booster’s, but in reality minor hiccups that would not be catastrophic on orbit were not so well tolerated during ascent. |
Although not employed now on US vehicles, an approach used for quite a few US Air Force Thor missions was the “dumb booster” concept. The Thor first stage had a control system capable of both keeping the vehicle stable and making trajectory adjustments but had no way of determining position or velocity errors; in essence it had no true guidance. The Thor control system was fed correction data and thrust termination commands from the upper stage or spacecraft guidance system, the same guidance system that would guide the rest of the vehicle after the Thor stage separated.
This approach was used on numerous Thor Agena vehicles as well as Defense Meteorological Satellite Program (DMSP) missions. For the DMSP Block 5D-1 launches, the spacecraft guidance computer itself provided guidance direction to both the Thor first stage and the second and third stage solid motor stages that were, in reality, part of the spacecraft system. For the earlier DMSP missions, the Burner solid motor upper stage provided guidance rather than the spacecraft itself. For both the Agena and Block 5D-1 Thor missions, the spacecraft itself issued the engine shutdown commands and fired the separation ordnance to jettison the fairing and separate/ignite the upper stages.
The dumb booster approach had the advantage of lower overall cost, since the Thor did not need its own guidance computer or inertial navigation unit, a couple of rather pricy items. It had the disadvantage of making anything other than a fairly large number of launches of the same type of payload rather difficult. Payloads without guidance systems could not be accommodated easily. When the Air Force shut down the Thor program in 1981, aside from the “Shuttle Only” edict, there were no suitable payloads around that could use the Thor, and none arose. The remaining four LV-2D’s and five SLV-2A’s were placed in storage and never flown, even after the STS-51L disaster forced a reversal of policies.
Aside from the “marketing” difficulties, the dumb booster approach was not without its mission assurance challenges. The spacecraft people tended to trust their own guidance hardware more than they did the booster’s, but in reality minor hiccups that would not be catastrophic on orbit were not so well tolerated during ascent. On the DMSP Thor Block 5D-1 mission F-2, a spacecraft guidance integration problem caused a reaction during the liftoff shock that led the vehicle to fly into the wrong inclination orbit. And the more complex electrical interfaces required were a factor in the DMSP Block 5D-1 mission F-5 failure (see “Launch failures: two Thors, one problem”, The Space Review, January 19, 2009)
A far more common approach is for the booster to use its own separate guidance system, enabling it to more easily accommodate a larger number of payloads. On the Titan IIIE missions, the Centaur upper stage provided the guidance system for the whole vehicle. It probably would have been easier to just use separate guidance systems for the Titan and Centaur: that approach could hardly have cost more, but for some reason they chose to use a single system. The approach was not duplicated on the later Titan IV Centaur vehicles, which used two separate guidance systems, one on the Titan and one on the Centaur.
When the booster has its own guidance system, the normal approach is to have the booster issue a separation signal to the payload via an electrical interface. The booster also issues a signal to fire the separation ordnance, such as explosive bolts that release a V-band camp that holds the spacecraft and booster upper stage together. In the case of spin-stabilized upper stages, such as the Payload Assist Module used on many Delta and one Atlas V vehicle, the booster also sends signals to spin up the upper stage and initiate the sequence to fire the rocket motor.
Some speculation regarding the Zuma mission focused on the fact that the payload adapter reportedly was built by the spacecraft contractor rather than the booster contactor, as is normally the case. But problems with such interfaces are rare. |
Booster-issued separation commands with a booster-provided payload separation system is most commonly used approach, but it is not without its problems. On March 14, 1990, a Commercial Titan III mission failed when the Intelsat VI F-3 spacecraft did not separate from the booster. The root of the problem was that the Titan was capable of carrying two such payloads and thus had two connectors to enable sequential release of the two spacecraft. But there was only one spacecraft on that flight, and it was hooked to the wrong connector during its installation on the booster. The booster never issued the separation command to the single payload.
Another different approach is for there to be no electrical interface between the booster and spacecraft. This was employed on TIROS NOAA and some DMSP missions launched on US Air Force Atlas E/F boosters. The TIROS payload was based on the DMSP Block 5D spacecraft and thus came equipped with its own guidance and built-in upper stage propulsion systems. Using the same basic software and guidance system that was used to guide the Thor booster, the TIROS and DMSP spacecraft could keep track of the booster’s trajectory and decide on its own when to separate and fire its rocket motor and thrusters to attain the final orbit. The spacecraft program offices asserted that no signal was needed from the Atlas and that the payload could even fire the separation ordnance. This offered the advantage of a simpler payload interface and thus a shorter processing time to respond to the call-up requirement that was an intrinsic feature of both the TIROS and DMSP programs. Unfortunately on the Atlas 19F NOAA-B mission of May 29, 1980, a booster performance dispersion led to the spacecraft attempting separation prior to the booster completing its burn, resulting in a mission failure (see “Launch failures: engine out”, The Space Review, December 31, 2012).
On the Pegasus XL mission of November 4, 1996, structural failure of a battery on the booster occurred. The battery was to provide power to initiate payload separation, and its failure led to one of the spacecraft on the rocket never activating and the other failing to separate from the booster.
On the Titan IV mission of April 9, 1999, the Inertial Upper Stage upper and lower stages failed to separate properly due to an insulating wrap over the staging connectors. While the IUS second stage fired, the added mass of the IUS first stage and the failure to deploy the IUS second stage nozzle properly led to the Defense Support Program payload separating from the IUS but being deployed into an elliptical orbit rather than the desired geosynchronous orbit.
There have also been a few failures where the payload fairing failed to separate properly and that led to either an inability to separate the payload or the payload failing to attain orbit due to the added mass of the fairing.
Some speculation regarding the Zuma mission focused on the fact that the payload adapter reportedly was built by the spacecraft contractor rather than the booster contactor, as is normally the case. But problems with such interfaces are rare. There were some thoughts that the August 6, 1981, Atlas Centaur carrying a FLTSATCOM payload might have suffered from a poorly designed interface, but investigations showed that the most likely cause of damage to the spacecraft that occurred was due to the fiberglass payload fairing collapsing inward.
Such failures can be due to a booster failure, payload failure, or simply an inadequate integration process. And such failures may not reflect upon any inherent deficiency in the space booster. |
The Space Shuttle was not without its payload separation problems. On the STS-51D mission, the Leasat 3 payload was to be deployed from the shuttle cargo bay. The approach used employed no electrical command interface to the spacecraft. Instead, when the payload and its upper stage were “flipped” out of the cargo bay, the action was supposed to activate a switch on the payload to initiate its ascent sequence. The switch operated in a manner similar to the way you would slide your hand across a light switch as you entered or left a room. But the switch was not activated during the deployment, and despite some innovative—and probably rather hazardous—experiments using a hand-made “flyswatter” and the shuttle manipulator arm, the shuttle crew was unable to activate it manually. A separate shuttle mission had to be flown to enable Leasat 3 to have an upper stage added to take it to the proper orbit.
Even when the payload does separate properly, it may be damaged by the process. On the Japanese N-1 mission of February 6, 1979, the payload made it to the proper orbit but the “yo” weights designed to make sure the third stage separated from the payload apparently struck the payload and knocked it out.
And in some cases we don’t ever really know what happened during payload separation, other than whatever happened was very bad. On July 20, 2001, the Cosmos-1 solar sail mission was launched on the first flight of a Volna, a converted submarine launched ballistic missile. The vehicle seemed to perform nominally, but the payload could not be located, either in orbit or on the ground. Following another failed Volna solar sail mission on June 21, 2005, due to an engine failure, the payload office decided that perhaps the Volna missions were not such a bargain. All four Volna missions ended in failure.
So, to summarize, failures to properly separate the payload are actually pretty rare compared to many other launch failure modes. Such failures can be due to a booster failure, payload failure, or simply an inadequate integration process. And such failures may not reflect upon any inherent deficiency in the space booster.