Suggested Searches

Chapter Contents

Chapter Glossary

(AI/ML)Artificial Intelligence/Machine Learning
(ASICs)Application-specific Integrated Circuits
(CDH)Command and Data Handling
(ConOps)Concept of Operations
(CRAM)Chalcogenide RAM
(DDD)Displacement Damage Dose
(DRAM)Dynamic RAM
(EPS)Electrical Power System
(FERAM)Ferro-Electric RAM
(FPGAs)Field Programmable Gate Arrays
(FSW)Flight Software
(I/O)Input & Output
(LEO)Low-Earth Orbit
(MRAM)Magnetoresistive RAM
(OBC)Onboard Computer
(PCM)Phase Change Memory
(SDRs)Software-defined Radios
(SEEs)Single-event Effects
(SEL)Single-event Latch-up
(SEUs)Single-event Upsets
(SRAM)Static Random-Access Memory
(SSA)Small Spacecraft Avionics
(SWaP)Size, Weight, and Power
(SWaP-C)Size, Weight, Power, and Cost
(TID)Total Ionizing Dose

8.1 Introduction

Small Spacecraft Avionics (SSA) consist of all the electronic subsystems, components, instruments, and functional elements of the spacecraft platform, including the primary flight sub-elements Command and Data Handling (CDH) and Flight Software (FSW), as well as other critical flight subsystems such as Payload and Subsystems Avionics (PSA). All must be configurable into specific mission platforms, architectures, and protocols, and be governed by appropriate operations concepts, development environments, standards, and tools. The CDH and FSW are the brain and nervous system of the integrated avionics system, and generally provide command, control, communication, and data management interfaces with all other subsystems in some manner, whether in a direct point-to-point, distributed, integrated, or hybrid computing mode. The avionics system is essentially the foundation for all components and their functions integrated on the spacecraft. As the nature of the mission influences the avionics architecture design, there is a large degree of variability in avionics systems.

There are two major factors to consider for SmallSat avionics:

1. Spacecraft scale: a traditional spacecraft is a high-size, weight, power, and cost (SWaP-C), flagship system, so it’ll have a high-SWaP-C avionics system, typically to reduce risk and address higher reliability requirements. A SmallSat is a low-SWaP-C, miniature system, so it’ll have a low-SWaP-C avionics system. Typically, due to low cost, more risk is often tolerable, but nonetheless, enhancements can be applied to increase reliability. Individually, the avionics system scales with the spacecraft, however constellations of SmallSats can “match” the capabilities of a traditional spacecraft (using multiple cheap units versus one expensive unit).

2. Architecture design: the architecture design is not necessarily dependent on the scale of the spacecraft. In both traditional spacecraft and SmallSats, the avionics system can be either centralized or decentralized, simplex or fault-tolerant, and modular or monolithic. Traditional spacecraft are very expensive, and to reduce risk, the avionics may employ redundancy such that if one element fails the entire architecture is able to continue, but SmallSat avionics designs are more centralized, whereby if one element fails, the entire system fails. Figure 8.1 illustrates an architectural block diagram of a centralized small spacecraft system. In anticipation of extended durations in low-Earth orbit (LEO) and deep space missions, designers are now incorporating radiation-hardened (rad-hard) or radiation-tolerant architecture designs in their SSA packages to further increase their overall reliability.

While a significant focus of this chapter is on commercial products and developments, vendors are not the only ones developing avionics platforms; there are also numerous government and academic efforts worth considering, with a few examples below:

  • SpaceCube and MUSTANG, by NASA GSFC (government)
  • Sabertooth by JPL
  • CHREC/SHREC Space Processor, by NSF SHREC (academic)
  • RadPC by Montana State University (academic) 

Given the distributed and integrated nature of modern SSA, this chapter organizes the state-of-the-art in SSA into CDH (8.3) and FSW (8.4). On-the-Horizon activities (TRL <5) for CDH and FSW (8.5 and 8.6, respectively) highlight recent developments in next-generation SSA systems. Avionics Systems Platform and Mission Development Considerations (8.2) discusses how these considerations are being addressed and/or mitigated by state-of-the-art advances in CDH, FSW, and PSA products. A summary of future SSA systems is provided in (8.7).

flow chart
Figure 8.1: Functional block diagram of the LADEE spacecraft.
Credit: NASA

The information described below is not intended to be exhaustive but provides an overview of current state-of-the-art technologies and their development status. It should be noted that Technology Readiness Level (TRL) designations may vary with changes specific to payload, mission requirements, reliability considerations, and/or the environment in which performance was demonstrated. Readers are highly encouraged to reach out to companies for further information regarding the performance and TRL of described technology. There is no intention of mentioning certain companies and omitting others based on their technologies or relationship with NASA.

8.2 Avionics Systems Platform and Mission Development Considerations

There are many factors to be considered in selecting the optimum configuration and implementation of avionics subsystems, components, and elements for small spacecraft missions. Overall spacecraft concerns of Size, Weight, and Power (SWaP) always need to be considered. Some of the more pertinent issues and concerns that all small spacecraft missions must address include:

  • Mission applicability and tailoring
  • Element, module, and component modularity and interoperability 
  • Manufacturing and production efficiency, complexity, and scaling
  • Mission environment, especially radiation and long-duration space exposure
  • Standards and regulatory concerns
  • SWaP-C constraints

In addition to CDH and FSW, state-of-the-art SSA systems should consider the following subsystem/payload specific electronic systems:

  • Small spacecraft platform size ranges and configurations
  • Integrated avionics platform architectures
  • Mission avionics configurations
  • Spacecraft and mission autonomy

Flight payload and subsystems avionics elements include:

  • Subsystem integrated onboard computer (OBC) controllers
  • Integrated systems health avionics
  • Onboard payload processors
  • Cloud-based processors   

