Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Akin’s Laws of Spacecraft Design

spacecraft.ssl.umd.edu

Post reply on HN
Print view View original

81–90 of 159 posts

Re: Akin’s Laws of Spacecraft Design

#81

Post by johnwalkr »

JoeAltmaier wrote: post #37

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.

Good requirements include margins. In aerospace it's common to see[1] a system requirement that says "...shall supply a peak current of 1.0A for 1.0s", a general requirement somewhere else that says "...power supplies used for the purpose of X shall be designed to a margin of 1.5 for current and a margin of 2.0 for time", and a child of both that says "...shall supply a peak current of 1.5A for 2.0s, including margins".

That being said, I work in aerospace and if a company aims to meet the above requirements but maximimize or minimize some aspect, e.g. make a light/cheap/competitive product, how do you do that? There's always a few engineers that will die on the hill of "but there is no requirement for mass of this particular component" or "you said I should minimize mass but that's not a real requirement" (many organizations reject anything but "shall requirements" when it comes to formal review). TBC or TBD values can be used, but then it's difficult for everyone to understand if the value is a target or just something to be updated later. On the other hand, there's always a few engineers who will happily work for an extra year to optimize something way too much.

Sometimes a requirement is flat-out incompatible with another requirement, too. Requirements are so important but they are just a tool, and also sometimes require iteration. Number 38 goes in the right direction, but I would personally want to add "46. Sometimes requirements are wrong".

[1] These are simplified examples

Re: Akin’s Laws of Spacecraft Design

#82

Post by beckingz »

firewolf34 wrote: post #57
whats_a_quasar wrote: post #50

Earlier quoted context omitted.

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

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 "frictionles…

Except that requirements cost time to develop, so perfect requirements have significantly more cost than good enough requirements.

Also, requirements tend to evolve as customers grow, so requirements will change over time and become less perfect, causing that investment to depreciate.

Re: Akin’s Laws of Spacecraft Design

#83

Post by beckingz »

dclowd9901 wrote: post #68
dylan604 wrote: post #48

Earlier quoted context omitted.

>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

The rovers likely are completely on spec but simply because of all of their redundancies and tolerances designed as they are, they exceeded on-paper minimum expectations.

The specs were decreased so that "success" was extremely likely, because failure is career ending.

Re: Akin’s Laws of Spacecraft Design

#84

Post by tonyarkles »

visviva wrote: post #76
jameshart wrote: post #61

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/Apoll…

What makes you think this is limited to human-rated spacecraft?

Hell, I work in unmanned small autonomous aircraft and almost all of these apply to my day-to-day.

Re: Akin’s Laws of Spacecraft Design

#85

Post by jameshart »

visviva wrote: post #76
jameshart wrote: post #61

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/Apoll…

What makes you think this is limited to human-rated spacecraft?

The multiple references to human spaceflight?

Re: Akin’s Laws of Spacecraft Design

#86

Post by tonyarkles »

bryanlarsen wrote: post #28
inamberclad wrote: post #10

Earlier quoted context omitted.

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.

A decade is a short period of time by human-rated-spaceflight standards.

I mean… yes and no. The Apollo program started in 1961, had the first manned flight in 1968, and landed on the moon in 1969. Gemini started in 1961 and had two people in ‘65. Don’t get me wrong, I’m perpetually impressed by the things SpaceX is doing, but don’t let the fact that the rest of the industry has slowed down significantly convince you that SpaceX is moving faster than anyone ever has before.

Re: Akin’s Laws of Spacecraft Design

#87

Post by tonyarkles »

c_o_n_v_e_x wrote: post #67
whats_a_quasar wrote: post #50

Earlier quoted context omitted.

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

>and it works much better to the engineers to build something with continuous customer input than to build rigidly to a spec sheet Continuous input is a tried and true method of blowing out both budgets and timelines on building anything physical.. hardware, rockets, chemical plants, etc.

Working at a hardware company with a software company founder (which I’ve done multiple times now) can be a frustrating experience. People used to being able to casually say “hey I want to add this new feature” and getting “$40,000 and 12-week shipping delay” as a response are generally not happy. One project I worked on shipped board v2.17; the requirements were changing so quickly that we often needed to do significant board redesigns before we’d even sent the current design to the prototyping shop. It was… fun.

Re: Akin’s Laws of Spacecraft Design

#88

Post by tonyarkles »

beckingz wrote: post #82
firewolf34 wrote: post #57

Earlier quoted context omitted.

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 "frictionles…

Except that requirements cost time to develop, so perfect requirements have significantly more cost than good enough requirements. Also, requirements tend to evolve as customers grow, so requirements will change over time and become less perfect, causing that investment to depreciate.

I agree completely. In the physical goods world, though, it’s not a continuous function. At points along the way, there is a very clear cost step response. Requirements evolving is totally fine and expected, but you need to periodically say “The current set is good enough, let’s build it and ship it”. Trying to do continuous delivery on manufactured items is the road to madness.

My general approach to this is to try to reasonably anticipate things that could be coming down the pipe and, if possible, do the bare minimum to cheaply support the next prototype. As an example, if the product has a GPS receiver and a microcontroller and could conceivably need to do dual-receiver down the road, I’ll have a quick look for spare Tx/Rx pins on the microcontroller and just route those out to blank pads. Two benefits:

- when product management asks, we have a way to build a prototype using existing parts

- if there aren’t any spare pins to break out like that, I can raise it as a potential design red flag early. It’s not necessarily a show stopper, but it contributes situational awareness for when the next big step cost might show up down the road.

Re: Akin’s Laws of Spacecraft Design

#89

Post by tonyarkles »

dylan604 wrote: post #79
dclowd9901 wrote: post #68

Earlier quoted context omitted.

The rovers likely are completely on spec but simply because of all of their redundancies and tolerances designed as they are, they exceeded on-paper minimum expectations.

at this point though, if I was on a team that made a $newShinyToy for a space mission that did not "over perform" like this, I would personally feel shame and have a sense of failure if it only performed to the papers and end of mission came exactly when the paper said.

I wouldn’t go quite that far. Generally speaking aerospace margins are there for two reasons:

- To try to compensate for the worst-case situations

- To try to compensate for the unknown-unknowns

If you made a Mars rover that experienced a worst-case re-entry burn, got blown off-course during landing by larger-than-ever-measured surface winds, had your solar panel etched by dust in said surface winds, and completed 89 of the 90 day mission, you should still very much feel like you’ve succeeded AND you’ve provided incredibly valuable input data for the next iteration. We then refine our mental model of the Martian atmospheric conditions and revise the worst-case scenario specs for next time.

Re: Akin’s Laws of Spacecraft Design

#90

Post by tonyarkles »

Razengan wrote: post #13

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?

I think one of the most interesting things about space flight is how inflexibly your maneuvering actually is compared to how it’s portrayed in TV and film. As an example, in a given orbital altitude you cannot really speed up or slow down without changing your altitude. You can’t really move side to side at all without completely changing your orbital trajectory.
Post reply on HN