A Fleet Maintenance Paradigm for Satellite Servicing

The adoption of satellite servicing has been frustratingly slow. Nearly 20 years after DARPA’s Orbital Express¹ demonstrated many of the key technical capabilities for satellite servicing² one can still count the number of commercial satellite servicing missions on a single hand. While there are many reasons for the slow adoption, I believe one of the main reasons is that most spacecraft operators and developers believe that satellite servicing is not economically relevant for them. I believe that most of them are wrong in this opinion, but understandably so, because they’re viewing satellite servicing solely through the lens of bespoke, one-off missions.

The Bespoke Servicing Paradigm

Most satellite servicing missions, including human servicing ones like the Hubble servicing missions³, or the now-cancelled robotic RESTORE-L/OSAM-1 mission⁴, have used this paradigm. A satellite that needs help is identified, a one-off mission is planned around that, tools are designed, built, and tested to achieve the desired repairs/upgrades, the mission is launched and carried out, and usually that’s the end of it. Sometimes, after the primary mission, they’ll consider reusing the hardware for a secondary mission, like space probes who’ve completed their primary mission. But in most cases, under the bespoke mission paradigm, you’re building stuff for a single use. Because the hardware is complicated, and you’re working on expensive clients that demand high reliability, and the system is only used once, it tends to be ridiculously expensive, even if the results can be amazing⁵.

When you see $500M+ price-tags for many of these bespoke servicing missions, its easy to understand why people would say that isn’t relevant for their spacecraft. If you’ve ever thought “how could you possibly design, build, and launch a servicing mission cheaper than me just replacing one of my satellites”, you’re probably viewing servicing through this paradigm.

While mission costs for bespoke servicing missions are getting significantly more affordable, see for instance the $30M price-tag for Katalyst Space’s upcoming SWIFT rescue mission⁶, the important thing to realize is that this isn’t the only way to do servicing missions.

In fact, there is a spectrum of different servicing mission approaches or paradigms, ranging from the bespoke/one-off missions just described on one extreme, to multi-client opportunistic servicing, all the way to what I’d call a “fleet maintenance” paradigm on the other end of the spectrum.

The Multi-Client Opportunistic Servicing Paradigm

By multi-client opportunistic servicing, I mean the idea of servicing vehicles that are designed to serve a number of client spacecraft over the course of its lifetime, completing a service for one client, then moving on to the next one as soon as a new need arises.

This paradigm is still pretty broad, covering everything from non-refuelable jetpack vehicles like the Northrop Grumman MEVs⁷, to servicers meant to be replenished, upgraded, etc., over time, like the DARPA/Northrop Mission Robotics Vehicle⁸ and some of the refueling missions that the Space Force is funding Astroscale⁹, Northrop Grumman¹⁰, and others to develop. Servicers under this paradigm might be designed to service unprepared clients, or could be optimized for servicing client spacecraft that have been designed with servicing interfaces. In a way, you could think of this sort of being analogous to how tow-trucks or service vans work terrestrially. When your car breaks down, they don’t design a custom single-use vehicle to go fix or tow it, they send a multi-use vehicle that is going to bet used over and over again until it wears out.

Regardless of the details, the key benefit of this approach is that by having the servicing vehicle serve a number of clients, the vehicle’s design, manufacturing, and launch costs can be amortized over more missions, lowering the per-mission cost significantly. This is where the bulk of satellite servicing companies are currently focusing their efforts.

There are some challenges to this approach, because maneuvers from one satellite to another may take significant time and/or propellant, if they are not in the same plane. But there are some orbital regimes like the GEO arc, and some sun synchronous orbits where large numbers of assets are clustered in coplanar or nearly coplanar orbits, where this can potentially work. Because a servicer can potentially be reused single or double-digit times over its lifetime, the cost per servicing event for this paradigm can starts dropping into the low double- or single-digit millions, potentially even into the sub-$1M range for small servicers focused on prepared clients¹¹. This approach is affordable enough to start being relevant to a wide range of commercial, civil, and defense space assets, which is why we are starting to see more activity under this paradigm. But if you’re a constellation operator/developer, you’re probably still not convinced that servicing makes sense for your constellation.