Modular avionics architectures for small spacecraft can be characterized as either federated or integrated. In a federated avionics architecture, each subsystem of the spacecraft is considered an independent, dedicated autonomous element, with the avionic components performing all functions independently and exchanging data over standardized communications protocols and interfaces. An integrated avionics architecture is a shared, distributed functionality, that can be configured with distributed, heterogeneous and/or mixed criticality elements. In either case, modular avionics architectures can be configured with smart subsystem capabilities, redundant fault tolerant radiation, and anomaly mitigation procedures.

Constellation networks and swarms, synchronized formations, and other multi-satellite cluster formations are creating new opportunities for SSA. The increased need for synchronization, intersatellite communications, controlled positioning for integrated CDH functionality, coordination and conduct, Concept of Operations (ConOps), and autonomous operations impose new constraints on the avionics system. This is true not only for single satellites, but now also for multi-satellite configurations, whereby overall mission performance is dependent on all the platform elements acting in a co-dependent fashion.

8.3 State-of-the-Art (TRL 5-9): Command and Data Handling

Current trends in small spacecraft CDH generally appear to be following those of previous, larger scale CDH subsystems. The current generation of microprocessors can easily handle the processing requirements of most CDH subsystems and will likely be sufficient for use in spacecraft bus designs for the foreseeable future. Cost and availability are likely primary factors for selecting a CDH subsystem design from a given manufacturer, but many groups develop their own custom platforms. The ability to spread nonrecurring engineering costs over multiple missions and reduce software development through reuse are both desirable factors in a competitive market. Heritage designs work well for customers looking to select components with proven reliability for their mission. SmallSat CDH should consider the following:

  1. Avionics and onboard computing form factors
  2. Highly integrated onboard computing products
  3. Rad-hard processors and FPGAs
  4. Memory, electronic function blocks, and components
  5. Bus electrical CDH interfaces
  6. Radiation mitigation and tolerance schemes

As small satellites move from the early CubeSat designs with short-term mission lifetimes to potentially longer missions, radiation tolerance becomes a significant factor when selecting parts. These distinguishing features, spaceflight heritage and radiation tolerance, are the primary differentiators in the parts selection process for long-term missions, verses those which rely heavily on commercial-off-the-shelf (COTS) parts. Experimental missions typically focus on low-cost, easy-to-develop systems that take advantage of open-source software and hardware to provide an easy entry into space systems development, especially for hobbyists or those who lack specific spacecraft expertise.

Small spacecraft CDH technologies and capabilities have been continuously evolving, enabling new opportunities for developing and deploying next-generation SSA. When small spacecraft were first introduced, a primary purpose was to observe and send information back to Earth. As awareness and utility have expanded, there is a need to improve the overall capability of data collection for specific mission environments beyond LEO. Small spacecraft, including nanosatellites and CubeSats, currently perform a wide variety of science in LEO, and these smaller platforms are emerging as candidates for more formidable missions beyond LEO.

The adoption of CubeSat and SmallSat technology is enabled by the miniaturization of electronics, sensors, and instruments. As spacecraft manufacturers begin to use more space-qualified parts, they find that those devices can often lag their COTS counterparts by several generations in performance but may be the only means to meet the radiation requirements placed on the system. Presently, there are several commercial vendors who offer highly integrated systems that contain the onboard computer, memory, electrical power system (EPS), and the ability to support a variety of Input & Output (I/O) for the CubeSat class of small spacecraft. Several CDH developments for CubeSats have resulted from in-house development, the rise of new companies that specialize in CubeSat avionics, and the use of parts from established companies who provide spacecraft avionics for the space industry in general. While parallel developments are impacting the growth of CubeSats, vendors with ties to the more traditional spacecraft bus market are increasing CDH processing capabilities within their product lines.

In-house designs for CDH units are being developed by some spacecraft bus vendors to better accommodate small vehicle concepts. While these items generally exceed CubeSat form factors in size, they can achieve similar environmental performance and may be useful in small satellite systems that replicate more traditional spacecraft subsystem distribution.

8.3.1 Avionics and Onboard Computing Form Factors

The CompactPCI and PC/104 form factors continue generally to be the industry standard for CubeSat CDH bus systems, with multiple vendors offering components that can be readily integrated into space-rated systems. Overall, form factors should fit within the standard CubeSat dimension of less than 10 × 10 cm2. Spacecraft avionics components are performance-driven and not necessarily dependent on spacecraft platform sizes, but some noncontainerized spacecraft platforms may need to consider the availability and utility of higher TRL avionics products. The PC/104 form factor was the original inspiration to define standard architecture and interface configurations for CubeSat processors, but with space at a premium, many vendors have been using all available space exceeding the formal PC/104 board size. Although the PC/104 board dimension continues to inspire CubeSat configurations, some vendors have made modifications to stackable interface connectors to address reliability and throughput concerns. Many vendors have adopted the use of stackable “daughter” or “mezzanine” boards to simplify connections between subsystem elements and payloads, and to accommodate advances in technologies that maintain compatibility with existing designs. A few vendors provide a modular package which allows users to select from a variety of computational processors.

8.3.2 Highly Integrated Onboard Computing Products

A variety of vendors are producing highly integrated, modular, onboard computing systems for small spacecraft. These CDH packages combine processors and/or Field Programmable Gate Arrays (FPGAs) with various memory banks, and with a variety of standard interfaces for other subsystems onboard. FPGAs and software-defined architectures also give designers a level of flexibility to integrate uploadable software modifications to adapt to new requirements and interfaces. Table 8-1 summarizes the current state-of-the-art for some of these components. It should be noted that while some products have achieved TRL 9 by virtue of a space-based demonstration, what is relevant in one application may not be relevant to another, and different space environments and/or reliability considerations may result in lower TRL assessments. Some larger, more sophisticated computing systems have significantly more processing capability than what is traditionally used in SmallSat CDH systems, however the increase in processing power may be a useful tradeoff if payload processing and CDH functions can be combined (note that overall throughput should be analyzed to assure proper functionality under the most stressful operating conditions).

