How NASA Brought the F-1 Rocket Engine Back To Life 221
First time accepted submitter Martin S. writes "How NASA Engineers have reverse engineered the F1 engine of a Saturn V launcher, because: 'every scrap of documentation produced during Project Apollo, including the design documents for the Saturn V and the F-1 engines, remains on file. If re-creating the F-1 engine were simply a matter of cribbing from some 1960s blueprints, NASA would have already done so.
A typical design document for something like the F-1, though, was produced under intense deadline pressure and lacked even the barest forms of computerized design aids. Such a document simply cannot tell the entire story of the hardware. Each F-1 engine was uniquely built by hand, and each has its own undocumented quirks. In addition, the design process used in the 1960s was necessarily iterative: engineers would design a component, fabricate it, test it, and see how it performed. Then they would modify the design, build the new version, and test it again. This would continue until the design was "good enough."'
iterative dev, no docs, took us to the moon... (Score:5, Insightful)
the design process used in the 1960s was necessarily iterative: engineers would design a component, fabricate it, test it, and see how it performed. Then they would modify the design, build the new version, and test it again. This would continue until the design was "good enough."'
take note modern IT managers - this is agile, not that bastardised process-heavy "agile" scrum-style crap you do today.
Re:iterative dev, no docs, took us to the moon... (Score:5, Insightful)
Every IT shop... (Score:5, Insightful)
Yes, if one is doing a one off project, or a prototype that will then be given to someone else to redesign, the perhaps this is the a good method.
Every mid to large sized IT shop I've ever seen or worked in (dozens) has basically been a "one-off project" when viewed as a whole. Yes sure, every one is basically built out of off-the-shelf hardware and OSes, but there is so much customization and scripting, customized apps and databases and communication software, and other various "glue" bits holding these microcosms all together, but after you examine the innards of any decent sized IT shop that's been running a while, the place as a whole is actually a giant hodge-podge Rube Goldberg contraption that has evolved and taken final shape over time and iterative development.
We've not building Henry Ford assembly line Model Ts here.
Re:Lacked the barest of computer aids? (Score:5, Insightful)
Compared to what we were doing at NASA in the 90s - much less by today's standards - the 60s really were lacking in the barest of computer aids. In hindsight, the assistance of computers was amazingly rudimentary. The ability to do structural analysis was being built "as they needed it" and independently in each group or center - NASTRAN, even in its earliest state, didn't exist yet. These are the people who started developing tools which didn't exist.
You have to remember - this was a time when Battin was using discrete math to plan missions, and a general n-body problem was considered unsolvable (and, afaik, still is in explicit form - but is trivial on modern computers for relevant values of n).
Re:Lacked the barest of computer aids? (Score:5, Insightful)
This flies in the face of at least history. It also flies in the face of the usual mythology that NASA invented the computer. Which is it?
I never heard that myth. But NASA and its contractors were pioneers in some CAD tech, like FEM (finite element modelling), and the computers for Apollo spacecraft designed at MIT/Lincoln labs were marvels of miniaturization for their day.
But by 1963 manufacturing, at least for the money-means-nothing military, was already computerized.
Maybe a tiny amount of it. Don't confuse NC (numerically controlled) with CNC (computer numerically controlled). NC was developed largely in the late 40's and was widely used by the 50's. It used relay logic and so forth. CNC was too expensive until "inexpensive" minicomputers came along later in the 60's, and didn't take off until micros came along in the 70's. The video probably shows a futuristic "we tried it who cares what it costs" type of setup, like Doug Engelbart's WIMP interfaces in the 60's. Good forward looking stuff, but not necessarily ubiquitous, even for NASA.
Re:Mentioned this last week (Score:5, Insightful)
Our God-given curiosity will force us to go there ourselves because in the final analysis, only man can fully evaluate the moon in terms understandable to other men.
-Gus Grissom
This was also proven in several instances where manual human intervention saved a mission when automated systems failed.
Before you counter, yes, there were also man-made mistakes that caused problems during a mission. (Example Lovell's mistake in Apollo 8, which he manually corrected, and then used the skill on Apollo 13 when he didn't make a mistake).
I'd also agree that sending the Mars automated rovers were the best first step, rather than jumping right to a manned landing.
I think the thing we must accept is that both manned and unmanned missions are useful and different in their abilities & goals. Calling one "better" is over-simplifying.
Best it was on paper, not computers (Score:5, Insightful)
A typical design document for something like the F-1, though, was produced under intense deadline pressure and lacked even the barest forms of computerized design aids.
Thank goodness for that. People still know how to read paper drawings. If it was computerized, we might be able to read the media if it survived (1/2" mag tape or punch cards) but would probably have to spend a lot of time reverse engineering obsolete CAD formats.
And how is this different than the F-35 JSF progra (Score:2, Insightful)
We constantly test, and call it good enough. The difference is the fighter is going to cost more than the Saturn missions...go figure.
Re:iterative dev, no docs, took us to the moon... (Score:5, Insightful)
Don't be brainwashed by all this "process" crap. These days you have to talk to guys in their 60's and 70's to get the full oral history, but they wistfully recall days when the emphasis was on getting things done and making them work, rather than mindlessly following "process". There were always procedures and so forth to keep documentation straight, but it was a means to an end instead of an end in itself. These days you get more brownie points for following process than you do for making things work. "Process" should be a way to get things done, not a fetish.
Nor was everything simple in the old days. For example, the B-29 project was hideously complex. If they'd injected modern "process" instead of making it work and writing ECO's, everyone west of the Mississippi would probably be speaking Japanese now.
Re:Mentioned this last week (Score:5, Insightful)
Except - this story reveals your claim to be bullshit. We have (literally) tons of documentation on how they did it, and that's just the beginning...
In some fantasy world where we had stopped rocketry and spaceflight development and operations... you'd be right. But here in the real world, we're still flying rockets, we're still developing engines, and electronics, and materials, and... well... pretty much everything required for a moon flight. (In fact, there's a lot of Apollo components that will never see the light of day again because they're obsolete... long since replaced with something better.)
One might as well complain about how nobody has built a Wright Flyer in over a century and how everyone who ever designed of flew one is dead.
(Seriously, how does drivel like this get modded "Insightful", when it's clueless bilge?)
Re:iterative dev, no docs, took us to the moon... (Score:4, Insightful)
The saturn V was not production, was only reliable with great effort, and with incredible highly skilled and trained people.
I agree with the majority of this sentence, save for the first section.
The Saturn V was launched ten times as part of a mission, which would make them all "production". That's a total of fifty F1 engines (5 per each first stage). If I'm not mistaken, two unmanned tests were scheduled; I cannot remember if it was tested on those after the engine became flight rated. With a usage window for the engine in production from 1968 to 1973 (Skylab).
I believe the OP was referring to the process to get the engine flight rated with all the nuances noted, which means his initial heads up to the managers of today accurate.
Re:iterative dev, no docs, took us to the moon... (Score:4, Insightful)
I one read an overview of the CMM levels, and what struck me was this:
At level one, it doesn't say the organization is hopeless, doomed to failure, it says "success depends on the skills of exceptional individuals"
The rest of the levels are built on a fantasy it could be otherwise.
Re:iterative dev, no docs, took us to the moon... (Score:4, Insightful)
"everyone west of the Mississippi would probably be speaking Japanese now"
Doubt it.
Don't be so skeptical. Ever work for a defense contractor? If the same approach was used in the 40's as today, the Arsenal of Democracy would still have been holding meetings while the invasion was underway.
That "process crap" is vitally important (Score:5, Insightful)
Don't be brainwashed by all this "process" crap. These days you have to talk to guys in their 60's and 70's to get the full oral history, but they wistfully recall days when the emphasis was on getting things done and making them work, rather than mindlessly following "process".
All that "process crap" is exactly how any successful engineering project is done. The space program in the 60's and 70's was no exception. Do some reading about the actual engineering that went on and you'll quickly realize it was ALL about developing working processes. A process is nothing more than a set of procedures used to accomplish a task. If the task has to be communicated to someone else or cannot be overlooked or is just plain complicated, documentation becomes a vital aspect of the process. You can't build something as complicated as a space ship without a huge amount of extremely robust processes and accompanying documenation. Developing effective production processes isn't mindless busywork - it is among the most challenging and important things we do. The best manufacturing companies spend a tremendous amount of resources on process development because without them they would be unable to function.
If you want to ensure that a rocket blows up, by all means ignore developing processes and don't worry about documenting or communicating the procedures used. Just be a cowboy and "get it done". When you have no way to discover what went wrong, who was responsible, when you were supposed to do it or how to do it again you might begin to understand why process is important. My company makes wire harnesses and we've made products that have gone into space. For even the simplest cable with a crimped terminal on one end we typically have about 15+ pages (and often much more) of assembly instructions, QA instructions, machine setup instructions, QA logs, shipping and packaging instructions, manufacturing orders (how many to build and when to build them), bills of material, training documentation, defect logs, packing slips, and invoices. And every bit of that documentation is genuinely important. Without robust processes in place it would be complete chaos to try to make even the most basic products, never mind something as complicated as a F1 engine. All that "process crap" lets us build a high quality product (repeatedly if needed), diagnose and correct any problems that may arise, and make sure everyone knows what they are supposed to do and when they are supposed to do it.
Re:iterative dev, no docs, took us to the moon... (Score:2, Insightful)
The saturn V was not production
There were 15 Saturn V rockets, with many spare parts.
was only reliable with great effort
There was not a single F1 engine failure.
and with incredible highly skilled and trained people.
Going to space is not monkey business. highly skilled personnel is also required to operate and service an Airbus A-320, and they have sold *thousands* of them.
Something one does not want to have to deal with when trying to make a profit.
Want to bet that the builders made a buck or two?