Higher score = stronger published engineering criterion for resilient onboard space software.
The constraint set
Space-vehicle onboard software lives under a constraint set that ground systems do not face. Radiation flips bits. Mission lifetimes are measured in years. The compute is older and slower than ground hardware by design — radiation-hardened parts lag commercial silicon by a generation or more. There is no field service. The published research community treats these as foundational — every methodological claim sits on top of them.
Radiation-tolerant compute, partitioned architectures, and hardware-in-the-loop T&E discipline. ML-onboard prototypes have flight precedent for narrow tasks; open-ended autonomy on safety-critical loops remains research.
The radiation environment is not abstract. Single-event upsets (SEU), single-event transients (SET), single-event latch-ups (SEL), and total ionizing dose (TID) each present different failure modes; the GEO and LEO environments differ; the South Atlantic Anomaly produces a measurable upset-rate increase for any LEO asset that crosses it. The publicly available NASA-HDBK-4002 and ESA's ECSS-Q-ST-60-15C codify the engineering vocabulary, and the JEDEC JESD89A test methodology is the open standard for measuring single-event effects in commercial parts. Software architectures that ignore this physics are not credible.
The compute lag is similarly concrete. RAD750 (BAE) and LEON3/4 (Cobham Gaisler) — the two most common rad-hard processors in flight today — operate at clock speeds and IPC budgets that are roughly a decade behind commercial silicon. The newer wave of rad-hard or rad-tolerant parts (Microchip RTPolarFire SoC FPGAs, Boeing High-Performance Spaceflight Computing chiplet program targets) is closing the gap, but software architectures must be sized to what is qualified for flight, not what is on the engineer's laptop. Treating the compute lag as a fixed constraint rather than a temporary inconvenience is the published professional posture.
Fault tolerance in the open literature
The published space-systems literature on fault tolerance has three converging threads. First, hardware-software co-design — error-correcting memory, watchdog timers, voted execution — establishes a baseline. Second, software-only techniques — checkpoint/restore, redundant execution, deterministic replay — extend coverage to the software stack. Third, autonomy-preserving fault recovery, where the spacecraft is expected to continue mission operations through degraded states, is the active research frontier. NASA Goddard, JPL, and several university labs have published systematically on this for the last decade.
The specific software-fault-tolerance techniques worth naming are well documented. N-version programming and recovery blocks (Avizienis, Randell) remain the foundational redundancy patterns. Triple modular redundancy (TMR) at the software level, with diverse implementations and a voting mediator, is common in critical paths. Selective hardening — applying redundancy only to bit-flippable variables that the static analysis identifies as consequential — is the published efficiency move; the SWIFT and CRAFT compiler passes are public examples. Checkpoint-and-rollback systems integrated with the flight executive (cFS, Ada-based systems, or commercial RTOSes like VxWorks 7) handle non-instant recovery.
The autonomy-preserving frontier deserves separate naming. NASA's Autonomous Systems Engineering for Space portfolio and AFRL's published work on onboard fault-management have converged on the model that the spacecraft must hold mission-critical state, downgrade gracefully through pre-defined operational modes, and recover without ground intervention when ground contact is intermittent. The open Goal-Driven Autonomy literature (Aha and colleagues at NRL) and the model-based diagnosis tradition (de Kleer, Williams) provide the methodological vocabulary. The unsolved problem is verification: how to assure that a fault-management policy will produce safe behavior across the combinatorial space of degraded states.
Onboard autonomy and ML
The case for onboard machine learning on space vehicles is well argued in the open literature: downlink bandwidth is precious, latency matters for time-sensitive observations, and tasking efficiency improves when the spacecraft can decide what is interesting before sending it home. The against-case is equally well argued: ML inference is heavy, debuggability is hard, and the failure modes of an ML model on orbit are difficult to characterize from ground. The research community has not converged. Most published prototypes use ML for narrow, well-understood tasks — anomaly detection on telemetry, cloud detection in imagery, target prioritization — rather than open-ended autonomy.
The flight precedents are public and worth naming. NASA's EO-1 spacecraft demonstrated onboard autonomy and target re-tasking through the Autonomous Sciencecraft Experiment in the early 2000s. The Mars Science Laboratory and Mars 2020 rovers have flown AEGIS for autonomous target selection in MAHLI and ChemCam imagery. The Φ-sat-1 ESA CubeSat demonstrated onboard cloud detection on a commercial Intel Movidius Myriad 2 VPU in 2020, and Φ-sat-2 extends the line. CogniSAT-6 from Ubotica and Open Cosmos is a recent commercial onboard-AI demonstrator. None of these is open-ended autonomy; all are narrow tasks with well-characterized failure modes.
The verification gap matters more for ML than for classical software. The published Assurance of AI in Autonomous Systems literature (Kalra and Paddock; subsequent ASTM and SAE working groups) frames the problem in mileage-equivalent terms; the spacecraft analog is operational-hours equivalent. A model whose calibration drifts after a single SEU and whose drift cannot be detected from telemetry is a liability, not a capability. The published methodology — model snapshotting, ground-replayable inference traces, conformal-prediction-style operator-confidence outputs — is consistent with the broader CDAO Responsible AI Toolkit guidance.
Software architecture trends
Component-based and partitioned architectures — cFS from NASA, ARINC-style partitioning in some defense programs, MOSA-aligned bus architectures — are increasingly common in published flight-software designs. The motivation is reusability and certification. The trade-off is that strict partitioning makes some forms of cross-component optimization harder, including some forms of ML deployment. Any responsible offeror in this space has to articulate where in the architecture their software lives and what assumptions it makes about the rest of the bus.
The specific frameworks worth knowing are public. NASA's Core Flight System (cFS) is an open-source, component-based flight software framework with a substantial heritage. F Prime (F') from JPL is the framework underneath Ingenuity and several CubeSats. The Space Plug-and-Play Architecture (SPA) standards and the more recent Open Mission Systems / Universal Command and Control Interface specifications drive interoperability requirements on the defense side. ARINC 653 partitioning, with implementations like Wind River VxWorks 653 and Lynx LynxOS-178, is the certifiability backbone for safety-critical avionics-style separation.
The architectural placement question is what determines what an offeror can actually deliver. Software that lives inside the flight executive must respect the partitioning rules and the timing budgets the flight software manager has set. Software that lives in a hosted-payload partition has more freedom but tighter resource limits. Software that lives in the ground segment has full freedom but cannot affect onboard behavior in the relevant time horizons. Conflating these is the most common architectural error in proposals.
Test & evaluation in space
The published T&E methodology for space software is dominated by hardware-in-the-loop and software-in-the-loop simulation. Ground testing cannot fully reproduce the orbital environment, and on-orbit anomalies are difficult and expensive to investigate. The literature on simulation fidelity for flight-software T&E is thin compared to ground domains, which is itself a research opportunity. Software-first small businesses can earn credibility here by building evaluation harnesses before models.
The specific tools and patterns are well-documented. NASA's 42 spacecraft simulator (open source from NASA Goddard) and JPL's Dynamics Simulator for Entry, Descent, and Surface (DSENDS) anchor the public open-source side. NOS3, Trick, and the Basilisk astrodynamics framework are widely used. Fault-injection campaigns — both in HIL and in pure SIL — are published methodology for stressing fault-management code paths; the open SAFE-FP and similar academic frameworks provide reproducible patterns. The published methodology consistently emphasizes that fault-injection coverage matters more than aggregate test count.
Where the SBIR money goes
USSF and SpaceWERX have publicly stated priorities in resilience, autonomy, and rapid mission operations. The published Phase I and Direct-to-Phase-II programs in this area tend to share a structure: a specific operational shortfall, a target compute platform, and a clearly identified transition sponsor inside the relevant program office. Offerors who treat all three seriously — and especially the third — have higher transition rates than offerors who treat the SBIR as a research grant.
The named program offices that pull on space software in 2026 — Space Systems Command (SSC), Space Rapid Capabilities Office (SpaceRCO), Space Development Agency (SDA) for the Proliferated Warfighter Space Architecture, AFRL/RV in Albuquerque, and the various USSF Field Commands — have publicly distinct buying patterns. SDA buys at scale on a roughly two-year tranche cadence and rewards software that integrates cleanly with the Tranche 1 / Tranche 2 architecture. SSC buys with longer programmatic horizons. AFRL/RV funds research-flavored work earlier in the technology readiness level. Knowing which sponsor matches a given proposal scope is the first transition decision.
Public Reference Anchors a Reader Should Know
NASA-HDBK-4002 / ECSS-Q-ST-60-15C / JEDEC JESD89A. The public radiation-effects engineering and qualification standards.
NASA cFS, F Prime, NOS3. The open-source flight-software frameworks that anchor most public discussion of architecture.
NASA NPR 7150.2 / DO-178C. The public software-engineering process standards for civil and aviation-derived programs.
SDA Tranche public architecture documents. The proliferated-LEO architecture's published interface specifications and bus-vendor guidance.
Why this work matters to us
Precision Federal is a software-only SBIR firm. The reason articles like this one exist on this site is simple: federal program offices fund teams whose principal investigators have demonstrated, in public, that they think carefully about the problems the program is trying to solve. We write to demonstrate that posture, not to telegraph any particular technical approach. If your office is exploring the problem class above and wants a partner who reads the literature, codes the prototypes, and ships under a Phase I or Direct-to-Phase-II SOW, we are listening.
Common questions on the public-record framing
Where do ML and traditional flight software meet?
Narrow ML tasks (anomaly detection on telemetry, cloud detection in imagery, target prioritization) have flight precedent; open-ended autonomy on safety-critical control loops does not.
How is space T&E methodology different from terrestrial?
Hardware-in-the-loop and software-in-the-loop simulation dominate because on-orbit anomalies are expensive to investigate. The simulation-fidelity literature for flight software is thinner than for ground domains.
What does this article not cover?
Specific spacecraft mission designs, specific platform vulnerabilities, or any Precision Federal architectural approach.
Public flight-software architecture references
| Reference | Origin | Use |
|---|---|---|
| NASA cFS | NASA Goddard, open-source | Component-based flight-software framework |
| F´ framework | JPL, open-source | Small-spacecraft flight-software framework |
| ARINC 653 | Avionics standards | Time and space partitioning |
| MOSA | OSD-mandated framework | Modular Open Systems Approach for new starts |
| HIL/SIL | Trick, Basilisk, NOS3 | Hardware- and software-in-the-loop testing |
Frequently asked questions
Radiation flips bits. Mission lifetimes are measured in years. The compute is older and slower than ground hardware by design — radiation-hardened parts lag commercial silicon by a generation or more. There is no field service. The published research community treats these as foundational.
Component-based and partitioned architectures — including NASA cFS, ARINC-style partitioning in some defense programs, and MOSA-aligned bus architectures. The motivation is reusability and certification; the trade-off is that strict partitioning makes some forms of cross-component optimization harder, including some forms of ML deployment.
Hardware-in-the-loop and software-in-the-loop simulation dominate the published T&E methodology. Ground testing cannot fully reproduce the orbital environment. The literature on simulation fidelity for flight-software T&E is thin compared to ground domains, which is itself a research opportunity.
Publicly stated priorities are resilience, autonomy, and rapid mission operations. Phase I and D2P2 programs in this area tend to share a structure: a specific operational shortfall, a target compute platform, and a clearly identified transition sponsor inside the relevant program office.