System developers are gravitating towards ready-to-use hardware and software development platforms that can provide seamless migration to higher performance architectures. As with non-space applications, there is a reluctance to change controller architectures due to the cost of retraining and code migration. Following the lead of microprocessor and FPGA vendors, CubeSat avionics vendors are now providing simplified tool sets and basic, cost-effective evaluation boards.

Table 8-1: Sample of Highly Integrated Onboard Computing Systems
ManufacturerProductProcessor/ SoC/ FPGARadiation Hardness Assurance (RHA)Board Dimension (cm)Power Consumption (W)Orbits FlownRef
AAC Clyde SpaceKryten-M3Smart Fusion 2 SoC including an ARM Cortex-M3 processor delivering 62.5 DMIPSTID 20 krad
(system level)
AAC Clyde SpaceSirius OBC & TCM32-bit LEON3FT (IEEE-1754 SPARC v8) fault-tolerant processorTID 20 krad
(system level)
9.589×9.017×1.7201.3LEO, lunar lander(2)
Alén SpaceOBC+TTCARM 32-bit Cortex-M7 with FPUn/a8.93×9.33×1.26OBC_max: 5.865
TTC_max: 5.865
LEO, 2024(3)
Aitech Systems Inc.SP0-SPower PC 1020, Alcatel RTAX100 krad TID, SEL/LET 40 Mev-cm2/mg (without enclosure)3U cPCI: 10.06x16x20.312LEO, MEO, GEO, Lunar, Deep Space*(4)
Aitech Systems Inc.SP1-S64-bit Arm® Cortex®-A72 cores @ 1.8 GHz100 krad TID (Target)3U Space VPX: 10.06x16x20.3<25TBD(4)
Aitech Systems Inc.S-A1760Pascal™ Architecture GPU w/256 CUDA® cores NVIDIA Denver 2 Dual-Core ARM® CPU + Cortex® A57 Quad-Core ARM® CPU1.05 krad TID, < 1 type 2 SEFI update in 158 days (without enclosure)12.7×12.7×5.2Configurable ≤ 5 Idle, 8-10 under typical CUDA load, <20 when System on Module is fully utilizedLEO*(5) (6)
Aitech Systems Inc.S-C8780Intel® Pentium-D or Xeon-D, discrete 2D GPU, Xilinx UltraScale+ FPGA w/Dual-core ARM® CPUTBD3U Open VPX: 10.06x16x20.3Configurable 25-55TBD(7)
Aitech Systems Inc.S-C8500Intel® Tiger Lake UP3 SoC, 4 cores/8 threads, integrated GPGPU with 96 Execution Units, Xilinx UltraScale+ FPGA w/Dual-Core ARM® CPU is Optional1 krad TID, SEL/LET TBD (without enclosure)3U Open VPX: 10.06x16x20.3CPU Configurable from 12-28, Total system 22-42 configurations.TBD(8)
Table 8-1: Sample of Highly Integrated Onboard Computing Systems (Continued)
ManufacturerProductProcessor/ SoC/ FPGARadiation Hardness Assurance (RHA)Board Dimension (cm)Power Consumption (W)Orbits FlownRef
ArgotecOBC FERMIDual-Core LEON3FT SPARC V8 Processor with fault-tolerant memory controller +Microchip RTG4Rad-hard10.24x10x4.495 (depending on load)Deep Space, Lunar Orbit, Earth Orbi(9)
ArgotecOBC HACKQuad-Core SPARC V8 +Xilinx Kintex7Rad-hard + MIL + Automotive10×12.3×4.610 (depending on load)(10)
Bradford SpaceBinary OBCDual ARM Cortex R530 krad (Si) + functional SEE resilience through SW EDAC and internal cold redundancy13.3×11.53 Peak
1 Idle
C3S Electronics Development LLCOBC32-bit ARM Cortex-M7Continuous integrity check on the program memory, multi-level watchdog system, MRAM storage0.92×0.895×0.123 without daughterboard, 0.92×0.895×0.136 with daughterboard0.46 (measured in test mode, using eMMC as mass storage)LEO(12)
Cesium AstroSBC-14611.4 GHz ARM CortexLEO5×8.4×1.38LEO (2023)(13)
EnduroSatOBCARM Cortex M7Tested at 40 krad TID8.9×9.4×2.3 (with integrated GNSS)1.5 Peak 0.2 Idle400-600 km SSO, ISS-like, equatorial(14)
EnduroSatPayload ControllerXilinx UltraScale+ SoC20 krad TID (SoC testing)9.8×9.8×7.4<50 Peak, 20 IdleTBD
GOMspaceNanoMind HP MK3Xilinx Zynq 7030/7045>20 krad9.5×9.5×3.15Dependent on customer applicationLEO(15)
IbeosEDGE­1100 (3U SpaceVPX)AMD Ryzen SOCTID: 30 kRAD SEE: >37 MeV3U SpaceVPX; 16(L) x 10(W) x 2.5(Pitch)6-35Designed for LEO and GEO
IbeosEDGE­1100 GenieAMD Ryzen SOCTID: 30 kRAD SEE: >37 MeV14.8(L) x 10.8 (W) x 3.4(H) – Stand-alone box8-35Designed for LEO and GEO
InnoflightCFC-400XSDefense Grade Xilinx UltraScale+ MPSoCTID: 30 krad8.2×8.2×2.76-25LEO (2021) & GEO (2022)(16)
InnoflightCFC-400XPDefense Grade Xilinx UltraScale+ MPSoCTID: 30 krad17.2x10x2.54-30LEO in 2024(17)
Table 8-1: Sample of Highly Integrated Onboard Computing Systems (Continued)
ManufacturerProductProcessor/ SoC/ FPGARadiation Hardness Assurance (RHA)Board Dimension (cm)Power Consumption (W)Orbits FlownRef
InnoflightCFC-510PAMD Ryzen GPGPUTID: 30 krad17.2x10x2.512-40LEO in 2024
KP LabsAntelope OBC and DPUOBC – RM57 Herkules microcontroller (Dual 300 MHz ARM Cortex-R5F with FPU in lock-step)
DPU – AMD Xilinx Zynq UltraScale+ MPSoC (ZU2EG, ZU3EG, ZU4EG, ZU5EG), Quad ARM Cortex-A53 CPU, Dual ARM Cortex-R5 in lock-step
COTS with SEE mitigationMotherboard – 1x1x1
Daughterboard – 7x4x2
From less than 0.5 (DPU is off) to 6 (DPU processes the data)LEO(18)
KP LabsLeopard DPUAMD Xilinx Zynq UltraScale+ MPSoC (ZU6EG, ZU9EG, ZU15EG); Quad ARM Cortex-A53 CPU; Dual ARM Cortex-R5 in lock-stepCOTS with SEE mitigationNon-redundant: 9×9.5×5
Redundant: 9×9.5×7.8
7 static power consumption; up to 10 for deep learning inference.LEO(19)
KP LabsLion DPUAMD Xilinx Kintex Ultrascale FPGA (KU035, KU060, KU095)COTS with SEE mitigation16x10x5<15 for KU035 versionTBD(20)
Laboratory for Atmospheric and Space PhysicsLASP Generic Small-sat FPGA BoardKintex-725 krad8.763×8.7631LEO(21)
Micro Aerospace SolutionsMAS-SBC-107Arm® Cortex®-M7Total Ionizing Dose of 30 krad (Si)9×9.6<30LEO
Nara Space TechnologyNSTOBCAtmel ARM 9 based Microprocessor Unit<24 krad9x9x1.6 0.429 (Idle) LEO qualified 
Table 8-1: Sample of Highly Integrated Onboard Computing Systems (Continued)
ManufacturerProductProcessor/ SoC/ FPGARadiation Hardness
Assurance (RHA)
Board Dimension (cm)Power Consumption(W)Orbits FlownRef
Novo SpaceSBC002AVZynq Ultrascale+TID: 30 krad; Automotive parts with Rad-tolerant in high criticality parts; Rich telemetry with local event response; Board sectorization and power control; ECC in Volatile memories; CRC / Reed-Solomon / Interleaving in Non-Volatile memories; FPGA and fabric use selective TRM on critical functionality; Scrubbing on soft FPGAs.16×10application dependent
active mode max: 15
Novo SpaceSBC003AVSmartFusion216×10application dependent
active mode max: 8
Novo SpaceSBC004AFVersal ACAP16×10Under developmentTBD(24)
Novo SpaceSBC005AFPolarfire16×10application dependent
active mode max: 8
Novo SpaceGPU001AFJetson TX2i8.7×5active mode min:9
active mode max:15
Novo SpaceGPU002AFJetson Orin NanoTID: 30 krad8.7×5active mode min:6
active mode max:11
Pumpkin Space SystemsPPM A1MCU+DSPN/A90×960.05LEO
Pumpkin Space SystemsPPM A2MCU+DSPN/A90×960.05LEO
Pumpkin Space SystemsPPM A3MCU+DSPN/A90×960.05LEO 
Pumpkin Space SystemsPPM B1MCU+DSPN/A90×960.05LEO 
Pumpkin Space SystemsPPM D1MCUN/A90×960.05LEO 
Pumpkin Space SystemsPPM D2MCU+DSPN/A90×960.05LEO 
Pumpkin Space SystemsPPM E1MCUN/A90×960.05LEO 
Pumpkin Space SystemsPPM B1MCU+DSPN/A90×960.05LEO 
Pumpkin Space SystemsPPM D1MCUN/A90×960.05LEO 
Pumpkin Space SystemsMBM2 w/BBBMCU~5 krad90×962LEO 
Table 8-1: Sample of Highly Integrated Onboard Computing Systems (Continued)
ManufacturerProductProcessor/ SoC/ FPGARadiation Hardness Assurance (RHA)Board Dimension (cm)Power Consumption (W)Orbits FlownRef
Resilient ComputingRadPC-SBC-001RISC-V 32-Bit (AMD Artix 7)COTS with SEE mitigation10×101.5LEO, Lunar (2024)(28)
SkyLabsNANOhpc-obc4x RISC-V 64-bit / PolarFire / SoCCOTS w/ SEE mitigation9.5×9.1×1.3~10 Peak(29)
SkyLabsNANOhpm-obc32-bit RISC-V core / PolarFireCOTS w/ SEE mitigation9.5×9.1×1.3<5LEO, MEO(30) (31)
SkyLabsNANOobc-2PicoSkyFT / IGLOO 2COTS w/ SEE mitigation9.5×9.1×1.1<1 Peak, <0.9 IdleLEO, MEO(32) (33)
Space Dynamics LaboratoryPearl AvionicsLEON3 / RTP310 krad13×92-6LEO, GEO
SPiN USAMA61C CubeSatGR712RC dual-core 32-bit LEON3 fault-tolerant, SPARC V8 processorProcessor is 300 krad9.599×9.0271-1.2TBD(34)
SPiN USAMA61C smallsatGR712RC dual-core 32-bit LEON3 fault-tolerant
SPARC V8 processor
Processor is 300 krad10.5×10.51-1.2TBD(35)
SPiN USAMA61C cPCI serial spaceGR712RC dual-core 32-bit LEON3 fault-tolerant
SPARC V8 processor
Processor is 300 krad16×101-1.2TBD(36)
Spiral BlueSpace Edge OneNvidia Jetson Xavier NXN/A10×107LEO(37)
Southwest Research Institute® (SwRI®)Centaur SBCGR712RC dual core LEON3-FT CPU
Xilinx Ultrascale or Microchip RT-ProAsic or RTG4 FPGA
TID: Up to 60 krad (Si), more with shielding
SEL: Immune to >67eV/mg/cm2
SEU: < 1 error per 24 hour period
Available in 3U/6U cPCI form factorsLow power < 4 OperationLEO(38)
Southwest Research Institute® (SwRI®)HP-SBCPowerPC based MPC8548e CPU
Microsemi RT-ProASIC FPGA
Optional: Microsemi RTG4 FPGA
Optional: Xilinx Ultrascale FPGA
TID: Up to 60 krad (Si), more with shielding
SEL: Immune to >67eV/mg/cm2
SEU: < 1 error per 24-hour period
Available in 3U/6U cPCI form factors12-20 depending on clock frequency and FPGA pairingLeo and GEO(38)
Table 8-1: Sample of Highly Integrated Onboard Computing Systems (Continued)
ManufacturerProductProcessor/ SoC/ FPGARadiation Hardness Assurance (RHA)Board Dimension (cm)Power Consumption (W)Orbits FlownRef
SpacemanicDeepThought_OBC  SAMV71 -6.7×4.2×0.70.1   GRBAlpha
BDSat1 & 2
SpacemanicEddie_OBCMSP4306.7×4.2×0.70.1LEO (500-550 SSO), Planetum
Trident Space Electronic SystemsVDRTVersal VC190230 krad / 50MeV LU10×14.6×2.54<60LEO/MEO capable(41)
Trident Space Electronic SystemsUDRTMPSoC ZU1930 krad / 40MeV LU10×14.6×2.54<50Multiple LEO 400-1200km missions(42)
UnibapiX10-100AAMD Ryzen V1000 (CPU and GPU)
Intel Myriad-X (VPU)
Radiation Tolerant COTS
with SEE mitigation
UnibapiX5-106AMD Steppe Eagle (CPU and GPU)
Intel Myriad-X (VPU)
Microchip SmartFusion2 (FPGA)
Radiation Tolerant COTS
with SEE mitigation
XiphosQ7SAMD-Xilinx Zynq-7020 Dual-core ARM Cortex-A925 krad7.8×4.3×0.92LEO
XiphosQ8SAMD-Xilinx Zynq Ultrascale+ MPSOC Quad-core ARM Cortex-A5330 krad8x8x1.12>5LEO
XiphosQ8JsAMD-Xilinx Zynq Ultrascale+ MPSOC Quad-core ARM Cortex-A5330 krad8x8x1.12>5LEO
*Orbits flown are on larger spacecraft

