Update on Starship Payload Capacity
Tim Cash
Tim Cash
Gary barnhard
| Order of Magnitude Reduction | Landed cost of 1 kg on the Moon | Launch System | Comments1,2,3,4 | ||
| 0 | X | = | $1,000,000 | Landed mass current cost datum | |
| 1 | X/10 | = | $100,000 | ||
| 2 | X/100 | = | $10,000 | ||
| 3 | X/1000 | = | $1,000 | Starship+Super Heavy (Tractable) | Probable
design inflection point: design for space then make it function vs. design for
function then space rate it |
| 4 | X/10000 | = | $100 | Starship+Super Heavy (Plausible) | <Nominal cost for a 1 kg delivery from the Continental US to Antarctica?> |
| 5 | X/100000 | = | $10 | Starship+Super Heavy (Aspirational) | Nominal
cost for a 1 kg delivery from the Continental US to Alaska |
| NOTES: | |||||
| 1 - Calculating the historical costs of going to the Moon (Apollo) is obscured if not overwhelmed by the technology development and infrastructure costs associated with the program. | |||||
| 2 - Calculating the current costs of landing on the Moon is complicated because it has not been done by the United States or a United States company since Apollo 17. | |||||
| 3 - The cost of the Astrobotics Peregrine mission is not a valid data point because it did not end up successfully landing. | |||||
| 4 - The cost of the Intuitive Machines IM-1 mission, assuming it lands successfully, will likely remain indeterminant since the actual breakout between reoccurring costs and the developmental cost burden has yet to be determined much less disclosed. | |||||
| XISP-Inc, Gary Barnhard, gary.b...@xisp-inc.com | |||||
President & CEO
k.a.c...@sympatico.ca
Gary;
You wrote:
> Probable design inflection point: design for space then make it function vs. design for function then space rate it
For the past few years, I’ve been designing low-cost equipment to operate on the lunar surface (a small science camera, and complete lunar rover systems), after spending the past >25 years designing low-cost LEO satellites, and low-cost deep-space missions (usually asteroid missions) --- i.e., all missions in the “Microspace” category (microsats, nanosats, cubesats).
It’s not so simple as “design for space” versus “design for function”. In the bad old days of the 1970s through 2000 (i.e., prior to the Microspace approach becoming well-established), there was *one* aspect of spacecraft design that fit that categorization: the specification of “EEE parts” (i.e., electrical, electronic, and electromechanical parts). In the Bigspace world starting in the 1960s, the low reliability of such parts forced space designers to use “space-rated” (“S-grade”) parts (or their military equivalent), which involved a whole system of designing parts specially for the space environment, then testing them (each and every one of them) to ensure compliance with requirements, then having a whole information infrastructure to keep track of problems with parts (on a lot level) and who was using them in what program, so that alerts could go out if a particular part from a particular batch had a problem. Very very expensive! Many Bigspace programs still use this approach.
My AMSAT buddies were pointing out in the 1990s that commercial parts had become *way* more reliable since the 1960s (for commercial reasons), and that most Commercial Off The Shelf (COTS) parts were just fine for space use. The Microspace approach involves using COST parts, then doing radiation testing (at the lot level, if possible) to check that any particular part isn’t going to fall over under the total ionizing dose needed for your mission (TID rates on the lunar surface being not much different from those in LEO, i.e., 1-2 kRad/year). All the satellites/lunar equipment I’ve worked on has followed this approach, which works well.
But for space operation in general, and lunar systems in particular, at the *system* level (not the EEE-part level) you absolutely must design for the thermal environment. Very few parts of a spacecraft are happy getting to a temperature above 60-70C (batteries need rather lower temperatures), or below -30C to -40C (batteries need warmer temperatures), even when not operating (many parts and equipment items have narrower *operating* temperature ranges). But without careful design, a satellite or spacecraft or lunar-surface system can end up outside those temperature ranges --- e.g., the lunar surface itself gets to +130C at local noon anywhere near the equator, and down to -220C at night. So, while you can usually do fine selecting COTS EEE *parts*(which are what give you the desired functionality), at the overall *system* level you have to design for space --- in particular, for the specific thermal situation that your specific space system is going to find itself in. And that in turn may well restrict your choice of EEE parts further than you would otherwise prefer.
- Kieran
To view this discussion on the web visit https://groups.google.com/d/msgid/power-satellite-economics/65CFEDFD020000160019688C%40gw2.barnhard.com.
Tim Cash
To view this discussion on the web visit https://groups.google.com/d/msgid/power-satellite-economics/02cb01da64c0%2481ce4b90%24856ae2b0%24%40sympatico.ca.
--
Tim Cash
Gary barnhard
President & CEO
k.a.c...@sympatico.ca
When I was a young engineer, I bought into the prevalent attitude (which was pushed by space agencies and their big contractors) that there was some sort of magic, some “secret sauce” associated with designing spacecraft; and I looked forward to being indoctrinated into those mysteries, to becoming part of the “space engineering priesthood.”
My career path took me into the Microspace world, where I found out that myth was rubbish. It turns out that the key to space engineering is the same as for *all* engineering: decide what your mission objective is, then capture that in a set of requirements, and a design that meets those requirements. In the Bigspace world that is mainly top-down (requirements first), in the Microspace world it is much more bottom-up (candidate design first), but in both cases you certainly have to account for the space environment, and in particular to overcome design reflexes that are based on terrestrial engineering solutions (e.g., in space, getting rid of heat is always a big problem, because there’s no air around you to dump heat into).
“Bigspace” became toxic by learning the wrong lessons from Apollo --- “failure is not an option” is one of those, if you misinterpret it (which all space agencies, the USAF and all the big space contractors did, from 1970 onwards, with only *some* walking back f that in recent years, thanks entirely to the persistent badgering from Microspace people). The Bigspace failure was in incorporating more and more requirements that weren’t actually necessary, in order to reduce more and more the *perceived risk* (not the *actual* risk) of any given program. This traces back to the fact that most space spending is by government agencies, and civil servants are highly incentivized to make sure that if anything goes wrong, it’s not seen as being their fault. Loading on more and more risk-aversion practices into every program gives them more and more things they can point to when something goes wrong, to “prove” that it wasn’t *their* fault --- “look, we required the contractor to carry out endless, tremendously expensive failure modes, effects and criticality analyses, to prove that the mission would have a 99.5% probability of success!” (This causing the actual cost of the program to inflate by 10x, causing it to be a financial failure right from the start, whether it subsequently “succeeded” or not --- yes Hubble and JWST, I’m talking about you.)
Norm Augustine’s book, “Augustine’s Laws” dissects many of the behaviours in government aerospace contracting that lead to these sorts of outcomes. Highly recommended!
Rick Fleeter’s books (The Logic of Microspace, and Micro Space Craft) outline a bunch of ways which those in the Microspace field found to avoid those sorts of outcomes. Highly recommended!
My buddy Peter and I wrote a paper in 2000 that summarized the “death spiral” that Bigspace had been trapped in for the previous several decades, and a few of the main points from Fleeter’s books (and from our AMSAT buddies’ experience and advice) showing how the Microspace approach gave us a way to step off the death-spiral, onto a virtuous cycle instead. You can find it here: https://www.researchgate.net/publication/264346445_The_Microsat_Way_in_Canada. 24 years old now, but the lessons haven’t aged…
- Kieran
Keith Henson
> (e.g., in space, getting rid of heat is always a big problem, because there’s no air around you to dump heat into).
Keith
To view this discussion on the web visit https://groups.google.com/d/msgid/power-satellite-economics/03f201da64ff%2404ab1550%240e013ff0%24%40sympatico.ca.