[HN Gopher] Akin's Laws of Spacecraft Design
___________________________________________________________________
Akin's Laws of Spacecraft Design
Author : filiph
Score : 97 points
Date : 2023-08-09 09:45 UTC (13 hours ago)
(HTM) web link (spacecraft.ssl.umd.edu)
(TXT) w3m dump (spacecraft.ssl.umd.edu)
| karaterobot wrote:
| I have a subset of these printed out and tacked to a cork board
| in my office, and I refer to this website a few times a year.
| Very, very good stuff.
|
| This one in particular was a big influence on me when I moved
| from engineering to design. It expressed what I'd felt but hadn't
| put into words. Not just the look, but nearly every aspect of a
| project is _de facto_ path dependent, so you want to be as far
| upstream as possible. It 's also why I volunteer to write a lot
| of documents I'm not strictly responsible for:
|
| > 30. (von Tiesenhausen's Law of Engineering Design) If you want
| to have a maximum effect on the design of a new engineering
| system, learn to draw. Engineers always wind up designing the
| vehicle to look like the initial artist's concept.
| AnimalMuppet wrote:
| > 8. In nature, the optimum is almost always in the middle
| somewhere. Distrust assertions that the optimum is at an extreme
| point.
|
| This rings true in politics as well.
| firewolf34 wrote:
| More succinctly stated as "Only the Sith deal in absolutes."
| pdhborges wrote:
| Isn't a Pareto optimal solution always at the edge of the
| feasible space?
| GlenTheMachine wrote:
| Hi. I'm Henshaw of Rule 37. AMA.
| starkparker wrote:
| Who doesn't love grapplers?
| carabiner wrote:
| What work are you doing these days?
| Rebelgecko wrote:
| What's the backstory, was there a situation where you were the
| blamee (or the blamer?)
| mmaunder wrote:
| Thanks for the clear line of blame.
| aredox wrote:
| Well, you can tell us about the event/project that led you to
| coin that rule and how it panned out...
| xNeil wrote:
| What's a line of blame?
| innrautha wrote:
| I took it to mean clearly delineated responsibilities (i.e.
| who gets blamed when a part / aspect doesn't work).
|
| If there are unclear boundaries between responsibilities,
| things will fall through the gaps when one group assumes
| another will take care of something.
| firewolf34 wrote:
| Furthermore, when people are held responsible for quality
| completion of a task, they are often more driven to achieve
| the task at-quality. This must be balanced with not over-
| taxing them, but that's a given.
| e40 wrote:
| I take it to mean when blame is being aimed you are not in
| the line of fire.
| Eduard wrote:
| interesting - I understand it differently, namely as in:
|
| "at a project's beginning, define rules such as 'if
| component X explodes, it is team ABC's fault'".
|
| context:
|
| > 37. (Henshaw's Law) One key to success in a mission is
| establishing clear lines of blame.
| jameshart wrote:
| I don't feel like a field that has in its entire history only
| produced a handful of actual successful designs at all can
| possibly rate this kind of 'world weary cynicism' style of
| writing.
|
| Nobody has the experience or ability to be able to say 'trust me
| I've built a few spaceships, this is the hard won truth of how it
| is'. There are exactly _nine_ spacecraft that humans have ever
| flown in. Only the Mercury /Gemini/Apollo programs really
| accumulated any kind of experience and that experience was
| extremely specific to a particular place and time and
| organization.
|
| So sure, some general engineering truisms in here have the ring
| of wisdom to them and us non-spacecraft engineers can nod at them
| and quote them with the cachet they get from being associated
| with NASA.
|
| But 'trust me I have been teaching people to design spacecraft
| for decades' doesn't really count for much when during those
| decades no new spacecraft designs were actually getting made and
| launched.
| firewolf34 wrote:
| In Shute Norway's autobiography, _Slide Rule_ , he describes the
| design and construction of the
| [R100](https://en.m.wikipedia.org/wiki/R100), an airship of which
| he was one of the leading engineers.
|
| The R100 design was "competing" with the design for the R101;
| both design teams were simultaneously tasked with constructing a
| viable airship to make a long-range trip (in the case of R100,
| crossing the Atlantic in 78 hours, which was a remarkable
| achievement for the time). The difference was that the R101
| project was state-owned whereas the R100 was privately-owned.
|
| R101 crashed and burned in France, en route to India on 5th of
| October, 1930, likely due to structural issues damaging the
| airships gasbags, of which the only survivors were those lucky
| enough to be in the engine cars.
|
| In the autobiography, Norway describes how the difference in
| program management led to the disaster. There are a lot of
| factors that led to the crash, as you might imagine, but one of
| the points he makes is that the publically-owned project was not
| held to strict requirements in its design process. The privately-
| owned R101 had a strict contract that they needed to complete,
| with a tight budget to complete it. They had _constraints_.
| Whereas the public-sector project was allowed to continually
| revise their design as they went, making many successive rewrites
| and changes without much structure. In particular, they cut the
| ship in half and rebuilt it at one point in it 's development.
| And when they arrived at the end of their development cycle, they
| had no leeway to maneuver because they had a lot of public money
| wrapped up in the project, along with a lot of public visibility
| and responsibility, pressuring them into rushing the launch
| without complete trust in their design, and into terrible weather
| conditions.
|
| *13. Design is based on requirements. There's no justification
| for designing something one bit "better" than the requirements
| dictate.*
|
| Decide/envision your outcome, and set your constraints
| correspondingly early on in development, aligned with realistic
| expectations of resources, folks.
|
| To underline my point, here's a quote from the Wikipedia page.
|
| "Shortly before R101's flights in June 1930, the Cardington
| [R101] engineers tentatively suggested that the long flights to
| Canada and India might be postponed until 1931 on the grounds
| that neither of the two airships was fit to make a lengthy flight
| at their current developmental stage. The R100 team replied that
| their airship was perfectly capable of flying to Canada, _and
| that the Canadian flight was a part of their contract._ "
|
| R101 did not have a contractual obligation to meet, but did not
| want to outright state they needed more time, lest admit defeat.
| R100 had requirements that they needed to meet, which they were
| ready to meet, as they had them written from the start in clear.
| R100 launched successfully. R101 was forced to launch to compete
| before it was ready, due to this "spontaneous requirement". R101
| burned for it.
| freitzkriesler2 wrote:
| > 3. Design is an iterative process. The necessary number of
| iterations is one more than the number you have currently done.
| This is true at any point in time.
|
| I'm going to agilely build a space craft! /S
| carabiner wrote:
| Funny thing is SpaceX is known for applying Agile to its
| aerospace engineering workflows. Boeing etc. are much slower
| because they use waterfall.
| Balooga wrote:
| Oh, I'm pretty sure someone(s) manages a massive GANTT chart
| over on the SpaceX side.
| datadrivenangel wrote:
| It's the only way a spacecraft has ever really been built!
| avmich wrote:
| This is definitely the wisdom of ages, but some points do show
| some age. 39. (alternate formulation) The three
| keys to keeping a new human space program affordable and
| on schedule: 1) No new launch vehicles. 2)
| No new launch vehicles. 3) Whatever you do, don't
| develop any new launch vehicles.
|
| Recent SpaceX developments, Starship in particular, put some
| doubts on this one.
| idlewords wrote:
| Let's put this comment in the comment cellar for a few years,
| to fully develop the tannins, and then see how it has aged.
| Starship progress is a little ways away from proving this adage
| wrong.
| bryanlarsen wrote:
| It could be argued that Dragon has already proven this wrong.
| Falcon 9 was developed in the form it was specifically to
| launch Dragon. SpaceX's original next rocket was going to be
| a Falcon 5 until they got the Dragon contract from NASA. Yes,
| the original Dragon was a cargo vehicle rather than a human
| spaceflight vehicle, but both Falcon 9 and Dragon were
| developed with the intention of eventually human rating.
| inamberclad wrote:
| Both were late, and I wouldn't say that Falcon was built
| expressly for humans. It spent a decade proving itself
| before it flew with people. That's not a _new_ launch
| vehicle.
| bryanlarsen wrote:
| A decade is a short period of time by human-rated-
| spaceflight standards.
| hannasanarion wrote:
| So? Falcon wasn't a human spaceflight program during that
| time, and it was also over-schedule and over-budget
| anyway.
|
| The advice isn't "no new launch vehicles should ever be
| invented ever", it's "if you want your human spaceflight
| program to be on time and on budget, don't include a new
| launch vehicle in the plan"
| avmich wrote:
| > Both were late
|
| What was the "determined" date to have them ready? How do
| you know they were late? Judging by Elon's estimates?
|
| > I wouldn't say that Falcon was built expressly for
| humans
|
| You know of course that requirements for the rocket to
| launch people are different from the rocket to launch
| only cargo? There were cases when non-human-rated rocket
| became human rated (at least Proton), but these days it's
| better to plan ahead, like teams working on Arian-5 (and
| also Dream Chaser, not a rocket) do. I'd assume Flacon-9
| developed from the beginning in such a way so at least
| human-rating would be possible - if not built-in already.
|
| > It spent a decade proving itself before it flew with
| people. That's not a _new_ launch vehicle.
|
| I'd agree regarding Falcon-9. Starship is another story.
| inamberclad wrote:
| > What was the "determined" date to have them ready? How
| do you know they were late? Judging by Elon's estimates?
|
| Crew Dragon was approximately 3 years late, from the
| original planned launch date of 2017 to the actual date
| of 2020. Given that the contract for the missions were
| awarded in 2014, it's a miracle that things have
| proceeded at the pace they have.
|
| > You know of course that requirements for the rocket to
| launch people are different from the rocket to launch
| only cargo?
|
| I'm well aware of the differences. I work in this
| industry. That said, SpaceX made the wise decision to cut
| their teeth and prove their design on cargo first. That's
| not a new launch vehicle by definition. They were
| launching rockets regularly for years before they put
| people on the pointy end. Most other human-rated rockets
| in recent history have _only_ launched humans. I'm
| neglecting older, converted ICBMs like Redstone and
| Titan. The only standout from this list is probably Soyuz
| (the R-7 derivative launch vehicle), which has been kept
| going through sheer inertia.
|
| > I'd agree regarding Falcon-9. Starship is another
| story.
|
| I suspect that Starship will be years behind schedule
| before it even launches cargo. I suspect that it will
| miss NASA's planned lunar landing date, but it won't be
| at fault because other parts of the program will suffer
| even worse schedule slips. I understand that people are
| hopeful that this really will revolutionize spaceflight,
| and I count myself in that group too! Reality has a way
| of intruding eventually though. I want SpaceX to build,
| fly, and trash as many unmanned Starships as it takes to
| make it reliable. That will cause some level of delay
| because they'll find something new in the testflights
| that will necessitate a redesign before it kills someone.
| dylan604 wrote:
| >I suspect that it will miss NASA's planned lunar landing
| date, but it won't be at fault because other parts of the
| program will suffer even worse schedule slips.
|
| Could you imagine if NASA mandated that SpaceX be the
| launch platform for Boeing's capsule?
| bryanlarsen wrote:
| Congress didn't pay SpaceX the agreed upon amounts for
| the first 3 years of the contract, and Crew Dragon was 3
| years late. Coincidence?
| Zandikar wrote:
| Err, what? Keyword there: "New".
|
| SpaceX still faces large costs and delays in developing new
| launch vehicles, including starship, which is delayed and
| unfinished btw, so no matter how you try to spin it, Starship
| is not (currently) a good example of SpaceX being an exception
| to the adage. Artermis 3 isn't exactly cheap afterall, and if
| you don't know what that is but know what Starship is, that
| proves the adage this one is refering to:
|
| > 39[a]. Any exploration program which "just happens" to
| include a new launch vehicle is, de facto, a launch vehicle
| program.
|
| The whole point of these two adages is that reusing an existing
| design is better than a new one. SpaceX's REUSABLE rockets are
| great for a number of reasons yes, but by definition, those are
| not NEW launch vehicles. And when they were new, well, lots of
| delays and setbacks and costs as they kept accidentallying
| rockets trying to land them. Not a slight against SpaceX btw,
| that's part of rocket science and innovation, but again, not
| cheap or quick.
|
| If anything, SpaceX's entire business model is EMBRACING that
| adage, not disproving it or an exception to it.
|
| EDIT: clarified
| avmich wrote:
| > The whole point of these two adages is that reusing an
| existing design is better than a new one.
|
| Yes, and that's put in doubt. Starship aims to improve on
| previous designs - in terms of affordability, that is, making
| human flights cheaper. This cheapness can't be realized with
| existing designs, so a new design becomes better in that
| regard.
|
| > SpaceX's REUSABLE rockets are great for a number of reasons
| yes, but by definition, those are not NEW launch vehicles.
|
| I don't know how good definition can exclude reusable rockets
| from being new. Was Shuttle ever new? Delta Clipper? Reusable
| Falcon-9? Falcon Heavy? I think this is not a good
| definition, if, according to it, reusable rockets can't be
| new.
|
| > And when they were new, well, lots of delays and setbacks
| and costs as they kept accidentallying rockets trying to land
| them.
|
| Do you know the difference between designing and using? In
| software it's rather clear, and nobody would expect a half-
| written program to function according to specs. Neither it's
| the case in aerospace - while Falcon reusability was being
| designed and tested, nobody should expect it to perform
| flawlessly as when used "in production". Not cheap, agree
| (actually, quite cheap by aerospace standards, but still not
| some typical household-sized money), but I'd argue that was
| rather quick - just a few years to put reusable first stage
| into production starting from announcing the idea and
| building the first "Grasshopper". So, while 39[a] may stand
| here, your comment doesn't provide a good justification to
| it.
|
| > If anything, SpaceX's entire business model is EMBRACING
| that adage, not disproving it or an exception to it.
|
| SpaceX benefited immensely from using proven solutions, but
| the results they are showing are still disproving the idea of
| this law. The ambitions of SpaceX are high compared to the
| rest of the world launching industry, but so are the results,
| and we also have genuine "firsts", like putting the reusable
| first stage into production, or flying reusable spacecrafts
| to space station, TKSes and Shuttles notwithstanding.
|
| Let me try to explain again my main point: SpaceX aims to
| make human spaceflight significantly cheaper, and the opinion
| is that it can't be done without radical redesign from
| scratch. It was attempted several times in the past, with
| e.g. Shuttle and Energiya, and it still isn't done today, but
| if you want to risk being put on the "you're currently here"
| list of SpaceX achievements(1), which were doubted and then
| happened, I'd at least propose you to think from the basic
| assumptions and find out why SpaceX won't actually achieve
| cheaper human spaceflight this time.
|
| (1) In Russian that list looked like this before reusable
| Falcon:
| https://meduza.io/impro/0ZWeCgCXA4nsWv7dj7CHbSIrsURgOh-
| qpiUh...
| singleshot_ wrote:
| > In software it's rather clear
|
| In software, I perceive there to be almost no separation
| whatsoever between design and use. I'm using windows 11
| right now, and sometime in the next few days it will
| silently download software patches that were designed over
| the last few days to address situations not considered in
| the original design of windows 11. Software goes back and
| forth from the design process to active use pretty much
| continuously these days.
|
| Just an alternate perspective to think about.
| Alupis wrote:
| None of this is put in doubt though. Your points about
| SpaceX's potential for future cost savings and efficiencies
| are hardly realized today - particularly when considering
| the length of time that has been spent without a capable
| manned vehicle. If, fast forward a decade or two and SpaceX
| is still using today's designs (albeit, upgraded) and
| actually realized massive savings - then we can talk.
| However, I'd bet they're going to re-design and build brand
| new models along the way...
|
| There's a reason military aircraft tend to have extreme
| service lives. It's far cheaper and effective to upgrade
| and refit/improve existing airframes with modern technology
| than it is to start from scratch - every single time.
|
| Look at the F-35 program. It's not exactly fair because the
| design goals are vastly different - but upgrading aging
| F-15's has kept them on the battlefield for 47 years[1],
| and today they're still a seriously potent air superiority
| fighter. The F-15's of today are only similar in shape to
| the originals, however.
|
| [1]
| https://en.wikipedia.org/wiki/McDonnell_Douglas_F-15_Eagle
| Swizec wrote:
| The "No new launch vehicles" adage reads to me as "Don't
| develop a new browser when you make a website"
|
| That doesn't mean we never need or want a new browser. It
| just means that developing a browser is a separate project
| and if your fancy websites requires a new browser, it is in
| fact a browser development project, not a website project.
| inamberclad wrote:
| That's still going to be late and over-budget.
| avmich wrote:
| Late comparing to what? Maybe SpaceX will not make it ready
| for NASA's return to the Moon flights as it was planned.
| However those dates don't look too serious to me - what's the
| justification for them? I suspect they were specified fully
| understanding they can easily slip right.
|
| Over-budget - what's the planned budget? I suspect Elon Musk
| himself doesn't have pre-approved specific budget to develop
| Starship, which makes sense, as e.g. it's rather hard to
| pinpont. As for the overall idea for how much Starship
| development would cost - how do you know it's missed already
| or going to be missed?
| [deleted]
| bryananderson wrote:
| Falcon 9 (plus Dragon) is the definitive counterexample. The
| jury on Starship remains out.
| avmich wrote:
| I'd consider development of Crew Dragon to be rather fast -
| because, in the condition of a private development, it wasn't
| done before. Comparing to other spacecraft developments, in
| late 1950-s there was a race, USA vs. USSR, to put a man in
| space "soonest", and it took Soviets ~3.5 years from the
| launch of the Sputnik to send Gagarin to orbit. So, just a
| few short years... and a large government backing.
|
| Still, given that Crew Dragon was developed by a private
| company and is quite modern judging by performance, I think
| it's a good result.
| dylan604 wrote:
| Compare the budget of SpaceX to NASA's up to and through
| Mercury. NASA's experience was one of something never
| having been done before compared to the experience of
| SpaceX seeing many others doing it just needing to tweak
| the formula to make it affordable. Also, without NASA's
| burden of being a government pork/jobs program rather than
| being a streamlined process
| vannevar wrote:
| Far from being a counterexample, Falcon 9 is a great example
| of the adage's truth. It flew for 10 years before being used
| for human missions.
| filiph wrote:
| I knew #36 and have used it in the context of software
| engineering. But much of the rest is similarly applicable.
|
| > #36 Any run-of-the-mill engineer can design something which is
| elegant. A good engineer designs systems to be efficient. A
| _great_ engineer designs them to be effective.
| belter wrote:
| Good rules, despite the page background choice going against
| rule 20: "...A good design with a bad presentation is doomed
| immediately..."
| Eduard wrote:
| how is this rule meaningful beyond platitude?
|
| "boss, I have finished the task. But this time, I activated
| _great engineer mode_ , hence the result is not only elegant,
| but efficient and effective."
| wmanley wrote:
| I think you've misunderstood the quote. The solution that the
| great engineer produces is effective, but may not be
| efficient nor elegant if it doesn't need to be. The point is
| that solving the problem (and maybe stopping there) is more
| important than producing something that is fast or beautiful
| that doesn't solve the problem.
|
| I think there's some overlap with:
|
| > 13. Design is based on requirements. There's no
| justification for designing something one bit "better" than
| the requirements dictate.
| dakr wrote:
| I take this progression to mean that the novice will design a
| part or subsystem that is good by itself. The more
| experienced engineer is thinking bigger by taking into
| account the effect of the larger design on the portion they
| are working on. The great engineer is thinking holistically
| and so also considers how the part affects the whole design.
|
| The same thing applies, I think, to anyone who works on a
| team. The beginner thinks of the problem by itself. The more
| experienced member thinks of how the system will influence
| what they are building or doing. The senior member will think
| about how the thing they are doing/building will in turn
| affect the whole (and weigh the consequences).
| moffkalast wrote:
| > 33. (Patton's Law of Program Planning) A good plan violently
| executed now is better than a perfect plan next week.
|
| Ah yes, unfortunately it's only halfway through the execution
| that you realize it wasn't a good plan, wasn't even an okay plan
| but a straight up terrible one.
| Razengan wrote:
| By the way, since you need to apply thrust from any direction to
| maneuver flexibly in 3D space (without wind or gravity), wouldn't
| spherical/disc(saucer) shaped spacecraft be the most efficient?
| dmbche wrote:
| The space between things in space is quite large, so you're
| going in a single direction for a while. The thrust from the
| spacecraft is also used to exploit gravitational energy
| (slingshoting around planets) for the most part, from my
| understanding.
|
| In Sci-fi, it's generally understood that very fast crafts
| (0.1c and up) will need to reverse and apply thrust opposite
| their direction to slow down for a very large part of the
| voyage (up to more than half) - so could be a good idea to be
| able to flip around and apply thrust the other way too.
| 0cf8612b2e1e wrote:
| Plus, without deflector shield voodoo, a skinny tube design
| minimize your cross sectional area and how much debris you
| will impact.
| icegreentea2 wrote:
| Only if instantaneous large accelerations in arbitrary
| directions is amongst your primary performance requirements.
| You'd need to have thrusters ready to fire in arbitrary
| directions as well. A spherical (specifically) spacecraft would
| also have more heat dissipation challenges.
| carabiner wrote:
| There are 1,000 other requirements that do not demand maximum
| 3D rotation efficiency.
| pdonis wrote:
| No. Such a craft would either need to have full thrust engines
| pointing in every possible direction (way too costly and
| overbuilt) or would have to have some way of rotating its full
| thrust engines to be at any arbitrary angle relative to the
| ship (which then means you have to transfer all the thrust
| through gimbal mounts or whatever you're using to be able to
| rotate the engines, and those things won't be able to withstand
| that kind of stress). It's much easier and simpler to point
| your full thrust engines in one direction (out the back of the
| ship), so the thrust gets transferred through the entire ship's
| fixed structure, and then have smaller thrusters to rotate the
| _ship_ to point in the direction you want to go.
| JoeAltmaier wrote:
| Number 13. Design is based on requirements. There's no
| justification for designing something one bit "better" than the
| requirements dictate.
|
| Isn't that the margin for error? I want to go up in a ship that's
| a little better than the absolute minimum.
| rahimnathwani wrote:
| Then specify that in the requirements.
| dylan604 wrote:
| >There's no justification for designing something one bit
| "better" than the requirements dictate.
|
| Are the Martian rovers outliers to this rule?
|
| >I want to go up in a ship that's a little better than the
| absolute minimum.
|
| This makes me think of the "this was built by the lowest
| bidding contractor" quote
| whats_a_quasar wrote:
| This is the only one I have reservations about. It is also part
| of the engineer's job to understand the customer, understand
| what they need, and negotiate the requirements (within reason).
| It's hard (impossible?) for the customer to fully design
| exactly what they need, and it works much better to the
| engineers to build something with continuous customer input
| than to build rigidly to a spec sheet
| firewolf34 wrote:
| You're describing the (albeit quite common) situation where
| requirements were not conclusive enough and need to be
| revised throughout lifetime of development, which can be
| natural as you begin to understand the problem space as you
| work within it. But the key is that the requirements should
| be as conclusive and accurate to resolving your problem as
| they possibly can be, at any given point in time.
|
| In the "frictionless environment, ideal world" scenario -
| requirements should always be completed as close to the
| letter as possible and no further.
|
| In the practical scenario, requirements should be _written_
| as close to perfect as can be achieved where perfect is
| defined as what is necessary to resolve your problem space,
| limited by your understanding of the problem space.
| firewolf34 wrote:
| Requirements set constraints which guide the development
| process. Without them set early on, you risk not understanding
| completely what you're setting out to do, you risk differing
| expectations/assumptions between members of your team, and you
| risk creep as the project goes on which means you will diverge
| from your intended outcome.
|
| In any project, resources (time, money, etc) are limited so the
| most successful project will be one that uses resources most
| efficiently. So good explicit requirements _allow you_ to
| determine the most efficient manner to achieve them as they
| codeify the problem and give you goalposts to optimize within.
|
| This all _relies_ on you being able to set good requirements
| from the outset, which can be done by _understanding_ what you
| 're setting out to achieve (the problem you're trying to
| solve).
|
| I have a comment in this thread which discusses the
| consequences of this rule specifically.
| https://news.ycombinator.com/item?id=37069168
| imoreno wrote:
| Margin of error should be calculated at the design stage, not
| as an afterthought during implementation.
___________________________________________________________________
(page generated 2023-08-09 23:00 UTC)