More Compute on Orbit Means More Data on Orbit

By David Meyouhas, President, Microelectronics, Frontgrade Technologies

Last year, at the National Defense Industrial Association’s Emerging Technologies for Defense conference, Gillian Bussey, the Space Force’s deputy chief science officer, laid out where she expects the real disruption in space to come from. She said it would come from technologies combining. One piece of that picture: “technology that allows us to store, transfer, sift through, analyze large amounts of data,” particularly on the satellites themselves, made possible by better microelectronics. She described satellites making assessments in orbit instead of sending everything down to a ground station in Denver to be processed.

Since then, computing in orbit has drawn real attention. Orbital computing had its own sessions at several of the industry’s major conferences this year, including SmallSat and SATShow, and it is on the agenda again at Silicon Valley Space Week next month. Several companies have asked the FCC for permission to launch entire constellations of orbiting data centers. And in April, the Government Accountability Office, Congress’s watchdog, published a primer on the technology.

It comes up often in our conversations with customers, too. But most of the public discussion focuses on processors and how to power and cool them. Storage comes up much less, and, in my experience, it is one of the first walls designers hit once a processor starts doing real work in orbit.

Processing More Data Means Storing More Data

The reason to process data on the spacecraft is simple. If a satellite can make sense of what its own sensors collect, it does not have to wait until it passes over a ground station to act on that information. It can also keep working when its connection to the ground is jammed or lost, and for defense missions that carries a lot of weight. What gets less airtime is what this does to the data on board. 

Processing in orbit means sending less data to the ground. It does not necessarily mean storing less. 

The spacecraft still has to hold raw sensor data while the software works through it, whatever intermediate data that processing produces, and the programs and updates that make it all run. It then has to hold the results until it can reach the ground. If that connection is intermittent, constrained or under attack, the data stays on board longer.

The Space Force has understood this challenge for years. In 2022, Lisa Costa, then its chief technology and innovation officer, noted that most satellites lacked the storage and computing power to run AI on board.

Storage requirements will continue to increase as missions become more complex. Think about the difference between a personal computer running Windows 95 in the 1990s and one operating today. Modern operating systems are larger. Applications are more capable and consume more storage. The amount and variety of data being created have grown enormously. The same basic progression is taking place in space: as spacecraft software, sensors and onboard processing become more sophisticated, the memory required to support them grows as well.

Storage is an Architecture Decision

For engineers designing a spacecraft, storage can initially look like a minor decision. Select a memory chip that meets the stated requirements and move on. The trouble starts when the mission’s data outgrows that chip. The usual fix is to add a bank of memory devices and a separate controller to manage them. That means more hardware, more room on the circuit board, more weight, more power and additional testing to prove that the complete design can survive in space—often after the team thought the architecture was finished.

There is a simpler option for the right mission. eMMC storage, the same basic type of managed memory long used in phones and tablets, combines the memory and the circuitry that manages it in a single device. Increase the capacity within that same footprint, and it can do more than hold the software and settings the spacecraft needs to operate. It can store mission data itself without forcing the team to redesign the system around a more complicated storage architecture.

That matters because the satellite payload architecture often needs to overprovision the needed memory to account for the on orbit data expansion expected over the course of the mission life. Some of the software it will run has not been written yet. Some of the data products it will create have not been defined. 

Being able to add capacity without moving to a fundamentally different storage architecture is valuable when planning around that uncertainty.

Match the Memory to the Mission

Of course, capacity is only one part of the decision. Customers are constantly trading size, weight, power and cost—SWaP-C—against radiation performance, reliability and mission life. As spacecraft designs become more flexible and development cycles move faster, teams must revisit those tradeoffs throughout the early architecture phase instead of treating memory as a fixed, stand-alone component choice.

The growth of proliferated constellations in low Earth orbit has also changed the radiation trade space. Historically, 100krad total-ionizing-dose performance addressed most missions. Today, demand from shorter-duration LEO applications can support parts with 30krad performance. That gives designers more freedom to select a higher-capacity, lower-power or more cost-effective devices when the mission does not require the radiation performance associated with longer-duration or higher-orbit environments. 

No single memory technology is right for every mission, however. 

Frontgrade offers multiple memory technologies to meet the requirements of shorter-duration LEO applications (eMMC) as well as longer duration, higher radiation missions (MRAM). The point is not to default to the most hardened device available. It is to match the storage technology, capacity and radiation performance to the mission’s actual requirements. No single memory technology is right for every mission, however. 

Building Room for the Mission to Evolve

That is the thinking behind our new 64 GB eMMC Managed NAND. It joins the 32 GB device we introduced in 2025 in the same-size package, allowing designers to select the capacity that fits the mission without changing the board footprint. What we have heard from customers is that the additional room matters across very different designs, from high-end onboard computing systems to compact single-board computers.

Very few memory devices can withstand the harsh environment experienced in space. Building a version that holds up in orbit is the hard part, and it is work we have been doing for a long time. Frontgrade technology has flown on satellites across low, medium and geostationary Earth orbits, as well as on deep-space and critical human-spaceflight missions.

Computing in orbit is going to keep growing, and it should. 

But the more a spacecraft can process, the more it has to hold. 

Storage capacity—and the architecture supporting it—becomes part of what the spacecraft can do.

My recommendation for the industry is simple: when determining what a spacecraft should be able to do with its data, put storage into the equation from the beginning. Evaluate capacity, radiation performance and SWaP-C alongside the processor before the architecture is locked in. The mission may change over time. A storage design built with that reality in mind gives the spacecraft more room to change with it.