“Rapid and Complete Reusability ” of Rockets Won’t Be Enough
The rocket reusability race will come to a halt unless it considers integration time.
For years, we have heard companies talk about reducing the turnaround time of reusable rocket stages, but only recently has that conversation evolved to turnaround times on the order of days. However, a daily turnaround seems completely out of scope when the current payload build-integration timelines are upwards of 6–24 months. Once the current backlog of satellites and CubeSats are launched, this build-integration time will become the bottleneck of the space launch industry and will ensure an increased payload launch cost because weekly or daily reusability is no longer feasible. Let’s dive in.
Launching
There has recently been a huge surge in the rocket development sector, with more than $13 billion invested into startups since 2000. We have seen SpaceX, XCOR, Blue Origin, PLD Space and more innovate to ensure quicker launches through rocket reusability. This will indeed lower the launch cost/payload mass but relies on one major assumption: that there are enough post integration-ready payloads to launch on a regular basis.
According to an analysis done by CBInsights, there are currently more than 200 startups in the satellite development horizontal, working on space exploration, communication, tracking, and satellite constellation operation. They ensure the reusable market’s viability because they are creating thousands of different, innovative payloads to launch. However, building and preparing these payloads takes time, on the order of years. If launching could be done daily, which would subsequently result in all of these payloads being launched, the bottleneck is no longer the launch time, but rather the design, build, and build-integration time. To know more about the currently proposed satellites, visit: Commercial Space Transportation Forecast
Reusability Launch Mass Calculations
Even though each of these satellite development companies aim to create thousands of satellites, every single one of those companies will have to take each individual payload through an integration process that is ridden with massive lag time. This lag time will dramatically increase the supply of rockets even though demand would stay relatively constant, which ensures an increased payload launch cost because weekly or daily reusability is no longer feasible.
Many upcoming rocket launch companies have claimed rocket reusability is only cost effective if it is rapid. Now, let’s assume we have weekly reusability by seven major rocket companies. This would be 52 (launches a year) x 7 (companies) = 364 launches at an average of 22,000 kg per launch (using Falcon 9 to LEO mass): 364 x 22,000 = 8,000,000 kg per year.
Let us compare this to the total mass of payloads launched since 1957. Using a simple Python script to gather the mass of each spacecraft, courtesy of Skyrocket, we have only launched a total mass of 10,000,000 kg ( LEO, GEO, etc.) from 1957 to 2016! Reusability is definitely the optimal way to launch this mass, but we would either need the equivalent of 40 more years (at the past rate of development) worth of payloads ready each year to launch, or a dramatic reduction in the build-integration time by an order of magnitude, about 50 times faster that we launched payloads in the past.
Build and Integration
Satellites can range in mass because they contain all the way from 1000 kg+ payloads down to about 0.5 kg payloads. Even though one may think it would be harder to develop and launch a 1000 kg payload versus a 0.5kg payload, both are actually nearly identical in integration time necessary. This can be explained by all payloads facing very strict integration regulations and requirements regardless of mass.
We have reached out to industry experts to understand the integration process for larger payloads and we received answers that both made sense and shocked us.
What made sense? The larger the payload, the more a customer pays and thus has more of a direct connection with the launch provider. This ensures that a middleman, such as a payload integrator, is taken out of the equation. What shocked us? The integration timeline is at least 2 years for larger payloads. Each payload has to go through arduous procedures to show that it fits within the payload fairing, passes structural analysis and stiffness requirements, and supports coupled loads analysis. Beyond meeting build requirements, there is the physical integration event where a payload is delivered and integrated into a rocket, which requires traveling multiple times to the launch site before the six week delivery process even starts. In order to completely hand over a payload, a “group” must be formed — The Assembly Integration and Testing (AIT) group which is comprised of subsystem leads and employees of the launch provider to complete full integration, which can last multiple months.
Now, what about smaller payloads? With the reduction of payload and satellite size (i.e. the CubeSat model), companies, such as Spaceflight Services and NanoRacks, have emerged to help integrate payloads “easily” into a spacecraft. They provide a series of safety checks before a payload enters a rocket. Although they provide rocket launching companies ease of mind through simplified integration, they also increase the integration timeline by an order of magnitude due to numerous design checks and requirements. This very process would end up hurting a spaceflight company once the current backlog is cleared out because it adds more time lags in addition to the payload building time.
We are currently in the heat of this build-integration process with our organization’s microgravity payload, The Interstellar Microgravity Experiment (TIME) by STAC (Space Technologies at California — UC Berkeley.)
How does it work? We have a MONTHLY integration phone call to check the design of our payload and ensure all of our work is disclosed and understood by NanoRacks to meet their standards. We will be in this process for the next several months until our launch. During this process, not only will we have to communicate detailed reviews of what we are exactly doing, but we will also have to iterate our design to meet the standards set by NanoRacks and our launch provider.
This is not meant to disparage NanoRacks — they do an amazing job with the help and services they provide, but the process has led us to realize that this exhaustive process will be a major roadblock for future spaceflight. According to one CEO working in the industry, the current record from going from payload design to launch is ~7 months.
Potential Solutions — what can we do about this?
We have outlined a few solutions to start the conversation about the upcoming bottleneck in this industry, but in no way have started working on a solution.
Integration Automation —
Create a mechanism beyond standardizing the size of a Satellite as the CubeSat movement did. This would entail manufacturing plants specifically designed to build a custom satellite, much like the computer manufacturing process.
Fewer Payload Requirements —
Dramatically reducing the design constraints on a payload will help to some order of magnitude. Something to be worked on though for sure.
Single Safety Testing Platform —
Creating a system that puts a satellite through a standardized testing system for any rocket would help reduce human testing and design reviews.
Let’s take these new found problems and solve them to enable rapid launch reusability! We would love to hear your thoughts about these solutions and other solutions to expedite the build-integration process. Feel free to reach out to us or comment below with your thoughts!
— — — — — — — — — — — — — — — — — — — — — — — — — — — — — —
By Travis Brashears and Malhar Patel — Space Technologies at Cal (STAC) stac.berkeley.edu
Enjoy this article? Follow STAC on <LinkedIn, Facebook, Twitter, Website>.
Follow Travis Brashears on <Twitter, LinkedIn>.
Follow Malhar Patel on <Twitter, LinkedIn>.
Enjoy what you read? Share, like, and comment! All opinions expressed are our own and they do not reflect the opinions of any of of our other organizations. Have a question? Email execs@stac.berkeley.edu
