The first stage for this launch was brand new. They have not launched a reused stage yet (they just announced a contract with SES about such a launch).
1. What kind of insurance will be needed on a billion dollar NSA satellite? $100 million? $125 million? It's not so cheep anymore, and considering delays etc. It's not such a great deal anymore.
2. They probably should have a "stable" platform and a "beta" platform, with a discount offered for beta.
Unfortunately, the "move fast and break things" attitude doesn't work with rockets.
Well, the whole origin of rocketry was about moving fast and breaking things.
Less glib, I'm not so sure. In shed development, you spend a lot to make perfect things. Aston Martin or Rolls Royce are great examples of this. In factory development, you spend a lot to make perfect systems. I'd hold up Toyota or Honda as good examples.
I'm not an expert in SpaceX technology, but i thought their big supposed advantage was tons of automation. With bespoke development, it's tough to bring down the failure rate. you just keep testing and verifying more. With a defined system, you fix the system to avoid those errors.
There's obviously a spectrum, and SpaceX isn't that far out on the automation scale, but i do think that's the intention. If they can survive long enough to reap those benefits, their launches will be cheaper and more reliable. In the mean time, lots of cheap, risky, attempts are probably better for debugging than thinking real hard and building the perfect thing.
Insurance policies for rocket launches typically expect 1 in 10 rockets to blow up on the pad. ULA's 100% success rate is unusual for the industry. Elon and SpaceX are obviously shooting for higher reliability than the industry standard, but I don't think you should chalk this up to 'move fast and break things' causing substandard reliability.
> Unfortunately, the "move fast and break things" attitude doesn't work with rockets.
Rocket technology has never advanced without catastrophic failures. "Breaking things" is the only way forward with it. Rockets, of necessity, have to push designs to their limits, or they'll never lift off the pad.
I don't know if I agree. Aside from Challenger (I know -- a pretty big aside), what catastrophic launch failures were there with the Mercury, Gemini and Apollo program rockets? Or the Delta 2. And doesn't the old-fashion-can't-even-land-on-a barge Atlas 5 have a perfect launch and mission success record of 62 of 62?
It seems like building and launching a rocket that doesn't explode every 14th time is possible but its not cheap. The US has been doing it since the 60's. SpaceX may turn out to be OK for delivering Tang to the ISS, but let's let something else carry the Webb into orbit.
Apollo had 17 missions and at least four failures or near failures that come to mind:
* The Apollo 1 launch-pad fire, during a training session, using a 100% pressurised oxygen atomosphere. Three dead. Grissom, White, and Chaffee. I can list them from memory.
* Apollo 11 suffered a lunar lander computer crash in the final seconds before landing, was programmed to land on what would have been unsurvivable terrain, and had fewer than 30 seconds of fuel left when it finally touched down.
* Apollo 12 was struck by lightning as it left the launch pad, knocking out much of the electrical system, which had to be reset. Fortunately they built things robustly.
* Apollo 13 had an oxygen tank explode as it was en route to the moon. The mission was aborted, though orbital mechanics meant that the astronauts still had to orbit the Moon, then return to Earth.
Any of 11, 12, or 13 could have ended with fatalities. One scenario for the command module pilot (Michael Collins in Apollo 11) was, if needs be, to leave his two crew members on the lunar surface and to return to Earth alone.
Apollo 13 also came a few seconds away from blowing up during launch. The second stage center engine began a pogo oscillation that at its peak was vibrating the engine at 16Hz with an amplitude of about three inches. By luck, the intense vibration tripped a fuel sensor and caused the computer to shut the engine down just before it would have ripped the whole thing to pieces.
Eh, Apollo 11's difficulties were not a computer crash, but the computer throwing up repeated alarms saying "You are asking me to do to much, so I'm going to follow the rules you instilled in me about what tasks are vehicle critical and what tasks can be dropped." AKA the 1202 program alarm. Which happened because the rendezvous radar was left in the AUTO mode for descent, when it was only meant to be used for ascent.
It wasn't "You are asking me to do to much, so I'm going to follow the rules you instilled in me about what tasks are vehicle critical and what tasks can be dropped.", but "You are asking me to do to much, so I'm going to reboot". It also overcompensated throttle lag due to old documentation.
Your reference confirms the parent's interpretation as well as yours:
> During the braking phase, up to the time the landing radar locked onto the surface, the duty-cycle margin was over 15%. After the radar acquired, the extra computations involved in converting the body-referenced radar data to the navigation coordinate system lowered the margin to perhaps 13%. When a monitor display such as Verb 16 Noun 68 was added, the margin shrank again, to 10% or less. Buzz Aldrin was perceptive when he said after the second 1202 alarm, "It appears to come up when we have a 1668 up"[16].
> With a 10% margin and a 13% drain, the LGC simply did not have enough CPU time to perform all the functions that were required. Thanks to the flexibility of the Executive design — and quite unlike what would have happened with a boxcar structure — there was no collapse.
[...]
> Having a relatively low priority because of its size, SERVICER got last crack at the available computation time. With a negative time margin it was SERVICER that had not yet reached its conclusion when the next READACCS, running punctually, scheduled SERVICER again. Because it had not reached its end, the earlier SERVICER had not released its core set and VAC area — so the next time READACCS called FINDVAC to schedule SERVICER the Executive assigned a new core set and VAC area. That SERVICER also did not finish. After a short span of such operation the Executive exhausted its supply of core sets and/or VAC areas. When the next request was made the Executive, unable to comply, called BAILOUT with a 1201 or 1202 alarm code.
[...]
> The interesting effect of this train of events, during P63, was that the problem fixed itself. The software restart reconstructed only the most recent incarnation of the SERVICER job, and flushed the uncompleted SERVICER "stubs" that had accumulated. In addition, it terminated functions that had not been restart protected because they were not deemed critical — including the DELTAH monitor Verb 16 Noun 68. This is why, following the two alarms in P63, the display returned from Noun 68 to Noun 63.
[...]
> During P64 the situation was different. Added to the regular guidance equations was new processing that provided the capability to redesignate the landing site. With this addition, the essential software by itself left a duty-cycle margin of less than 10%. The alarms kept coming. There were three 1201 and 1202 alarms within 40 seconds. Each time, the software restart flushed the Executive queue but could not shed load.
> At MET 102:43:08, forestalling the next alarm, Armstrong switched the autopilot from AUTO to ATT HOLD mode, easing the computational burden, and then entered semi-manual mode P66, where the burden was still lighter. After 2 minutes and 20 seconds spent maneuvering in P66 without alarms, the LM landed.
Right. Like I said, no catastrophic launch failures.
They did build things robustly back when the US still had a manned space program. I wonder how well a SpaceX rocket would do if it was struck by lightning as it left the pad.
Then again, Apollo 11 couldn't land on a barge. However it could land on the moon with two humans on board and then take off again and return then safely to earth. 47 years ago.
There's a hierarchy of severity that's expected in industrial accidents, as I've recently learned running across a reference to the concept. The work was done a long time ago -- ~1930s - 1950s, and I think the earlier part of that period. It's used fairly heavily in the insurance industry still, from what I understand.
(I'm being a little vague because I can't immediately turn up that reference, I'll take a look for it.)
The upshot is that if you've got a base incident / accident / failure rate, you can predict with a fairly high degree of accuracy the likelihood of major accidents -- fatalities, major injuries, or catastrophic to plant and equipment.
(Now to see if I can find that.)
Here: H. W. Heinrich, Industrial accident prevention: a scientific approach (1959)
The publication date is later than I'd thought, but the data were collected much earlier -- 1931.
Fair enough. According to Wikipedia of the 26 Mercury program missions there were 6 pre 1962 Mercury program launch failures before the 6 successful manned missions. 5 of the 6 failures were test flights without payload.
Speaking of insurance: the type of insurance policy that was taken on this unfortunate payload would only kick in at launch (ignition). Test firing was not covered.
Be careful with that assumption: the standards for reliability and safety for crew-rated vs. uncrewed vehicles are very different. I've heard figures at around 10% hull-loss accident rates as expected for uncrewed, vs. an order of magnitude less for crew-rated. There's a very good reason that the pad had been cleared of personnel, and no one was injured in this launch. While spectacular, this explosion didn't inflate any body counts, because the risks were understood and well-managed. Spaceflight is hard, and people die, but we need to make sure we are comparing the same categories when we assess risk, reliability and cost. Trimming that 10% hull-loss rate down to 1% can be done, but probably not at anything like a cost that would make it commercially viable. The only other way to ensure reliability is the way commercial aviation did it: break enough vehicles (and lose enough people) that you understand the failure modes so well you can very nearly eliminate them.
A brain surgery can result in worse still: like, surgeon performs a surgery, makes some mistake, the patient is alive and gets up and goes home, but due to the surgical damage caused becomes a serial killer.
So, strictly speaking a brain surgery can also result in a body count that is greater than 1.
On a similar note, there's also the case of the leg amputation that killed 3 people: the patient (gangrene), the assistant (gangrene from fingers accidentally being amputated) and a spectator (from "fright").
Rocketry is hard... And very unforgiving.