8.3.3 Radiation-Hardened Processors

Several radiation-hardened embedded processors have recently become available. These are being used as the core processors for a variety of purposes including CDH. Some of these are the Vorago VA10820 (ARM M0) and the VA41620 and VA41630 (ARM M4); Cobham GR740 (quad core LEON4 SPARC V8); BAE 5545 quad core processor; and LS1043 quad processor. These have all been radiation tested to at least 50 kRad total ionizing dose.

8.3.4 Memory, Electronic Function Blocks, and Components

The range of onboard memory for small spacecraft is wide, typically starting around 32 kB and increasing with available technology. For CDH functions, onboard memory requires high reliability. A variety of different memory technologies have been developed for specific traits, including volatile memory, such as Static Random-Access Memory (SRAM) and Dynamic RAM (DRAM), Magnetoresistive RAM (MRAM), Ferro-Electric RAM (FERAM), Chalcogenide RAM (CRAM) and Phase Change Memory (PCM). SRAM is typically used due to price and availability, with numerous SRAM choices (up to 4M x 39 [20 MB]). There are many manufacturers that provide a variety of electronic components that are space-rated with high reliability. A chart comparing the various memory types and their performance is shown in table 8-2.

Table 8-2: Comparison of Memory Types
Operating Voltage, ±10%2.5 – 5 V1.35-3.3 V3.3 & 5 V3.3 V3.3 V3.3 V
Organization (bits/die)512 k × 8
4M × 39
128 M × 8
1Gb × 8
16 M × 8
4G × 8
2M × 816 k × 8Unk
Data Retention (70°C)N/AN/A10 years10 years10 years10 years
Endurance (Erase/Write cycles)UnlimitedUnlimited1E51E131E131E13
Access Time10-25 ns25 ns50 ns after
page ready;
200 us write;
2 ms erase
300 ns300 ns100 ns
Radiation (TID)50K – 1 Mrad50 krad30 krad1 Mrad1 Mrad1 Mrad
Temperature RangeMIL-STDIndustrialCommercialMIL-STDMIL-STDMIL-STD
Power500 mW300 mW30 mW900 mW270 mWUnk
Package4 MB-20 MB128 MB 1GB128MB – 4 GB2 MB1.5 MB
(12 chip package)