The Fleet Maintenance Paradigm for Satellite Servicing

The opposite end of the spectrum from bespoke one-off servicing is what I call the Fleet Maintenance approach, which is a servicing approach specifically-focused on servicing constellations at a relevant price-point.

The Fleet Maintenance approach has the following key characteristics:

• Fleet Maintenance Servicers for a constellation are designed to sequentially visit each satellite in the constellation, on a regular cadence, one or more times over the course of the satellite’s planned lifetime. For a constellation satellite with a 5-6yr design lifetime¹², this could be annually, or every 2 or 3 years, depending on anticipated need.
• Fleet Maintenance strongly favors constellations with spacecraft designed and built with servicing interfaces — such as docking/grappling features, relative navigation aids, and especially refueling and modular payload/equipment ports. These interfaces make hardware upgrades and consumable replenishment easy and realistic, and if mass produced, the interfaces can be inexpensive. And if you’re planning to perform thousands of rendezvous events per year, having fiducials/fixtures that decrease your odds of accidents pays for itself rapidly.
• While it is possible to include customized care for specific spacecraft¹³, Fleet Maintenance is primarily focused on bulk actions that are applied uniformly across parts of the fleet. For instance, a bulk upgrade of satellites in a constellation that were launched with the 1st-generation, lower-performance optical inter-satellite link¹⁴, or a mid-life refueling that enabled you to design the spacecraft with smaller tanks so you could fit more vehicles onto a launcher for faster constellation build-out, etc.
• Because the trip time from one satellite to another is relatively small, and very consistent, this means that it is not unrealistic that each servicer could amortize its build/launch costs over hundreds or maybe even thousands¹⁵ of servicing events, potentially driving the per-service cost below $10k per servicing visit.

Fleet Management takes advantage of the fact that most satellite constellations are designed to operate in multiple planes in a small number of inclinations¹⁶. Maneuvering from one satellite to another within a LEO orbital plane can be relatively fast (hours to days), and very low delta-V¹⁷. While plane changes, if you brute force them, are very expensive, drifting between two planes in the same inclination can be achieved very affordably by raising or lowering your orbit and using differential nodal precession to drift between planes¹⁸.

Conclusions

While there are tons of nuances, variations on the theme, and additional details I can and hopefully will dig into in the future¹⁹, I wanted to get this initial concept out there for consideration. By enabling satellite servicing at price points that are clearly relevant and complementary to mass-produced megaconstellations, I hope this post can get constellation operators to take satellite servicing more seriously. There’s a reason why most capital equipment terrestrially uses some variation on a fleet maintenance approach, and it is my hope that we soon see that lesson applied in space as well.

1. https://en.wikipedia.org/wiki/Orbital_Express ↩︎
2. Orbital Express demonstrated scripted and autonomous rendezvous, capture/berthing, refueling, and robotic exchange of modular On-Orbit Replaceable Units (ORUs), including both batteries and computing modules. ↩︎
3. https://en.wikipedia.org/wiki/Hubble_Space_Telescope#Servicing_missions_and_new_instruments ↩︎
4. https://en.wikipedia.org/wiki/OSAM-1 ↩︎
5. If you notice the obvious economic similarities between bespoke servicing, expendable launch vehicles, and flagship science missions, kudos for paying attention. ↩︎
6. https://www.nasa.gov/news-release/nasa-awards-company-to-attempt-swift-spacecraft-orbit-boost/
   
   Part of the reason this mission is so affordable is that the spacecraft is a light modification of a demo mission that Katalyst was planning to fly anyway this year, that was a follow-on to a previous Quark servicer demo mission that was flown by Atomos before they were acquired by Katalyst. ↩︎
