Flight software

Flight software has to run the vehicle’s sensing, actuation, fault response and command execution on a processor that is slow by ground standards, with memory that cannot be inspected or replaced, behind a communications link that gives a few tens of minutes of uplink per sol at a few kilobits per second. A surface rover cannot be reset by a technician, and a lost command cycle can cost days of mission time. Across NASA Mars surface missions, 48 major anomalies (four or more consecutive sols of lost progress) took 11 percent of prime mission duration, and software accounts for 11 of them and computer hardware for 8 [21].

Design space

Four design choices recur: the processor and operating system, the software architecture or framework, the scheduling model, and the means of changing the software after launch.

Processor and operating system. Radiation tolerance and flight heritage have held the processor class to a few generations behind the commercial state of the art. The MER flight software ran as 97 prioritized VxWorks tasks over 93 modules and roughly 300,000 source lines of C [1]. Pathfinder’s 1997 resets came from a priority inversion in that same task model, on a bus-management cycle of 8 Hz, and took under 18 hours to reproduce in the laboratory once the cause was suspected [2]. Real-time executives other than VxWorks are used on smaller vehicles; RTEMS context-switch overhead and interrupt latency were measured on an ERC32 at 12 MHz for that reason [12]. Commercial multicore and Linux-class parts are the other direction: Perseverance runs its onboard global localization on a Snapdragon 801 in the Ingenuity base station [24], and benchmarks of Mars 2020 vision processing and the GFOLD divert solver on next-generation processors address the same gap [29]. Multiprocessor designs for fault tolerance without radiation-hardened parts have been proposed and ground-tested, not flown on a surface vehicle [27]. See Flight computers and RTOS.

Architecture and frameworks. Two open frameworks cover most of the reuse. The core Flight System (cFS) is a layered executive and application set; on the Global Precipitation Measurement observatory it made up 42 percent of flight software lines and about 35 percent of the most constrained memory, and an estimate for rewriting the suite for a Class B mission is 49 person-years [9]. F Prime is a component and port framework: ASTERIA’s flight software had 54 component types in 93 instances, 17 of them inherited unmodified [10]. On Ingenuity about 60 percent of the code was auto-generated by F Prime and about 20 percent was unique to the helicopter [11]. As of a 2024 briefing, F Prime is C++ 11 with generated boilerplate and fully supports embedded Linux, x86_64, arm, aarch64 and bare-metal microcontrollers with hardware-in-the-loop testing, while VxWorks 7, RAD750 and RISC-V are roadmap items; Lunar Flashlight flew it and performed one in-flight update in January 2023, and its self-assessment lists time and space partitioning as not supported out of the box [34]. A survey of six frameworks for small spacecraft compares cFS, F Prime-class alternatives and others on portability and process, not on measured flight performance [23]. Robotic autonomy architectures such as CLARAty layer a decision layer over a functional layer and were validated on rover testbeds and flown in part [28]. See Core Flight System.

Scheduling. Hard-real-time guarantees rest on the fixed-priority and deadline-driven schedulability bounds of 1973 [13]. The onboard activity scheduler is a second, slower layer: the Mars 2020 design replaced a 6-minute fixed-cadence baseline with event-driven invocation, flexible execution and a 1-minute commit window, after simulation on a workstation surrogate of the RAD750 scheduler [14]. Parallel execution is the other scheduling gain: by sol 570 Perseverance had accumulated 329 hours 52 minutes of parallel activity, about 30 to 35 minutes per sol, and testbed runs showed Mastcam-Z video commanded in parallel with communication window preparation completed only 16 to 19 Mb of data against 385 Mb with nothing in parallel, so CPU contention and flight software priority bind rather than the plan [33]. EO-1’s CASPER planner is the documented price of onboard planning on a small processor: 4 MIPS of an 8 MIPS machine and 40 MB of memory, with the code image cut from 12 MB to 5 MB for flight [15]. See Timing and scheduling.