8.3.5 Bus Electrical Interfaces

CubeSat class spacecraft continue to use interfaces that are common in the microcontroller or embedded systems world. Highly integrated systems, especially systems-on-chip (SoCs), FPGAs, and application-specific integrated circuits (ASICs), will typically provide several interfaces to accommodate a wide range of users and to ease the task of interfacing with peripheral devices and other controllers. FPGAs are commonly used for these interfaces because of their flexibility and ability to change interfaces as needed. Some of the most common bus electrical interfaces are listed below with applicable interface standards:

  • Serial Communication Interfaces (SCI): RS-232, RS-422, RS-485 etc.
  • Synchronous Serial Communication Interface: I2C, SPI, SSC and Enhanced Synchronous Serial Interface(ESSI)
  • Multimedia Cards (SD Cards, Compact Flash, etc.)
  • Networks: Ethernet, LonWorks, etc.
  • Fieldbuses: CAN Bus, LIN-Bus, PROFIBUS, etc.
  • Timers: PLL(s), Capture/Compare and Time Processing Units
  • Discrete IO: General Purpose Input/Output (GPIO)
  • Analog to Digital/Digital to Analog (ADC/DAC)
  • Debugging: JTAG, ISP, ICSP, BDM Port, BITP, and DB9 ports
  • SpaceWire: a standard for high-speed serial links and networks
  • High-speed data: RapidIO, XAUI, SerDes and MGT protocols are common in routing large quantities of mission data in the gigabit per second speeds

8.3.6 Radiation Mitigation and Tolerance Schemes

