A spacecraft storage architecture should begin with the data, not the memory device. Before selecting capacity or technology, designers need to understand how data will enter the system, where it will move, how it will be processed and how long it must remain onboard. That complete data lifecycle determines whether the storage architecture can support the mission under both normal and off-nominal conditions.

Follow the data through the system

An onboard computer may handle several types of data simultaneously: raw sensor inputs, working data, intermediate processing products, applications, models, software updates and completed results awaiting downlink. Each type has a different role. Raw data may need to remain available only until processing is complete. An application or model may remain onboard for the mission's duration but receive periodic updates. Processed results may need to be retained until the spacecraft establishes a reliable connection with the ground.

Designers should begin by asking:

• At what rate do the sensors generate data?

• Does that data arrive continuously or in bursts?

• How much must be available to the processor at one time?

• What can be discarded after processing?

• What must be retained, and for how long?

• How long might the system operate without a downlink?

• How much growth should be reserved for future workloads?

These questions establish the system's capacity requirement, but capacity is only one part of the architecture.

Evaluate how the storage must perform

The processor, interfaces and storage must move data at rates that support the intended workload. A device may offer enough total capacity but lack the access characteristics required by the system. A processor may be able to analyze a large dataset, but the architecture may not have enough local storage to stage it. Designers must therefore consider interface bandwidth, read and write performance, access patterns and endurance alongside capacity. Reliability requirements also shape the architecture. The system may need to protect critical data from corrupted writes, device failures or radiation effects. It may require redundancy, fault isolation or a recovery strategy for operations interrupted by a reset or power event. These requirements must then be balanced against size, weight, power and cost. Storage that meets the capacity requirement but exceeds the available board area or power budget does not meet the mission requirement.

Match the technology to the mission

Managed eMMC, raw NAND and radiation-hardened memory technologies offer different advantages. An eMMC device integrates NAND flash with a controller that handles functions such as error correction, bad-block management and address translation. The host requires a compatible interface and driver, but it does not manage the flash media directly. This can reduce controller development and storage-management work at the system level. Raw NAND may be appropriate when an architecture requires larger arrays, different performance characteristics or more control over how storage is managed. It also requires the system to provide the necessary controller functions, creating additional hardware, software and verification considerations. Radiation can point the design in another direction. A managed NAND device may suit a mission whose radiation requirements fall within its operating envelope. A more severe environment may require radiation-hardened MRAM or another technology, even if its capacity, power or cost profile differs. There is no universally superior approach. The right choice depends on the complete mission profile.

Design for more than the nominal case

A storage architecture should account for both expected operations and credible disruptions. What happens if a ground contact is missed? How much data accumulates if a communications link is unavailable longer than planned? Can the system continue processing, or does it have to stop collecting data? What information receives priority when available capacity becomes limited? The architecture should also provide appropriate margin for software growth and mission changes. The applications operating several years after launch may be larger or more capable than those available during hardware development. Frontgrade's 64 GB eMMC Managed NAND is one example of capacity evolving with those requirements. For a compatible system, it can provide more storage within the same package size as the existing 32 GB device, without requiring a fundamental change in how the host manages storage. The larger lesson is that a spacecraft's storage architecture should be derived from its complete data lifecycle: how quickly data arrives, how it is processed, how long it must remain onboard and what happens when normal communications are unavailable. Evaluating those requirements early helps ensure that storage supports the computing architecture instead of constraining it.