Rocketry is hard... And very unforgiving.
Rocketry is hard... And very unforgiving.
But if you look at the FT version, it's 1 for 8.
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.
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.
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.
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.
* 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.
> 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.
I've read his reference before and my reaction to his reply to me was "Yeah, that's right, too."
Yeah, they were really outsize personalities in every way (in a good way). Very unique time in American history.
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.
(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.
https://www.worldcat.org/title/industrial-accident-preventio...
Which I'd originally turned up ... through a NASA accidents presentation: http://www.hq.nasa.gov/office/codeq/accident/accident.pdf
Pre-launch was covered by a different policy.
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.
Respectfully submitted.
I wonder if there is a surgeon who's that skilled.
See "Liston's most famous case"...