Deep space and long-duration LEO missions compel developers to consider reliability requirements and possibly incorporate radiation-mitigation strategies into their respective spacecraft designs. CubeSats are often either composed of only COTS components or a hybrid combination of COTS and rad-hard and radiation-tolerant components. COTS components typically offer superior performance, energy efficiency, and affordability compared to their rad-hard alternatives; however, COTS devices tend to be highly susceptible to radiation. The advantages of COTS components have enabled low-cost CDH development, while also allowing developers to leverage start-of-the-art technologies in their designs. A hybrid design combines COTS and rad-hard components, such as COTS processor and memory with rad-hardened supporting electronics (e.g., EPS, watchdog, etc.), to maximize the benefits of both technologies. These designs may also incorporate radiation-mitigation techniques to further enhance overall system reliability.

For space applications, the effects of radiation on electronic devices can vary broadly (44). Radiation effects are often categorized into long-term cumulative effects and transient single-event effects (SEEs). Long-term effects include total ionizing dose (TID) and displacement damage dose (DDD). TID, measured in krad, is the ionizing radiation absorbed by the device material over time causing parametric or functional degradation of the device. DDD is the nonionizing damage caused by particle collisions with the device structure over time. SEEs occur when a single radiation particle strike deposits enough charge to cause an effect. SEEs can be destructive or nondestructive. Single-event upsets (SEUs) are nondestructive SEEs that can affect the logic state of a memory cell. Single-event latch-up (SEL) are destructive SEEs that manifest as parasitic structures in CMOS logic or bipolar transistor structures, potentially causing a high-current state.

Other areas of consideration for CDH elements include memory, imaging, protection circuits (watchdog timers, communications watchdog timers, overcurrent protection, and power control), memory protection (error-correction code memory and software error detection and correction), communication protection (several components), and parallel processing and voting.

8.4 State-of-the-Art (TRL 5-9): Flight Software

The FSW, at a fundamental level, communicates the instructions for the spacecraft to perform all operations necessary for the mission. These include all the science objectives as well as regular tasks (commands) to keep the spacecraft functioning and ensure the storage and communication of data (telemetry). The FSW is usually thought of as all the programs that run on the CDH avionics but should also include all software running on the various subsystems and payload(s).

There are many factors in selecting a development environment and/or operating system for a space mission. A major factor is the amount of memory and computational resources. There are always financial and schedule concerns. Another factor is what past software an organization may have used and their experiences with that software. The maturity of the software and its availability for the target subsystem or payload are additional factors to be considered in the final selection.

FSW complexity can refer to the architecture design (e.g., the interactions between subsystems, especially for spacecraft autonomy) as well as the number of operations to be performed. The more software is required to do, the bigger the task and cost. This complexity (and the associated verification effort) is what primarily drives the cost and schedule for a program or mission. Required reliability and fault management can also increase complexity and cost, regardless of the size of the spacecraft. Changing requirements is also a huge factor, which may be mitigated by involving the software team early in the planning process.

With the increase in processing capability with CDH and other processors, more capable FSW has been enabled. Traditionally, larger spacecraft require rad-hard processors which have poor performance, while CubeSats and SmallSats can take more risks with COTS processors that offer substantially more performance. Several advances have increased the processing capabilities available for CubeSats. Low-power ARM-based processors and embedded COTS SoCs, as well as advances in radiation hardened processors, have brought similar processing capabilities down to the small size of CubeSats. All of this has resulted in increased demands and requirements for FSW.

Generally, CDH and other subsystems need to be able to supervise several inputs and outputs as well as process and store data within a fixed time-period. These all need to be performed in a reliable and predictable fashion throughout the lifetime of the mission. The needs of each mission can vary greatly, but basic deterministic and reliable processing is a fundamental requirement. The following are important when considering FSW design:

  • Implication of CDH processors on FSW
  • Frameworks
  • Operating systems
  • Software languages
  • Mission operations and ground support suites
  • Development environment, standards, and tools

8.4.1 Implication of CDH Processors on FSW

The processor and memory available on the CDH can put significant limitations on the FSW. For some of the smaller jobs, or to reduce electronic complexity, smaller processors are used (distributed processing). These have typically been thought of as embedded processors, with many of them containing dedicated memory. Modern integrated space avionics, including heterogeneous and mixed criticality architectures, also impact operational constructs and can contribute to advanced configurations (such as multiple modular redundant systems architectures) which can allow advanced paradigms for radiation tolerance and system redundancies in critical small spacecraft missions.

8.4.2 Frameworks

In the context of SSA, a FSW framework can be described as a hierarchal architecture, sometimes referred to as a set of lego-like building block constructs, partitions, and functions. This emerging system-of-systems concept describes the large-scale integration of many independent, self-contained systems that work together to satisfy a global need. Examples of commonly used frameworks include:

8.4.3 Operating Systems

Operating systems manage computer hardware, software resources, and provide common services for computer programs. Examples of commonly used operating systems include:

  • VxWorks
  • FreeRTOS
  • Linux

8.4.4 Software Languages

System programming involves designing and writing computer programs with software languages that allow the computer hardware to interface with the programmer and the user, leading to the effective execution of application software on the computer system. State-of-the-art small spacecraft have used C, C++, Python, Arduino and other software languages.

8.4.5 Mission Operations and Ground Support Suites

Although not directly used on the spacecraft, mission operations and ground support suites must also use software and systems for testing, and to monitor, command, control, and communicate with the spacecraft, as well as display status and disseminate data across all aspects of a space mission (including spacecraft performance and procedures, systems health, science and technology data handling and management, and telemetry tracking and control). For smaller spacecraft and missions, it is usually best to use the same ground support software for mission operations, integration and testing, and development and testing. There are numerous open-source and proprietary tools and programs available for these activities. A small set of tools that have been used at NASA are described below. For more information, please refer to the Ground Data System and Mission Operations chapter.

8.4.6 Development Environment, Standards, and Tools

Development environment, standards, and tools are used to design, develop, validate, and operate small spacecraft missions, with adherence to accepted software and space mission standards. Examples of commonly used development tools include:

  • Version control tools
  • Auto-generation of software
  • Simulations and simulators
  • Software best practices and NPR7150