Fault tolerance in the software. The hardware-voted and software-voted computers of the 1960s to 1980s set the vocabulary: JPL-STAR with self-testing and repair [17], and SIFT, which put redundancy management in software across independent processors [18]. The dependability taxonomy of faults, errors and failures from the wider computing literature is the common terminology [31]. On Mars the redundancy is a pair of flight computers with one prime, and the software on top is a fault-protection engine that arbitrates more than 1000 monitors [25]. Partitioned (ARINC 653 style) architectures are proposed for reuse and containment of faults, not flown on a surface rover [26].

What changed and what it enabled

Early flight software was written once and flown. Since MER, rovers have had their flight software replaced in flight: MER completed two full loads and one patch, a full load needing about 8 MB of uplink and the February 2005 patch about 2 MB, at about 15 minutes of UHF pass at about 1000 bits per second [6]. MSL has had nine full updates and cold patches between sol 1 and sol 2960; a release binary is about 10 MiB in 49 files [5]. The Spirit sol 18 reboot loop was a flash file system directory limit and cost 15 sols [3][21]. The Curiosity sol 200 anomaly was uncorrectable errors in commercial NAND flash, with a swap to the backup computer commanded 16 hours after the first error message and 35 days of margin before solar conjunction [4]. R-Hope, a special build that moves the non-volatile file system from NAND to 64 MB of NOR, restored the failing computer as a backup, with a 99 percent reduction in file system volume [5].

Updates change capability as well as repair defects. Ingenuity’s Release 8.0 added landing hazard detection at 3 Hz and a digital elevation map in the navigation filter, with a measured waypoint miss of about 3 m on one leg; it also introduced a defect in which landing sites inside 500 Hz packets were discarded as stale, patched in Release 8.1 [16]. A hot patch to Curiosity’s arm kinematics is the corresponding rover case [30]. Code volume grew with this: the Mars rover missions’ flight software size growth and the NASA multi-center study of flight software complexity both point to rising size and the cost of verification [7][8]. See Onboard software update.

Specifics

Subsystem concern	Representative flown evidence	Status
Preemptive tasks on VxWorks, RAD6000 and RAD750	MER, MSL, Mars 2020 [1][7]	Flown
Open component frameworks	cFS on GPM, F Prime on Ingenuity [9][11]	Flown
Flexible execution and event-driven scheduler	Mars 2020 onboard scheduler [14]	Flown; evaluated by simulation
Onboard planner on a small processor	CASPER on EO-1 [15]	Flown in Earth orbit
Software update after landing	MER, MSL, Ingenuity [6][5][16]	Flown
Commercial processors for localization	Snapdragon 801 on Mars 2020 [24]	Flown
Dependable multiprocessor cluster	ST8 concept [27]	Ground-tested
Partitioned operating system	ARINC 653 study [26]	Proposed

Verification of flown autonomy software, from the Deep Space 1 Remote Agent to the Mars 2020 onboard scheduler, rested on testing and informal methods; formal methods were mostly limited to static analyzers, with SPIN model checking of the Remote Agent executive and of MSL flight software as the exceptions [35]. For distributed spacecraft, a hybrid event-driven simulator that runs compiled flight software with modeled scheduling and heap use reported a 7,500x faster-than-real-time speedup over 33 months of use on two in-house packages, in Earth orbit only [32]. Defect data bound what testing can find. Of 199 critical post-launch anomaly reports on seven JPL spacecraft, 41 percent were triggered by data access or delivery problems, and roughly a third by rare events that led to new fault-protection requirements [20]. The history of NASA flight computing is in [19]; the programming interfaces of ROS-based research frameworks, used on research rovers and not on flight vehicles, are in [22].

What is not established

The corpus holds no processor utilization or timing margin for Ingenuity’s Release 8.0, so the cost of the added capability is not stated [16]. The Mars 2020 scheduler results come from a workstation surrogate and assumed, not measured, onboard runtimes [14]. The cFS memory footprint is a single mission build, so its generality to other processors is not established [9]. The comparative framework survey does not rest on flight measurements [23]. The flash fatigue projection for Mars 2020 rests on one flight-like qualification sample [4]. Multicore and Linux-class flight computing beyond the Ingenuity base station has no surface-mission flight record in the held sources.