Could you explain this point a bit more please? Is it because Mars has too much gravity with too little atmosphere or some other reason?
And your posts sound like an uncritical repetition of Musk’s claims of how requirements engineering is done. Even with a top-down requirements flow, trading requirements is crucial to the process, and trade study analysis is one of the key steps that is repeated as requirements are flown from top to bottom, and requirements are always subject to revision as a design approaches maturity and unexpected problems or growing mass budgets dictate changes. This is not something SpaceX created as some unique innovation; it’s an inherent part of every system requirements analysis process. If you have an existing capability that you want to build a system around, like a propulsion system, then you can perform bottom-up analysis (which is just as “old-school” as top down requirements flow, and arguably actually older given the reverse engineering of the V-2 that produced the Redstone and related families of rockets), but going through the requirement flows and assuring that there is not a gross mismatch is crucial to managing the design of a complex system across multiple functional groups and engineering disciplines.
SpaceX uses a looser process of trading “key design parameters” between functional design groups through informal (i.e. personal) interchange; this is also not new, and in fact is essentially how every company working in the early days of the rocket launch industry function. The problem with doing this is that you can paint yourself into a corner and have to engage in repeated system-level redesign, or worse, miss the impact of lower level requirements that have a system level impact affecting reliability or performance metrics. Both of these have occurred with SpaceX, particularly during the repeated failures of the Falcon 1 vehicle for reasons that should have been identified during requirements analysis, and later in Falcon 9 development, hence why there are actually three distinct generations of vehicles, even though SpaceX tries to pretend there aren’t by labeling them Falcon 9(v1.0), Falcon 9v1.1, and Falcon 9v1.1-Full Thrust, a pretense that fools no one.
This notion that SpaceX has some wholly unique process for doing engineering is a myth of their own creation; they are doing essentially the same things that new launch contractors have done since the dawn of the space age. As they’ve matured as a company they’ve adopted more formalized systems for tracing requirements (whatever they want to refer to them as) which has improved their ability to optimize system performance. They have some better tools for this, and perhaps more importantly, a singular focus that modern launch contractors who are run by finance people intent on maximizing contract value rather than optimizing launch capability for cost lack, but they haven’t discovered some genie in a bottle that no one has ever tried.
You are essentially correct. Mars has enough gravity that it can hold a relatively deep atmosphere which results in significant aeroheating and is problematic (from a mass budget perspective) to perform a propulsive landing as Apollo did on the moon, but the atmosphere is thin enough that above a certain mass it is not practical to use parachute decelerators to slow to subsonic speeds. The atmosphere also experiences seasonal variations in density which produces a lot of uncertainty and at times a large amount of suspended particles which could pose erosion problems to a decelerator heat shield. There are a few potential solutions to this as are presented in this presentation (slide 21 shows various architectures although the paper that discusses them is behind a AIAA firewall); the one that appears the most promising from a mass standpoint is an inflatable supersonic decelerator although the Low Density Supersonic Decelerator demonstration program ran into problems in its tests in 2014 and 2015. It’s not an unsolvable problem, but it is one of the biggest uncertainties in a crewed mission, and also one of the largest mass drivers.
And even if you had really inexpensive mass-to-LEO capability, the risks involved for a crewed landing would still dictate needing a solution that is technically mature and empirically demonstrated; spending hundreds of billions of dollars on a mission to send a crew to Mars, only for the landing vehicle to tumble out of control, overshoot its destination by hundreds of kilometers, or be damaged landing on a rock is unacceptable for obvious reasons, notwithstanding the tragedy of losing the crew to an error in judgement.
Stranger
I’ve never argued that these factors are completely exclusive to SpaceX. Just that they’re embracing them, now, and it’s working well for them. And that people that have worked for both NASA and SpaceX sense the difference in culture.
With respect to “early days”, I have no doubt that you’re right, and that this is one of the key answers to the question “how is it that SLS is such a clusterfuck given how quickly we sent men to the moon a half century ago”? Well, there are many reasons but one of them is that NASA was not so institutionally calcified back then.
There is nothing new under the sun, but there are many good ideas which were used once and slowly lost; identifying these and bringing them back is itself innovation.
This is not really here nor there, but Feynman argued in Appendix F of the Rogers Commission Report on the Challenger disaster that for engine design, the bottom-up approach is superior to top-down, and that the latter was the source of many difficult to fix defects. Whereas normally, one might start with the smallest components and put them through a heavy qualification process, and then testing them in increasingly larger subassemblies; the SSMEs started with the top-level design and let the requirements flow down from that. It turned even the smallest issue into a full-blown systems engineering problem.
Today, it’s easier to have a mixed approach. Computers allow for an easier parameterized design, so even if a change in one component has a cascading effect, it’s easier for the rest of the system to accommodate. SpaceX has indicated that for Raptor, scaling the engine is close to trivial (“trivial” is relative, of course), and can be tuned for the desired requirements even after most of the design is complete.
The thing that bothers me is that SpaceX has been saying that they are hoping for first flight tests of BFS next year. For that to happen, something of this scale would have to be well under construction. Which means the design would have been finalized long ago with maybe just minor alterations as you go.
But these aren’t minor changes - this is a whole new ship. If they are still at the stage where they are making radical changes to the ship design, its completion date is nowhere near 2019. More like 2023 or something. But it also means that they bet the company on something they don’t quite know how to build - or at least didn’t.
There’s just something off about this. It’s starting to take on the feel of a Hyperloop or Boring company project, rather than a serious well thought out development program that is through feasibility and design and is now turning wrenches.
I hope I’m wrong. Maybe Monday will make me feel better when we get more details.
Hops only. For a point of comparison, the first tests of the Falcon 9 reusability program were with the Grasshopper vehicle. Compare to the first operational landing of a Falcon 9. I don’t expect the test vehicle to look much like any of the final vehicle designs. It will have some Raptor engines, but probably not in the final configuration, and will have the full-size composite tanks, but the remainder will likely be the minimum necessary to perform the tests.
The Space Launch System isn’t a “clusterfuck” becuase of systems engineering methodology. It’s a mess because the high level requirements forced upon the system (by politicians) were not sensible or cost-effective, and because the timeline for development was hopelessly optimistic. In fact, it is an example of how the “bolt a bunch of existing hardware together and hope for the best” mentality of many low cost space advocates just doesn’t work. There are environemnt and performance requirement mismatches all over the place owing to the use of existing previously qualified compnonents that experience new environments and loads, and having to requalify or find a functional replacement has caused failures and increased cost and schedule.
Programs and contractors didn’t implement systems engineering because they became “calcified” or lost the secret sauce of innovation; they did so because they found that managing large multidisciplinary programs required more formal communication and documentation than could be done through casual communications. NASA in particular created and implemented systems engineering methodolify on Apollo because of problems on earlier programs like the Ranger lunar lander program amd experience on Mercury and the early years of Apollo when managing hundreds of contractors which were themselves dealing with thousands of suppliers was proving impossible to maintain clear cummunications.
Systems engineering is what made Apollo a success, and for all the problems that the Shuttle had it was what allowed such a complex and novel system to fly without a lot of incremental development. Systems engineering is not a panacea; you still need people with discipline knwoledge to perform trade studies and feasibility studies and do the actual analysis and simulation to verify requirements, which is often lost upon programs that make the system engineers to be the leaders rather than coordinators, and when contractors make requirement decisions to maximize revenue rather than to get the best product or the customer shifts requirements midway through the flow, you end up with bloated, unworkable designs like the F-35
I don’t think Feynman knew much if anything about systems engineering or engine design, and the problems with the SSME had as much to do with the political decision to split work by giving Rocketdyne the contract as long as they used a staged combustion design with Pratt & Whitney high pressure turbopumps. Rocketdyne actually designed and tested a gas generator cycle annular aerospike that would have offered better performance margins at substantially lower operating pressures, but was rejected because it gave no workshare to P&W.
There is this notion that “the computers” somehow design an engine or a vehicle, and you just throw parameters at it, give it a design goal, and it will fart out a completely detailed optimized design. This could not be farther from reality, particularly with a subsystem for which the design crosses so many disciplines as an engine or motor. Individual components can be optimized for specific goals, such as making a nozzle of a specific throat and exit plane diameter have an optimal shape and thickness for gas flow and heat exchange, but the interactions are so complex that performing some kind of all-up simulation of every pertinent phenomenon is just not viable or even useful given potential uncertainties in such analysis. Instead, you make bounding assumptions like a maximum heating rate based upon thermal capacity and mass flow rate, feed that into your thermostructural, ablation, and regenerative cooling analyses, and then build and test with good confidence that the analysis provides sufficient margin that if you’ve made some optimistic assumptions that it will survive rather than blow up and throw the schedule awry.
Doing parametric studies is fine at an upper level requirements analysis—and in fact is exactly what is done in those “old-school” systems engineering trade studies—but just doesn’t work at a detailed level with a substantial degree of complexity because there is no simulation tool in existance that can simulataneously simulate fluid flows, structural response, thermal response and heat transfer, et cetera, and trying to link a bunch of tools together with a multidisciplinary optimization tool is ofter more cumbersome than doing each analysis individually and feeding results from one to another.
It is very easy to talk with glibness about being able to tweak some design parameter and have “computers” rescale the design to fit; in practice is never works thst way except with straightforward analyses and pretty linear or trivial parameters. And I saw this having spent several years trying to get MDO systems to work in a seemless fashion; even when they do sort of work, a structures analyst or fluid dynamicist will inevitably examine results and find errors in the implicit assumptions or how an adaptive mesh was formulated the type of model used and throw the entire MDO in doubt.
Stranger
Thanks for the explanation and the truly fascinating link. I found this little aside on slide 14 a bit worrisome: “Without new technologies we have surface impact at Mach 2.5”. That and the insanely complicated mission profile at the start makes me less than willing to volunteer for a Mars mission.
A couple of nice pictures of the latest BFR design. That’s a damn fine looking rocket. Note that the booster is apparently missing its grid fins, but this was just a rendering mistake.
That sounds like the kind of thing that would be much easier to do in-house than when dealing with contractors and government agencies. Which is probably a big reason Musk sought to keep a lot of the production in-house. I don’t believe it would be particularly easy for, say, Boeing to ask Grumman if they could use a little of their SWAP leftovers in a fighter’s nose. In-house, the adjudication of competing interests can be done much more fluidly.
On Musk’s optimistic/delusional timeframes: Could they be a way of improving productivity? There’s a quote I’m about to screw up that says something like: “The time required to accomplish a task expands to fill the constraints provided”. We’ve all had times when we unproductively procrastinated on doing a faraway task* or slowed down as we realized that we were nearing the end of the task ahead of schedule.
Having very tight constraints can serve to focus attention and efforts even if you fall short. And sometimes falling short is ok**. For example, there have been times I aimed to do 40 reps of a particular exercise and that’s exactly what I did. At other times, I aimed to do 60 and ended up doing 50. I failed to reach my goal but I did more than if I’d aimed to do 40. Military training can work similarly: Drill instructors may want you to raise your arms 45 degrees but they know that if they ask for 45, you’ll eventually slink back to 30 so they ask for 90 knowing they’ll end up with 45.
That may be Musk’s worldview. There are times when not failing to reach a specific threshold is critical. E.g.: Jumping over a chasm, being able to support the weight of a building, defending a hill. But there are times where, the higher you aim and the harder you go at it, the better a place you’ll end up. If SpaceX stopped existing right now, how much would it have changed the space industry if others copy what it does best? How about the equivalent for Tesla?
- For example, by going on Internet forums.
**Yeah, I know! My gut also cannot fathom the notion but it’s true.
I think we’re talking past each other a bit. I’m including top-level requirements like “must use ATK’s solid boosters” as part of the systems engineering.
Granted, these high level requirements came from political expediency, not any kind of engineering decision. But in a more rational organization, that kind of choice would have been an engineering decision. When SpaceX chose methane for their BFR propellant, that was driven by their requirements for cost, tankage efficiency, Martian ISRU, and so on. One could disagree with their reasons but the decision nevertheless followed from them. When NASA chose hydrogen for the SLS, it was because they wanted the dollars to keep flowing to the old STS contractors.
I’m all for blaming the politicians, but it’s no longer possible to separate NASA from the politics. NASA is still filled with great engineers, but they’re embedded in an organization which doesn’t allow them to make good decisions. It’s a poisonous culture that I think tends to infect everything, pitting groups against each other and leading to a silo attitude.
Probably not, but he talked with a lot of people. His findings were a synthesis of what others said about the project. At any rate, he says nothing about why that approach was taken–indeed it may well have been politics again. He only notes that the approach made it more difficult to fix known issues than would otherwise be the case.
Perhaps you were just speaking generally here, but I wasn’t claiming that at all. Obviously this isn’t practical yet except perhaps at the most superficial level. I was speaking specifically of scaling a specific engine design (here, Raptor).
Well, you seem to be more negative here than SpaceX has been on the difficulty of scaling Raptor from the 1/3 size we last saw to full size. And I don’t just mean Musk; IIRC, Mueller has also commented on the relative ease of scaling Raptor.
Of course I’m not trying to imply here that it really is no more complicated than dialing a knob. Just that if you have a working system already, and a good model for how the various factors scale, then the changes needed to get the scaled model working is far less work than building it from scratch. And that it may well be easier to build both, learning lessons on the small model (where it’s cheaper and faster to iterate) and then applying those to the large one. It’s more expensive to iterate on the large one if you run into difficulties–which would certainly be the case for a completely new engine architecture.
Then again, you never know what you might encounter. The F-1 engine had well-known combustion instability problems during development. These were a direct result of having such a large combustion chamber, and the same problems led the Russians to pursue both large clusters of engines and multi-chamber single engines (like the RD-170). SpaceX may not encounter that specific problem, but there may be other instabilities or otherwise that surprise them.
Right. And even within the same organization, plain old physical proximity can make a huge difference. If you need to hash something out with another group, you grab a few people and head to a conference room. It’s not the same over email, or if (horror) you aren’t supposed to talk to other engineers directly, and instead always go through their manager.
Musk has more or less said just that, in regards to both Tesla and SpaceX. The dates are “aspirational”. The only way they could be achieved is if everyone executes perfectly. That’s just not going to happen–some group is going to be the long pole. But as you say, work expands to fill the allotted time. So if you pad your estimates, you will still have groups taking longer than that.
I don’t think it’s necessarily procrastination at work (although that can be the case), but more that every task has an infinite amount of “polish” that can be put into it. You have to make some cutoff to limit the scope. Setting a tight deadline forces you to make hard choices between needs and wants.
And as you say, there is an element of “shoot for the stars, and hit the moon”. It’s better to fall short at an ambitious task than to exactly meet a weak goal. One shouldn’t set crazy, completely impossible goals, but going for a goal that’s a little beyond what you think you can do helps one focus.
I don’t think there will be a self-sustaining colony on Mars in Musk’s lifetime, but SpaceX’s focus on Mars has been a driver for everything they’ve achieved. They would not be where they are without that vision. Even if BFR just ends up being a cheap cargo hauler to LEO, it will still be an amazing vehicle.
This is completely wrong. The SLS configuration was not the result of any rigorous trade study analysis; it was a “realignment” of the Ares V development originally being developed for the cancelled Constellation program, as a response to the DIRECT proposal with the Jupiter-120 and Jupiter-232 (later -246) vehicles. The use of Shuttle-derived components was essentially dictated in order to get Congressional approval and in theory to save costs and schedule versus developing a completely new vehicle and infrastructure.
The intent behind DIRECT (which was developed by NASA engineers working on their own time) was straight reused of Shuttle-derived ground and flight systems with minimal modification in order to maintain continuity of heavy launch capability following the expected retirement of the STS. The Jupiter family was always intended to be an interim solution to bridge to a hypothetical future more capable launch system which leveraged on the demonstrated reliability of the 4-1/2 segment SRBs, Space Shuttle Main Engines, the RL-10 engine for the upper stage, and all of the ground support systems for transportation, assembly and integration, and propellant loading, et cetera. It was not any attempt to get the most optimal or lowest cost system but one that could be made ready to fly within as short a window as possible with a minimally modified center propellant tank (thrust structure and reinforcements essentially just tacked on to the existing External Tank structure).
The SLS was largely just a rebranding of the Ares V, using a 5-1/2 segment SRB (not previously flown), modified SSMEs, a highly modified center tank structure, and a number of other changes that required substantial modification to ground support and assembly equipment as well as manufacturing tooling and complete requalification of many systems like the engine controllers give the environments they are exposed to. The single benefit is crew-qualifying the SLS so that the separate Ares I was not required for crewed flights, but given the amount of changes the estimated reliability was significantly lower than what the Jupiter family was assessed at.
I don’t know what, if any, direct experience you have working with any of the NASA centers, but while they certainly have some cultural problems with being a large bureaucracy that with the politics that go along with centers competing for programs and budgets, calling it “poisonous” is ill-informed and disingeneous. NASA has also launched numerous planetary exploration, orbiting solar and stellar observatories, and along with the NOAA has developed and maintained the most comprehensive set Earth observation satellites, many of which have operated long past their planned mission lifetimes. Your posts read like fannish adoration of all things SpaceX and Elon Musk which necessitate obligatory bashing of NASA based upon third-hand information that comes from message boards and Space.com.
NASA has a lot of problems as you would expect from any large organization without a clear mission and often amorphous leadership, but this is not an indictment of systems engineering as a process or the ability of NASA to perform system engineering processes with useful result in absence of political pressures to do otherwise, nor the ability to execute extremely difficult missions such as the Mars Science Laboratory, the New Horizons misison, or the Great Observatories orbiting telescopes, and of course the Gemini and Apollo programs.
This is the way a small organization working on projects with a limited scope and engineering disciplines function. It is not the way any organization building a complex launch vehicle with multi-disciplinary analyses functions, and that includes SpaceX despite the misapprehensions in your posts. SpaceX has formal systems for documenting and tracking requirements, performing sequential vehicle design and mission analyses, et cetera, just as any large launch vehicle contractor does.
I know how much SpaceX likes to taut their “flat management structure”, and it is true that unlike big conglomerates like Lockheed Martin, The Boeing Company, and Northrop Grumman they don’t have layers upon layers of vice presidents overseeing a wide array of defense programs, but at the functional level they aren’t significantly different from any other launch contractor save that the commercial nature of their contracts don’t require formal interfaces with an external mission assurance contractor (for most missions). SpaceX is still a maturing company that is privately owned, and thus has some flexibility that the more established contractors lack but as they’ve grown they have been developing the same kind of structures and systems (albeit streamlined by starting with online documentation instead of keeping reams of paper documents for work procedures and test plans) and has gone through a lot of growing pains that have resulted in several avoidable failures. SpaceX is not some kind of golden unicorn that has discovered a magical process that no one else has ever conceived of, and their ultimate goals and meeting profitability and cost reduction through reuse has not been quantifiably demonstrated.
Stranger
Presentation starting in a few minutes.
He speaks very awkwardly. I am surprised.
Ha. This is actually well above average for Musk (he does better when presenting purely technical stuff). No one ever accused him of being a smooth public speaker…
He sounds like a homeless person hired off the street, and not even given cue cards. How can someone that stupid sounding make so much money?
Because the kind of people that invest in his businesses care more about technical competence than public speaking ability.
That actually made me laugh out loud.
Why?
Because real CEO’s don’t cause the price of the stock to fall after giving interviews while high. When he runs out of fanboy investors he’s stuck with reality. Reality in the next 2 years will be a crap-ton of electric vehicles entering the market from established car makers who don’t get all flustered over paint.