8.5 On the Horizon (TRL 1-4): Command and Data Handling

Many CDH systems will continue to follow trends set for embedded systems. Short-duration missions in LEO will continue to take advantage of advances made by industry leaders who provide embedded systems, technologies, and components. In keeping with the low-cost, rapid development theme of CubeSat-based missions, many COTS solutions are available for spacecraft developers.

While traditional CDH processing needs are relatively stagnant, as small satellites are being targeted for flying increasingly data-heavy payloads (i.e., imaging systems) there is new interest in advanced onboard processing for mission data. Typically, these higher performance functions would be added as a separate payload processing element outside of the CDH function.

Next-generation SSA/PSA distributed avionics applications are integrating FPGA-based software-defined radios (SDRs) on small spacecraft (45). A SDR can transmit and receive in widely different radio protocols based on a modifiable, reconfigurable architecture, and is a flexible technology that can enable the design of an adaptive communications system. This can increase data throughput and enable software updates on-orbit, also known as re-programmability. Additional FPGA-based functional elements include imagers, Artificial Intelligence and Machine Learning (AI/ML) processors, and subsystem-integrated edge and cloud processors. The ability to reprogram sensors or instruments while on-orbit have benefited several CubeSat missions when instruments do not perform as anticipated, or when entering an extended mission phase that requires subsystems or instruments to be reprogrammed.

In keeping with trends seen in other disciplines and industries, the Industry 4.0 and “digitally managed everything” is absolutely of critical importance for technological and programmatic efficiencies in SSA systems development. Following are some modern tools, technologies, and approaches that should be considered when developing and deploying next-generation small spacecraft avionic systems:

  • Artificial intelligence, machine learning, and machine vision
  • Robotics and automation
  • Model-based systems engineering
  • Embedded systems / edge computing
  • Internet-of-space-things
  • Cloud computing
  • Augmented reality/ virtual reality / mixed reality
  • Software-defined-everything
  • Advanced manufacturing
  • Digital twin

8.6 On the Horizon (TRL 1-4): Flight Software

FSW is key to mission success. The field of software is a very dynamic environment that is continuously evolving. The challenges with flight software usually remain the same regardless of the size of the spacecraft (CubeSat to SmallSat) and are related to the size and complexity of the endeavor. Overall, FSW can be known to cause scheduling and implementation issues, especially during integration and test. There is usually a temptation to add additional features, and all these factors can drive up overall complexity of the FSW and increase risk to the mission as a whole.

It is essential that FSW be as simple as possible. It is critical to survey options and plan early in any FSW effort. Wherever possible, early development and testing should be performed. Efforts to add additional features should be looked at very critically with a strong effort to stick to the existing plan. With good planning and careful execution, a favorable outcome can be achieved. It is becoming more common to update software after the hardware is delivered (or even launched), and there are now software frameworks such as cFS that have features to enable software updates after deployment.

On the horizon FSW will soon include multicore processor operating systems and programming, as learning how to harness multicore processors differently than Microsoft Windows does will enable true real-time multiprocessing. On the horizon FSW will also include artificial intelligence (e.g., Nvidia); FSW for multicore, multiprocessor, and heterogenous platforms (e.g., AMD-Xilinx Versal); and FSW (middleware) for constellations of SmallSats with resource management, scheduling and task assignment, and fault tolerance.

Spacecraft autonomy is an emerging capability and SmallSat designers have particular interest in the following characteristics for autonomous systems:

  • Situational and self-awareness
  • Reasoning and acting
  • Collaboration and interaction
  • Engineering and integrity

Spacecraft autonomy can be considered part of management, direction, and control for all subsystems and functions in a spacecraft. CDH takes input from, and provides direction to, all subsystems (ADCS, Power, Propulsion, Comm, vehicle health, etc.). Those subsystems may also have a degree of autonomy depending on the complexity of its local “smart subsystems” processor. The NASA 2020 Technology Roadmap defines autonomous systems as a cross-domain capability that enables the system to operate in a dynamic environment independent of external control (46).

Some autonomous systems now implement a heterogeneous architecture, meaning they contain multiple processors with varying levels of performance and capabilities. For instance, higher performance modules and components can be used for sophisticated data processing, AI and onboard computing for both spacecraft and mission performance optimization—as well as real-time adaptive analysis of science data—while lower performance onboard processors and FPGAs conduct the routine spacecraft operations functions and interact with the subsystems which also may include distributed performance cascades.

8.7 Summary

Space applications now require considerable autonomy, precision, and robustness, and are refining technologies for such operations as on-orbit servicing, relative and absolute navigation, inter-satellite communication, and formation flying. An exciting trend is that small spacecraft missions are becoming more complex as these platforms are now being used for lunar and deep space science and exploration missions. Small spacecraft technology is expanding to meet the needs of increasing small spacecraft mission complexity. This has accelerated over the past few years to achieve the next gen goals of using small spacecraft to collect important science in deep space, and mitigate risk for larger, more complex mission-critical situations. In parallel, spacecraft electronics have matured with higher performance and reliability, and with miniaturized components that meet the growing needs of these now very capable spacecraft.

The2022 Small Spacecraft Avionics chapter has been updated with a broader, interrelated framework, where CDH, FSW, and smart payloads are not just independent space platform subsystems but are part of an integrated avionics ecosystem which includes all electronic elements of a space platform, now primarily digitally based and or managed. Also, SSA should not be considered as an isolated spaceflight technology component, but rather as a core digital engineering technology emphasis area, capable of taking advantage of and integrating products, processes, and technologies from other disciplines. To continue to be relevant and efficient, the SSA communities must remain cognizant and receptive of the continuously evolving nature of the digital based Industry 4.0 technology revolution now being evidenced in other related and/or associated vertical disciplines and solutions.