7. https://en.wikipedia.org/wiki/Mission_Extension_Vehicle as well as similar offerings being developed by Astroscale, Starfish Space, Katalyst Space, and many others. ↩︎
8. https://space.skyrocket.de/doc_sdat/mrv.htm ↩︎
9. https://www.astroscale-us.com/en/missions/provisioner-the-astroscale-us-refueler ↩︎
10. https://news.northropgrumman.com/satellites/northrop-grumman-selected-for-in-space-demonstration-of-refueling-technologies ↩︎
11. My former startup Altius Space Machines did an economics assessment of multi-client opportunistic servicing in LEO SSO under an AFRL SBIR Phase I effort (contract number: FA9453-19-P-0554), with the support of SpaceWorks Engineering. Probably something worth its own blog post in the future, but the key takeaway was that servicing prices could feasibly get down to $200-250k/service given a small, low-cost servicer, prepared clients, and enough missions to perform over the servicer’s lifetime. This was just a short 3-month study that was a tiny part of a $150k Phase I effort, so I’d love to revisit the analysis down the road with a more sophisticated approach, if I can find a grad student looking for a dissertation topic… ↩︎
12. From my experience, this has been the typical planned lifespan of megaconstellation satellites including Starlink, OneWeb, and Kuiper constellations. Though in practice, I wouldn’t be surprised if Eutelsat tries to keep their Gen 1 constellation operating beyond the initial design lifetime. It’s pretty common for constellation operators to stretch orbital lifetimes (see for instance the history of Iridium’s Gen 1). ↩︎
13. If, for instance, satellite diagnostics are indicating a specific component was starting to wear out prematurely and you would otherwise have to dispose of the satellite if you didn’t replace it. ↩︎
14. For instance, at the time of this writing, SpaceX has now deorbited most of its v1 Starlink satellites that had no optical links, but ~25% of their constellation is still v1.5 satellites with the earlier generation, lower bandwidth optical links. I don’t have details, but I wouldn’t be surprised if the bandwidth and performance of Starlink optical links hasn’t noticeably improved even across the v2 mini production run. I expect this will be common for most satellite constellations — over the multi-year course of building out a constellation, you’re almost certainly going to incrementally upgrade important hardware that you wish you could retrofit older spacecraft with rather than living with obsolete equipment for half of a satellite’s useful life. ↩︎
15. A six year servicer lifespan, with an average of one visit per day works out to ~2200 servicing visits over its lifetime. ↩︎
16. Take Starlink for example, in spite of having launched nearly 10,000 satellites, almost all of them are in just four orbital inclinations: 43, 53, 70, and 97.6deg. Most of those inclinations have dozens of planes with dozens of satellites each, but having only a handful of inclinations makes servicing easier. Some constellations like OneWeb and Iridium have all of their satellites in just a single orbital inclination (both 86.4deg). ↩︎
17. I’ve recently run the numbers for a small constellation, and will try to do a follow-on blog post at some point providing some quantitative numbers for a representative large constellation. But it’s surprisingly little delta-V to visit each satellite in a plane, especially if you aren’t in a rush. ↩︎
18. Because the earth rotates, it has an equatorial bulge. This bulge means that orbital planes slowly precess a few per day. But the precession rate is a function of inclination and orbital radius. So, if you change the radius of your servicer’s orbit, you will change the precession rate of the plane the servicer is in relative to the precession of the satellites in the constellation plane. You can use this to drift between planes — it can take a while depending on how many degrees apart the constellation’s planes are, but is very cheap compared to doing a brute-force plane change. As with the previous footnote, I’ll try to provide some quantitative examples in a future blog post. ↩︎
19. Potential nuances worth digging into in the future include: What sorts of things likely could benefit from modular upgrades? How much modularity do you need to take advantage of fleet maintenance? How many maintainers do you need for a constellation? What sort of propulsion should a maintainer use? Should a constellation developer try to add servicing in-house, acquire servicing capabilities, or just buy the services on the market? If you know you can count on regular servicing, what can that change about how you design a spacecraft in the first place? Do you go full Spacecraft of Theseus, and go for effectively immortal satellites, or do you still keep satellite lifetime relatively modest, and plan on a small number of visits over a lifetime? There are also the previously mentioned discussions mentioned in earlier footnotes about digging into the orbital dynamics of fleet maintenance and showing some quantitative numbers to back up my claims.
    ↩︎