> They do the tests to validate that this rocket won't turn into a cruise missile, headed for the nearest residential area.
In that case the rocket has a flight-termination system, though, which should activate as soon as it veers too far outside the planned/expected parameters of the flight.
For more context, all (edit: American!) rockets for decades have had onboard self destruct systems and a "Range Safety Officer" on the ground whose entire job is to determine if and when to deploy this self destruct system.
The cruise missile scenario is highly unlikely as the rocket itself would be destroyed soon after leaving its intended trajectory.
> Like Russian vehicles, there is no flight termination system that receives ground commands onboard Chinese launch vehicles. Only US and ESA launch sites have such a system. Correction, Falcon 1 did not have such a system for launching on Kwaj.
Phlarp's original comment was about 'a "Range Safety Officer" on the ground whose entire job is to determine if and when to deploy this self destruct system.'
The text I quoted implies there is an onboard flight termination system, even if there is no Range Safety Officer who can send external commands.
FWIW, a part from an exploded rocket, like the engine, could still destroy a school bus filled with children. The odds are very hard to estimate, and made more complicated in that there are few failure modes where a rocket failure halfway across a continent, at supersonic speeds, would reach the ground without breaking long before.
Nit: flight termination system does not cause the rocket to magically vanish. It will still continue on its current trajectory and impact Earth somewhere. It just causes the rocket to stop thrusting and, IIRC, disperses the fuel/oxidizer so that we don't end up with large quantities of fuel/oxidizer in a small area on ground.
Indeed, all it does is break up the rocket. Depending on when it happens during the launch we might still end up with a fireball near the ground (unlikely to be near anything inhabited, though, as there's a lot of free space around launch sites) or with a quickly disintegrating rocket because it's already at high speeds.
There will still be debris, of course, but I guess the reasoning is that it's preferable to have relatively small debris, than one large piece of exploding debris.
Size of debris is not that important: lots of small pieces will cause a similar amount of damage as the same mass in a large piece.
Two important roles of flight termination are:
1. Cause the rocket to stop thrusting (and thus prevent it from thrusting out of range safety exclusion zone).
2. Cause the propellant tanks to be destroyed. This prevents the propellants from causing a large explosion on the ground (when the tanks hit the ground) in preference to a conflagration in the air.
Very often. Air Force range safety guidelines require a million dollar flight termination system and most of that cost is testing and quality control. I don't have an authoritative list of all flight terminations but it happens at least once every few years whenever a rocket fails to follow the set flight path.
I also have to suspect things like isolated, dedicated and redundant comm links with the flight termination system are part of these guidelines. Perhaps even a "dead man's switch" that terminates the flight if this separate communication system loses signal at some point. (Even if this means a costly false positive or two~)
For the Space Shuttle, the flight termination system had two huge 10KW transmitters to send the signal. That would get through despite damaged receiving antennas, noise, or jamming.
Less than the typical TV or FM broadcast tower, and remember there's a lot of empty space around the launch sites. Even ham radio operators in the US can run at 1.5kW peak.
As an example, the strut failure in the falcon 9 a while back didn't explode from the failure, that was the flight termination system that actually caused the fireball when things started going south.
There were no self-destruct systems on the shuttle orbiter, though there were on the solid rocket boosters and external fuel tank. They were used only once, on the Space Shuttle Challenger after the orbiter broke up, but the SRB's were still burning in an uncontrolled manner.
Don't worry, unlike the space shuttle, rockets have escape mechanisms. In that specific case, the astronauts would probably have survived as the emergency rocket thingies would have fired and evacuated them far from the explosion before it could reach the capsule.
This discussion reminds me of the failure of the first Ariane 5 launch. The flight-termination system was activate erroneously, and the payload was not insured. Ouch.
That's not what happened - the rocket went out of control due to a software bug allowed by over-reliance on unit testing, and was quite properly deliberately destroyed.
But yes, Cluster was run on the cheap, hence the use of the Ariane 5 test flight, and didn't have insurance.
"Over-reliance on unit testing"? I have a somewhat different read from the inquiry board report, which says it was a "systematic software design error." Yes, inadequate testing, and a belief the working code for Ariane 4 meant it was validated for Ariane 5 were certainly contributory, but I think it's unfair to single out an over-reliance on unit testing.
The board argues that there was a bias towards believing the software does not have an error. Thus, any out-of-range value is interpreted as a hardware error, which means the CPU should shut down.
There was a decision to not include Ariane 5 trajectory data in the SRI requirements and specification. Thus, while tests were rigorous at the equipment ("unit") level, and there were system tests, they didn't test that case. This is test design failure.
In addition, the board says "the review process was a contributory factor in the failure."
I can see how those can be aspects of "over-reliance on unit testing", but it doesn't explain, for example, how some of the variables from Ariane 4 were protected from overflow exceptions but others were not.
You have quite fairly picked me up on a cheeky exaggeration.
Lots of things had to go wrong to cause the Ariane 5 failure - including bad handling of overflow, as you mention. But to my mind, the universal last line of defence against any kind of mistake is an integration test: put all of the parts of the system together, feed them real input, and verify that you get correct output. Arianespace did not do that.
Well, until they actually launched it. It was a test flight, right? It proved to be an essential and very effective test.
If anyone's at all interested in risk analysis or robust software, it's totally worth finding a decent writeup on the Ariane 5 failure --- it's a fascinating postmortem in just how many unexpected little things together added up to a big boom.
Everything is incredibly obvious in hindsight, of course, but making things obvious is largely what hindsight is for.
And once you've finished reading that, go look up the Therac-25...
That means there was an under-reliance on system testing, which I agree with. It doesn't imply there was an over-reliance on unit testing any more than it implies there was an over-reliance on analysis or over-reliance on the expectation of developing bug-free software.
Oops, yeah I recalled that the subsystem that caused the problem didn't need to run after launch, so I was thinking it fed incorrect data to the auto-destruct system, not that it actually went off course.
In that case the rocket has a flight-termination system, though, which should activate as soon as it veers too far outside the planned/expected parameters of the flight.