For feedback solicitation, please email: Please include a business email for further contact.


  1. AAC Clyde Space. “Kryten-M3” datasheet. Available online at: Accessed: August 1, 2023.
  2. AAC Clyde Space. “Sirius OBC and TCM” datasheet. Available online at: Accessed: August 1, 2023.
  3. Alen Space. “TRISKEL OBC+TTC+OBSW Solution” datasheet. Available at: . Accessed: December 1, 2023.
  4. Aitech Systems Inc. [Online] “SP0-S: Radiation Tolerant 3U CompactPCI SBC”. Accessed: December 1, 2023. Available at:
  5. Aitech Systems Inc. [Online] “S-A1760 Venus: Radiation-characterized Space AI GPGPU”. Accessed: December 1, 2023. Available at:
  6. Aitech Systems Inc. [Online] “Aitech’s Space-rated AI Supercomputer On NASA Atmospheric Re-entry Demonstration”. May 2023. Accessed: December 1, 2023. Available at:
  7. Aitech Systems Inc. [Online] “C878:3U VPX SBC”. Accessed: December 1, 2023. Available at:
  8. Aitech Systems Inc. [Online] “U-C850x Series: Innovative SWaP-C-optimized Secure 3U”. Accessed: December 1, 2023. Available at:
  9. Argotec. [Online] “FERMI: Deep Space On-Board Computer,” Technical Datasheet. Available at:
  10. Argotec. “Hack: High-Performance Modular On-Board Computer,” Technical Datasheet. [Online] Available at:
  11. Bradford Space Deep Space Industries. “Deep Space Avionics” Preliminary Datasheet.
  12. C3S Electronics Development LLC. “OBC” Datasheet. Available at:
  13. Cesium Astro. [Online] “SBC-1461: Single-Board Computer”. Accessed: December 1, 2023.  Available at:
  14.  EnduroSat. [Online] “Onboard Computer (OBC). Accessed: December 1, 2023.  Available at:
  15.  GOMspace. [Online] “NanoMind HP MK3”. Available at:
  16.  Innoflight. [Online] “CFC-400XS”. 2023. Accessed: December 1, 2023.  Available at:
  17.  Innoflight. [Online] “CFC-400XP”. 2023. Accessed: December 1, 2023.  Available at:
  18.  KP Labs. [Online] “Antelope” datasheet. Available at:
  19.  KP Labs. [Online] “Leopard” datasheet. Available at:
  20.  KP Labs. [Online] “Lion” datasheet. Available at:
  21. Laboratory for Atmospheric and Space Physics, University of Colorado, Boulder. [Online] “State-of-the-art small satellite technology”. Accessed December 1, 2023. Available at:
  22.  Novo Space. [Online] “SBC002AV”. Accessed: December 1, 2023. Available at:
  23.  Novo Space. [Online] “SBC003AV”. Accessed: December 1, 2023. Available at:
  24.  Novo Space. [Online] “SBC004AV”. Accessed: December 1, 2023. Available at:
  25.  Novo Space. [Online] “SBC005AV”. Accessed: December 1, 2023. Available at:
  26.  Novo Space. [Online] “GPU001AF – General purpose GPU”. Accessed: December 1, 2023. Available at:
  27.  Novo Space. [Online] “GPU002AF – General purpose GPU”. Accessed: December 1, 2023. Available at:
  28.  Resilient Computing. [Online] “Technology: RadPC – Radiation Tolerant Computing.” Accessed: December 1, 2023. Available at:
  29. SkyLabs. [Online] “NANOhpc-obc”. Accessed: December 1, 2023. Available at:
  30.  SkyLabs. [Online] “NANOhpm-obc”. Accessed: December 1, 2023. Available at:
  31. SkyLabs. [Online] “TRISAT-R SUCCESSFULLY REACHED THE MEDIUM EARTH ORBIT”. July 14, 2022. Accessed: December 1, 2023. Available at:
  32.  SkyLabs. [Online] “NANOobc-2”. Accessed: December 1, 2023. Available at:
  33.  D. Gačnik. “NANOsky I 2nd-Generation satellite platform for multi-mission constellation projects”. Presented at 5th ESA CubeSat Industry Space Days, June 1-3, 2021. Available at:
  34. Space Products and Innovation. “ULTIPURPOSE ADAPTER GENERIC INTERFACE CONNECTOR (MA61C) Datasheet”. Available at:
  35. Space Products and Innovation. “MULTIPURPOSE ADAPTER GENERIC INTERFACE CONNECTOR (MA61C) Datasheet”. Available at:
  36. Space Products and Innovation. “MULTIPURPOSE ADAPTER GENERIC INTERFACE CONNECTOR (MA61C) cPCI serial space version Datasheet”. Available at:
  37. Spiral  Blue. “Space Edge Computer Datasheet”. April 2023. Available at:
  38. Southwest Research Institute (SwRI). “SINGLE BOARD COMPUTERS”. 2023. Accessed December 1, 2023. Available at:
  39. Spacemanic. “Deep Thought On-board Computer“. 2023. Accessed December 1, 2023. Available at:
  40. Spacemanic. “Eddie Onboard Computer “. 2023. Accessed December 1, 2023. Available at:
  41. Trident Space Electronic Systems. “VERSAL DIGITAL RF TRANSCEIVER” datasheet. September 12, 2023. Available at:
  42. Trident Space Electronic Systems. “ZYNQ ULTRASCALE+ DIGITAL RF TRANSCEIVER” datasheet. September 12, 2023. Available at:
  43. Unibap. [online] “SpaceCloud’s 22 apps aboard the Wild Ride mission verified in orbit”. June 9, 2021. Accessed: December 1, 2023. Available online:
  44. National Academies of Sciences, Engineering, and Medicine. 2018. Testing at the Speed of Light: The State of U.S. Electronic Parts Space Radiation Testing Infrastructure. Washington, DC: The National Academies Press.
  45. M. Wirthlin, “High-Reliability FPGA-Based Systems: Space, High-Energy Physics, and Beyond,” in Proceedings of the IEEE, vol. 103, no. 3, pp. 379-389, March 2015.
  46. NASA. 2020 Technology Taxonomy. [Online] Available at: