Skip to content
Space Robotics

Timing and Scheduling

A planetary rover runs a motor control loop measured in tens of milliseconds and a perception step measured in minutes on the same processor. How those coexist is a scheduling problem that has been solved differently on each vehicle, and the solution determines the drive rate.

The problem has three layers. The operating system decides which task runs when, and nearly every flown planetary system uses a fixed-priority preemptive kernel [19][18]. A flight software framework decides how periodic work is released and how tasks exchange messages [20][22]. Above both, an onboard planner or scheduler decides which activities run at all, with its own runtime, which is itself a timing cost [14]. The sections below cover each layer, then the mechanisms that overlap slow computation with fast control, then what has flown against what has been shown only in simulation or on the ground.

Analytical foundation

Section titled “Analytical foundation”

Liu and Layland derived the schedulability conditions that fixed-priority designs inherit [12]. For a single processor and periodic tasks, a rate-monotonic assignment guarantees all deadlines when utilization is at most m(2^(1/m) - 1) for m tasks, which is 0.83 for two tasks and falls toward ln 2, about 0.69, as m grows. A deadline-driven (earliest deadline first) assignment is feasible up to 100 percent utilization, and a mixed scheme with one fixed-priority task reached 98.3 percent in the worked example, against a 78.3 percent case shown infeasible [12]. The result explains why flown systems keep processor headroom; MER caps autonomy software at 75 percent of the RAD6000 [3]. Mars 2020 flight software uses VxWorks priority preemptive scheduling with rate-monotonic priority assignment across instrument, mobility, sampling and communication activities [18].

Pathfinder is the standard case of what the analysis does not cover. A low-priority meteorological task held an information bus mutex, a medium-priority communications task preempted it, and the high-priority bus management task blocked until the watchdog reset the computer [13]. The account circulated as a 1997 email summary of a vendor keynote, and is a secondary source on the mechanism [13]. The 1553 deadline check described below is the primary-source side of the same event [2].

The fast end

Section titled “The fast end”

MER and MSL surface software is built around an 8 Hz tick [1]. The MER cruise attitude control task carries an 8 Hz rate requirement, and several tasks wait on the 8 Hz time event, with task priority alone deciding the order in which they execute after it arrives [1]. On Curiosity, Traction Control evaluates the commanded speed of each of the six drive wheels at 8 Hz, and its high rate downlink products are collected at that rate; drive telemetry for the sol 1646 and sol 1662 checkout drives was logged at 64 Hz [8].

There are no rate groups. A task with a rate requirement subscribes to the timer module, which delivers a message at the required interval into a higher-priority queue than the task’s command queue, so periodic work runs before commands within the same task and commands execute in the gaps between time events [1]. Tasks with no rate requirement are purely event driven and never poll [1].

The Pathfinder 1553 bus cycle is the sharpest published deadline in this family [2]. Its timeline repeats every 0.125 s: bus hardware starts on the 8 Hz boundary using transactions set up by the previous cycle, the distribution task wakes when traffic completes and distributes the data, then the scheduler task wakes and sets up the next cycle. The scheduler is the highest priority task in the system apart from the VxWorks tExec task, the distribution task third, and each checks every cycle that the other completed [2]. Failure of that check is a hard deadline miss, and the response is a computer reset. The hardware inherited from Cassini imposed the 8 Hz rate, and the software architecture followed from it [2].

The slow end

Section titled “The slow end”
StepVehicleProcessorTime
Visual odometry tracking stepSpirit, Opportunity20 MHz RAD6000up to about 3 minutes
Autonomous navigation pause per stepSpirit, Opportunity20 MHz RAD6000about 120 s
Autonomous navigation pause per stepCuriosity133 MHz RAD750about 120 s
Autonomous navigation pause per stepPerseverance133 MHz RAD750 plus Virtex-5 FPGAtypically 0 if not steering
Single ACE pose evaluationPerseverance class133 MHz RAD750, 10 cm DEM10 to 15 ms
Single ACE pose evaluationAthena roverNVIDIA Jetson TK111.2 microseconds
Plane fit, 200 points, for comparisonAthena roverNVIDIA Jetson TK168.2 microseconds
Global localization against orbital imageryPerseveranceSnapdragon 801, four cores at 2.36 GHzabout 32 s

Sources: [3] for MER visual odometry, [4] Table 1 for the navigation pauses, [6] for ACE, [7] for global localization.

At most 75 percent of the MER RAD6000 is available to autonomy software during normal operations, and telemetry processing can take more than the remaining quarter [3]. A three minute stereo and visual odometry step has to fit in that budget alongside the 8 Hz mobility work [3]. On MER and MSL the vehicle stops: the rover drives a step, halts, thinks for about two minutes, and drives again [4].

Making the slow step overlap the fast one

Section titled “Making the slow step overlap the fast one”

Three different mechanisms have been flown or demonstrated to remove that stop.

Thinking While Driving, developed for Curiosity from 2015, starts the next drive step immediately after image capture so that the motion estimate is computed while the wheels turn [11]. On the flight-like engineering model, nine runs averaged 51.5 m/h without it and 77.5 m/h with it [11]. The cost is localization latency: a large slip is not detected until two 1 m steps have completed rather than one.

Moving the work off the general purpose processor. Perseverance’s Vision Compute Element is a second RAD750 board carrying a Xilinx Virtex-5QV FPGA that runs stereo correlation and visual odometry image processing at 22 million disparities per second, processing about six times as many pixels per step as Curiosity in less time [4]. For the first time the autonomous drive rate is set by the wheel drive motor rotation rate rather than by sensing or computing [4].

Moving the work to a co-processor with a different operating system. When Ingenuity is not flying, its base station Snapdragon 801 is available to Perseverance as a co-processor [7]. The performance and reliability figures are opposed:

Perseverance RAD750Heli Base Station Snapdragon 801
CPU133 MHz x24 cores at 2.36 GHz
Memory128 MiB ECC RAM1.55 GiB non-ECC RAM
Storage2 GB validated ECC32 GB unvalidated ECC
Operating systemVxWorks 6.7Linux 3.8
AcceleratorsFPGA on the Vision Compute ElementGPU, DSP
Radiation hardenedyesno
Simulated upsets per device per day13, corrected4313, uncorrected

Source: [7], Table 1. The division of labor that follows is that the RAD750 handles critical real-time processing and the Snapdragon runs computationally intensive programs that can be verified independently and run offline. Global localization takes about 32 s of Snapdragon time against an order of magnitude longer on the RAD750, and it was given 0.5 GB of memory, more than the RAD750 has available at all [7]. Most of the wall clock cost is not computation: transferring images and metadata from the Rover Compute Element to the base station over a 10 KB/s serial link takes 30 minutes, which is tolerable only because it runs in parallel with other rover activities.

Scheduling isolation on the co-processor is deliberately primitive: the Linux change-root call for file system isolation, and ulimits, chrt and taskset for resource isolation, chosen over Docker or LXC to avoid uplinking additional software or interfering with Ingenuity operations. It was tested against deliberately malicious code including memory leaks, segmentation faults, thread bombs and file system erasure [7]. Radiation is handled by running the algorithm twice with a reboot between the runs and comparing results, with a 3 minute timeout on each localization run and 1.5 minutes for the reboot [7].

Planning cycles and overthinking

Section titled “Planning cycles and overthinking”

Perseverance’s Enhanced AutoNav plans while the vehicle is moving, and the timing question becomes whether a solution is found before the current maneuver ends. If it is not, the rover has to stop, which the developers call overthinking; it lowers the average traverse rate, adds wear to wheels and brakes, and raises mission risk [5]. The metric is the number of Approximate Clearance Evaluation calls per planning cycle, and the overthink threshold is 275 calls, which at 10 to 20 ms per call is 3 to 4 s of computation [5]. The ACE table row above gives 10 to 15 ms for a 10 cm DEM [6]. Evaluating the whole baseline tree of 1694 candidate paths at 25 cm intervals would call ACE more than 22,000 times and take over 3 minutes [5]. In simulation, replacing the path ranking heuristic with a learned one cut the overthink rate on complex terrain from 20.0 percent to 7.1 percent, and a hand-designed convolution heuristic cut it to 14.2 percent with a margin of error of 2.5 percent [5].

ACE exists because its predecessor’s cost is not bounded. Fitting a rover-sized plane to terrain, the basis of GESTALT, is an approximation whose cost varies, and full articulated suspension settling by iterative nonlinear optimization is described as intractable on a RAD750 [6]. ACE has a closed form, so its computation time is constant regardless of terrain pattern, which is what makes a per-cycle call budget meaningful.

Onboard planners and schedulers

Section titled “Onboard planners and schedulers”

Above the task level, an onboard scheduler turns a ground plan into a timeline and adapts it when activities finish early or late. Remote Agent, designed for Deep Space One, combined onboard planning and scheduling, a smart executive and model-based fault diagnosis [26]. Its batch scheduler operated for about 48 hours in the 1999 experiment, a duration quoted in the related work of the Mars 2020 scheduler paper [15].

Mars 2020 runs a one-shot, non-backtracking, priority-first scheduler on a 200 MHz RAD750 with 256 MB of RAM [14]. The ENav and co-processor sources give the rover computer as a 133 MHz RAD750 [4][7]; the sources disagree on the clock rate. The scheduler runtime is the central timing quantity. The first baseline invoked it on a fixed 6 minute cadence with a duty cycle of 3.5 of every 6 minutes, which forced a low software priority [14]. The flight design invokes it on events, with a predicted worst-case runtime, the commit window, of 1 minute, and applies Extended Veto flexible execution so that execution can adapt inside the scheduler’s own runtime [14]. In 40 simulation runs across 8 sol types with activities averaging 72 percent of predicted duration, the final design gained 14 minutes of makespan over the 5 minute fixed-cadence baseline, about 4.6 percent of the 5.1 hour average awake time [14]. The 72 percent figure rests on MSL data in which activities ran 28 percent shorter than predicted [14]. A workstation surrogate scheduler is about 100 times faster than the flight hardware, an anecdotal ratio, so flight runtime is scaled rather than measured [15]. The execution layer is required to respond at 1 Hz, which is one reason the project rejected temporal-flexibility schemes with high verification cost [15]. Activity priority and preferred-start parameters are set by Monte Carlo Parameter Search, which averaged 0.762 activities short of a perfect schedule against 1.539 for expert-set static priorities across the sol-type sweeps, in simulation [16]. The ground scheduler, Copilot, shares the same priority-first core and is used with an explainability tool for operators [17].

Ground-side automated scheduling has a flown record where onboard scheduling does not. ASPEN-RSSC scheduled Rosetta science campaigns across 35 Medium Term Plans, with plans of 600 to over 2000 activities, and a greedy run on a 2000-activity plan took about 20 minutes, with more than 75 percent of runtime in pointing and slew computation [25].

Concurrency across activities

Section titled “Concurrency across activities”

Priority preemption lets activities overlap on one processor, and operations had to learn which overlaps are safe [19]. MSL’s Parallelism Matrix became on Mars 2020 an active process that tests, approves and tracks permitted concurrent activities [18]. By sol 570 the rover had accumulated 329 hours 52 minutes of parallel activity, about 30 to 35 minutes per sol [18]. CPU contention is the limit. On the Vehicle System Testbed, Mastcam-Z data product autocompletion handled 285 Mb with parallel imaging against 385 Mb with nothing in parallel, and 16 to 19 Mb with parallel video commanding [18]. UHF window preparation takes 7 minutes per pass, so overlap with science recovers tens of minutes per sol [18].

Fault protection adds timers the scheduler cannot ignore. MER uses watchdog refreshes that force a reboot when missed after wakeup, and an Opportunity wakeup alarm set during deep sleep was delayed past its scheduled time by a dust storm, leaving all sequences deactivated [27]. After a fatal exception, uplinks through Odyssey were limited to 25 sequences with null padding between them to reduce processor contention [27].

Rotorcraft and frameworks

Section titled “Rotorcraft and frameworks”

Ingenuity’s navigation processor ran at up to 60 percent utilization across four cores in a typical flight, the upper bound observed [23]. Its Release 8.0 flight software update generated a landing hazard map at 3 Hz on the navigation computer and folded a digital elevation map into the vision navigation filter [24].

Reusable frameworks fix the scheduling model for a mission class. The core Flight System uses a publish and subscribe messaging layer over an operating system abstraction layer, a choice made in an architecture trade at Goddard [21]. The Global Precipitation Measurement build is the measured case: cFE is 12,930 logical lines and 341,561 bytes of EEPROM, and the suite occupied about 35 percent of a 2 MB EEPROM bank [20]. Estimated effort to develop cFS from scratch for a Class B mission was 49 person-years against about 2 for adoption [20]. F Prime flew on Lunar Flashlight, which performed an in-flight software update in January 2023, and is assigned to the CADRE rovers; the framework does not support time and space partitioning out of the box, by its own assessment [22]. A survey of six frameworks against CubeSat criteria compares them on flight heritage and footprint [30]. NASA’s flight software complexity study found growth in size and complexity across missions and recommended architectural controls [31].

Verification of timing

Section titled “Verification of timing”

Timing faults are found by test environments that run the real software against modeled hardware. Cassini used the same test methodology from before launch through twenty years of operations, across an all-software faster-than-real-time simulator and hardware-bearing test beds [32]. An event-driven simulator that runs compiled flight software with modeled scheduling, I/O and heap ran 7500 times faster than real time and exposed a 50 MB dynamic memory exhaustion defect on VISORS GNC; this is simulation evidence, not flight [29]. In-flight modification of the timing-critical software is itself scheduled: a MER full load is about 8 MB, a patch about 2 MB, and the commanded cold boot leaves the rover down 15 minutes [28].

Scheduling below the task level

Section titled “Scheduling below the task level”

Not all timing is task scheduling. MER camera exposure is specified in units of 5.1 ms [9]. The imaging chain uses two queues per priority level, one for mast-mounted cameras and one for body-mounted, and hands each image to a separate post-processing task as soon as its pixels are read so that the camera control task can start the next exposure, with the result that image acquisition order cannot be predicted from command order. Fault protection is polled rather than interrupt driven: the MSL engine periodically polls monitor states and maps a monitor that has turned red to a system response, and monitors use persistence counts so that a single bad reading does not trip a response [10].

What is not established

Section titled “What is not established”

The Pathfinder priority inversion mechanism is documented here through a secondary account [13]. The Mars 2020 scheduler figures are simulation results with a scaled flight runtime; no published measurement of onboard scheduler runtime on Perseverance is held [14][15][16]. Thinking While Driving and the overthinking rates come from an engineering model and simulation [11][5]. The Snapdragon co-processor timings are for localization only [7]. F Prime partitioning and cFS timing configuration have not been compared on a common workload [22][20]. Worst-case execution time measurements for flight tasks are not published in the held sources.

References

  1. Reeves, G. E. (2005). An Overview of the Mars Exploration Rovers Flight Software . IEEE International Conference on Systems, Man and Cybernetics. Source
    BibTeX
    @inproceedings{reeves2005overview,
  title = {An Overview of the Mars Exploration Rovers Flight Software},
  author = {Reeves, Glenn E.},
  booktitle = {IEEE International Conference on Systems, Man and Cybernetics},
  volume = {1},
  pages = {1-7},
  address = {Waikoloa, Hawaii},
  year = {2005},
  doi = {10.1109/icsmc.2005.1571113},
  abstract = {The Mars exploration rovers (MER) flight software (FSW) is possibly the most complex software implementation to be deployed on another planet. The requirements dictated a software system that addressed four distinct mission phases (cruise, landing, egress, and surface) and the mission demanded a system with significant autonomy. The structure of the MER flight software reflects its object-oriented beginnings and the overall function reflects the requirements of the MER mission and spacecraft. This paper provides an overview of the function and structure of the MER flight software. The MER mission and spacecraft are briefly discussed to provide context for the flight software decomposition and the discussion of the software execution model.}
}
  2. Reeves, G. E. (1997). What really happened on Mars? Authoritative Account. cs.unc.edu/~anderson/teach/comp790/papers/mars_pathfinder_long_versio...
    BibTeX
    @misc{reeves1997what,
  title = {What really happened on Mars? Authoritative Account},
  author = {Reeves, Glenn E.},
  organization = {Jet Propulsion Laboratory},
  year = {1997},
  url = {https://www.cs.unc.edu/~anderson/teach/comp790/papers/mars_pathfinder_long_version.html}
}
  3. Maimone, M. W., Leger, P. C. and Biesiadecki, J. J. (2007). Overview of the Mars Exploration Rovers' Autonomous Mobility and Vision Capabilities . IEEE International Conference on Robotics and Automation, Space Robotics Workshop. Source
    BibTeX
    @inproceedings{maimone2007overview,
  title = {Overview of the Mars Exploration Rovers' Autonomous Mobility and Vision Capabilities},
  author = {Maimone, Mark W. and Leger, P. Chris and Biesiadecki, Jeffrey J.},
  booktitle = {IEEE International Conference on Robotics and Automation, Space Robotics Workshop},
  address = {Rome, Italy},
  year = {2007},
  url = {https://www-robotics.jpl.nasa.gov/media/documents/mer_autonomy_icra_2007.pdf}
}
  4. Rankin, A., Del Sesto, T., Hwang, P., Justice, H., Maimone, M., Verma, V. and Graser, E. (2023). Perseverance Rapid Traverse Campaign . IEEE Aerospace Conference. Source
    BibTeX
    @inproceedings{rankin2023perseverance,
  title = {Perseverance Rapid Traverse Campaign},
  author = {Rankin, Arturo and Del Sesto, Tyler and Hwang, Pauline and Justice, Heather and Maimone, Mark and Verma, Vandi and Graser, Evan},
  booktitle = {IEEE Aerospace Conference},
  pages = {1-16},
  address = {Big Sky, Montana},
  year = {2023},
  doi = {10.1109/aero55745.2023.10115835},
  abstract = {Over the first 13 months of the Mars 2020 mission, the Perseverance rover traversed nearly 5 km along the Jezero Crater floor. Near the end of that period, the Science team was anxious to relocate to the ancient Delta region near the crater rim, over 5 km away. A Rapid Traverse Campaign was planned that would prioritize use of Perseverance's autonomous navigation software to drive at an unprecedented high pace and minimize science activities. The Rapid Traverse Campaign started in March 2022 and lasted 31 Martian days. During the campaign, Perseverance drove over 5 km in 24 drives, during which its autonomy software planned 94.8% of its overall driving, enabling it to set several new planetary rover driving records. Perseverance exceeded the longest daily drive distance record achieved by a previous planetary rover (219 meters) 11 times and set new records for the longest multi-sol drive distance in a single plan (528.7 meters) and the longest continuation drive (699.9 meters) by operating without human drive path input during 3 sols of driving. This paper details the planning and execution of the Rapid Traverse Campaign.}
}
  5. Abcouwer, N., Daftry, S., Del Sesto, T., Toupet, O., Ono, M., Venkatraman, S., Lanka, R., Song, J. and Yue, Y. (2021). Machine Learning Based Path Planning for Improved Rover Navigation . IEEE Aerospace Conference. Source
    BibTeX
    @inproceedings{abcouwer2021machine,
  title = {Machine Learning Based Path Planning for Improved Rover Navigation},
  author = {Abcouwer, Neil and Daftry, Shreyansh and Del Sesto, Tyler and Toupet, Olivier and Ono, Masahiro and Venkatraman, Siddarth and Lanka, Ravi and Song, Jialin and Yue, Yisong},
  booktitle = {IEEE Aerospace Conference},
  pages = {1-9},
  address = {Big Sky, Montana},
  year = {2021},
  doi = {10.1109/aero50100.2021.9438337},
  abstract = {Enhanced AutoNav (ENav), the baseline surface navigation software for NASA's Perseverance rover, sorts a list of candidate paths for the rover to traverse, then uses the Approximate Clearance Evaluation (ACE) algorithm to evaluate whether the most highly ranked paths are safe. ACE is crucial for maintaining the safety of the rover, but is computationally expensive. If the most promising candidates in the list of paths are all found to be infeasible, ENav must continue to search the list and run time-consuming ACE evaluations until a feasible path is found. In this paper, we present two heuristics that, given a terrain heightmap around the rover, produce cost estimates that more effectively rank the candidate paths before ACE evaluation. The first heuristic uses Sobel operators and convolution to incorporate the cost of traversing high-gradient terrain. The second heuristic uses a machine learning (ML) model to predict areas that will be deemed untraversable by ACE. We used physics simulations to collect training data for the ML model and to run Monte Carlo trials to quantify navigation performance across a variety of terrains with various slopes and rock distributions. Compared to ENav's baseline performance, integrating the heuristics can lead to a significant reduction in ACE evaluations and average computation time per planning cycle, increase path efficiency, and maintain or improve the rate of successful traverses. This strategy of targeting specific bottlenecks with ML while maintaining the original ACE safety checks provides an example of how ML can be infused into planetary science missions and other safety-critical software.}
}
  6. Otsu, K., Matheron, G., Ghosh, S., Toupet, O. and Ono, M. (2020). Fast Approximate Clearance Evaluation for Rovers with Articulated Suspension Systems . Journal of Field Robotics, 5. Source
    BibTeX
    @article{otsu2020fast,
  title = {Fast Approximate Clearance Evaluation for Rovers with Articulated Suspension Systems},
  author = {Otsu, Kyohei and Matheron, Guillaume and Ghosh, Sourish and Toupet, Olivier and Ono, Masahiro},
  journal = {Journal of Field Robotics},
  volume = {37},
  number = {5},
  pages = {768--785},
  year = {2020},
  doi = {10.1002/rob.21892},
  abstract = {Abstract We present a light‐weight body‐terrain clearance evaluation algorithm for the automated path planning of NASA's Mars 2020 rover. Extraterrestrial path planning is challenging due to the combination of terrain roughness and severe limitation in computational resources. Path planning on cluttered and/or uneven terrains requires repeated safety checks on all the candidate paths at a small interval. Predicting the future rover state requires simulating the vehicle settling on the terrain, which involves an inverse‐kinematics problem with iterative nonlinear optimization under geometric constraints. However, such expensive computation is intractable for slow spacecraft computers, such as RAD750, which is used by the Curiosity Mars rover and upcoming Mars 2020 rover. We propose the approximate clearance evaluation (ACE) algorithm, which obtains conservative bounds on vehicle clearance, attitude, and suspension angles without iterative computation. It obtains those bounds by estimating the lowest and highest heights that each wheel may reach given the underlying terrain, and calculating the worst‐case vehicle configuration associated with those extreme wheel heights. The bounds are guaranteed to be conservative, hence ensuring vehicle safety during autonomous navigation. ACE is planned to be used as part of the new onboard path planner of the Mars 2020 rover. This paper describes the algorithm in detail and validates our claim of conservatism and fast computation through experiments.}
}
  7. Verma, V., Nash, J., Saldyt, L., Dwight, Q., Wang, H., Myint, S., Biesiadecki, J., Maimone, M., Tumbar, A., Ansar, A., Kubiak, G. and Hogg, R. (2024). Enabling Long and Precise Drives for the Perseverance Mars Rover via Onboard Global Localization . IEEE Aerospace Conference. Source
    BibTeX
    @inproceedings{verma2024enabling,
  title = {Enabling Long and Precise Drives for the Perseverance Mars Rover via Onboard Global Localization},
  author = {Verma, Vandi and Nash, Jeremy and Saldyt, Lucas and Dwight, Quintin and Wang, Haoda and Myint, Steven and Biesiadecki, Jeffrey and Maimone, Mark and Tumbar, Andrei and Ansar, Adnan and Kubiak, Gerik and Hogg, Robert},
  booktitle = {IEEE Aerospace Conference},
  address = {Big Sky, Montana},
  year = {2024},
  url = {https://www-robotics.jpl.nasa.gov/media/documents/2024_Global_Localization_IEEE_Aero.pdf}
}
  8. Toupet, O., Biesiadecki, J., Rankin, A., Steffy, A., Meirion-Griffith, G., Levine, D., Schadegg, M. and Maimone, M. (2020). Traction Control on the Curiosity Mars Rover: Algorithm and Flight Results . Journal of Field Robotics. Source
    BibTeX
    @article{toupet2020traction,
  title = {Traction Control on the Curiosity Mars Rover: Algorithm and Flight Results},
  author = {Toupet, Olivier and Biesiadecki, Jeffrey and Rankin, Arturo and Steffy, Amanda and Meirion-Griffith, Gareth and Levine, Dan and Schadegg, Maximilian and Maimone, Mark},
  journal = {Journal of Field Robotics},
  year = {2020},
  doi = {10.48577/jpl.hkzuqs},
  abstract = {No abstract available.}
}
  9. Litwin, T. E. and Maki, J. N. (2005). Imaging Services Flight Software on the Mars Exploration Rovers . IEEE International Conference on Systems, Man and Cybernetics. Source
    BibTeX
    @inproceedings{litwin2005imaging,
  title = {Imaging Services Flight Software on the Mars Exploration Rovers},
  author = {Litwin, Todd E. and Maki, Justin N.},
  booktitle = {IEEE International Conference on Systems, Man and Cybernetics},
  volume = {1},
  pages = {895--900},
  address = {Waikoloa, Hawaii},
  year = {2005},
  doi = {10.1109/icsmc.2005.1571260},
  abstract = {The imaging services module of the Mars Exploration Rovers' on-board flight software is responsible for providing image data to the rest of the system. It acquires images from a suite of cameras, performs on-board image processing, labels the results with metadata, and delivers the final products to a diverse set of consumers, both on board and on the ground. The demands for flexibility and speed led to a design involving multiple tasks and a large set of parameters controlling the acquisition of the images, the on-board processing, and the method of product delivery.}
}
  10. Benowitz, E. (2015). The Curiosity Mars Rover's Fault Protection Engine . IEEE International Conference on Space Mission Challenges for Information Technology. Source
    BibTeX
    @inproceedings{benowitz2015curiosity,
  title = {The Curiosity Mars Rover's Fault Protection Engine},
  author = {Benowitz, Ed},
  booktitle = {IEEE International Conference on Space Mission Challenges for Information Technology},
  volume = {111},
  pages = {62-66},
  address = {Big Sky, Montana},
  year = {2015},
  doi = {10.1109/smc-it.2014.16},
  abstract = {The Curiosity Rover, currently operating on Mars, contains flight software onboard to autonomously handle aspects of system fault protection. Over 1000 monitors and 39 responses are present in the flight software. Orchestrating these behaviorsis the flight software's fault protection engine. In this paper, we discuss the engine's design, responsibilities, and present some lessons learned for future missions.}
}
  11. Rankin, A., Holloway, A., Sabel, A., Patel, N. and Maimone, M. W. (2022). Visual Odometry Thinking While Driving for the Curiosity Mars Rover's Three-Year Test Campaign: Impact of Evolving Constraints on Verification and Validation . IEEE Aerospace Conference, 20230005759. Source
    BibTeX
    @inproceedings{rankin2022visual,
  title = {Visual Odometry Thinking While Driving for the Curiosity Mars Rover's Three-Year Test Campaign: Impact of Evolving Constraints on Verification and Validation},
  author = {Rankin, Arturo and Holloway, Alexandra and Sabel, Anna and Patel, Nikunj and Maimone, Mark W.},
  booktitle = {IEEE Aerospace Conference},
  number = {20230005759},
  pages = {1-10},
  institution = {NASA},
  year = {2022},
  doi = {10.1109/aero53065.2022.9843487},
  abstract = {Over the first 9 years of the Mars Science Laboratory (MSL) Curiosity rover's surface mission, more than 87% of its driving was performed using Visual Odometry (VO). The benefits of using VO during driving are that it minimizes rover position uncertainty and can be used to monitor wheel slip, halting a drive if excessive wheel slip is occurring. The VO implementation onboard Curiosity acquires and processes VO images in between drive steps while the rover is stationary. A VO Thinking While Driving (VTWD) flight software capability has been developed to enable the processing of VO images during rover driving, increasing the distance Curiosity can drive using VO during a given time period up to as much as 1.75x total distance. Verification and Validation (V&V) of this capability has been challenging due to impacts from the COVID-19 pandemic and unavailability of the JPL Mars Yard outdoor test site. The VTWD V&Vtest procedures were modified to use a small indoor space with Mars-like terrain. This paper describes the 3 year V&V effort under challenging conditions to approve the VTWD capability for use on the Curiosity rover.}
}
  12. Liu, C. L. and Layland, J. W. (1973). Scheduling Algorithms for Multiprogramming in a Hard-Real-Time Environment . Journal of the ACM, 1. Source
    BibTeX
    @article{liu1973scheduling,
  title = {Scheduling Algorithms for Multiprogramming in a Hard-Real-Time Environment},
  author = {Liu, C. L. and Layland, James W.},
  journal = {Journal of the ACM},
  volume = {20},
  number = {1},
  pages = {46--61},
  year = {1973},
  doi = {10.1145/321738.321743},
  abstract = {The problem of multiprogram scheduling on a single processor is studied from the viewpoint of the characteristics peculiar to the program functions that need guaranteed service. It is shown that an optimum fixed priority scheduler possesses an upper bound to processor utilization which may be as low as 70 percent for large task sets. It is also shown that full processor utilization can be achieved by dynamically assigning priorities on the basis of their current deadlines. A combination of these two scheduling techniques is also discussed.}
}
  13. Jones, M. B. (1997). What really happened on Mars?. cs.unc.edu/~anderson/teach/comp790/papers/mars_pathfinder_short_versi...
    BibTeX
    @misc{jones1997what,
  title = {What really happened on Mars?},
  author = {Jones, Michael B.},
  organization = {Microsoft Research},
  year = {1997},
  url = {https://www.cs.unc.edu/~anderson/teach/comp790/papers/mars_pathfinder_short_version.html}
}
  14. Agrawal, J., Chi, W., Chien, S., Rabideau, G., Gaines, D. and Kuhn, S. (2021). Analyzing the effectiveness of rescheduling and Flexible Execution methods to address uncertainty in execution duration for a planetary rover . Robotics and Autonomous Systems. Source
    BibTeX
    @article{agrawal2021analyzing,
  title = {Analyzing the effectiveness of rescheduling and Flexible Execution methods to address uncertainty in execution duration for a planetary rover},
  author = {Agrawal, Jagriti and Chi, Wayne and Chien, Steve and Rabideau, Gregg and Gaines, Daniel and Kuhn, Stephen},
  journal = {Robotics and Autonomous Systems},
  volume = {140},
  pages = {103758},
  year = {2021},
  doi = {10.1016/j.robot.2021.103758}
}
  15. Chi, W., Chien, S., Agrawal, J., Rabideau, G., Benowitz, E., Gaines, D., Fosse, E., Kuhn, S. and Biehl, J. (2018). Embedding a Scheduler in Execution for a Planetary Rover . International Conference on Automated Planning and Scheduling. Source
    BibTeX
    @inproceedings{chi2018embedding,
  title = {Embedding a Scheduler in Execution for a Planetary Rover},
  author = {Chi, Wayne and Chien, Steve and Agrawal, Jagriti and Rabideau, Gregg and Benowitz, Ed and Gaines, Daniel and Fosse, Elyse and Kuhn, Stephen and Biehl, James},
  booktitle = {International Conference on Automated Planning and Scheduling},
  volume = {28},
  pages = {312--320},
  year = {2018},
  doi = {10.1609/icaps.v28i1.13909},
  abstract = {Scheduling often takes place in the context of execution. This reality drives several key design decisions: (1) when to invoke (re) scheduling, (2) what to do when the scheduler is running, and (3) how to use the schedule to execute scheduled activities. We define these design decisions theoretically in the context of the embedded scheduler and practically in the context of the design of an embedded scheduler for a planetary rover. We use the concept of a commit window to enable execution to use the previously generated schedule while (re) scheduling. We define the concepts of fixed cadence, event driven, and hybrid scheduling to control invocation of (re) scheduling. We define the concept of flexible execution to enable execution of the generated schedule to be adaptive within the response cycle of the scheduler. We present empirical results from both synthetic and planetary rover scheduling and execution model data that documents the effectiveness of these techniques at enabling the scheduler to take advantage of execution opportunities to complete activities earlier.}
}
  16. Chi, W., Agrawal, J., Chien, S., Fosse, E. and Guduri, U. (2019). Optimizing Parameters for Uncertain Execution and Rescheduling Robustness . Twenty-International Conference on Automated Planning and Scheduling. Source
    BibTeX
    @inproceedings{chi2019optimizing,
  title = {Optimizing Parameters for Uncertain Execution and Rescheduling Robustness},
  author = {Chi, Wayne and Agrawal, Jagriti and Chien, Steve and Fosse, Elyse and Guduri, Usha},
  booktitle = {Twenty-International Conference on Automated Planning and Scheduling},
  volume = {29},
  pages = {501-509},
  year = {2019},
  doi = {10.1609/icaps.v29i1.3552},
  abstract = {We describe use of Monte Carlo simulation to optimize schedule parameters for execution and rescheduling robustness in the face of execution uncertainties. We search in the activity input parameter space where a) the onboard scheduler is a one shot non-backtracking scheduler and b) the activity input priority determines the order in which activities are considered for placement in the schedule. We show that simulation driven search for activity parameters outperforms static priority assignment. Our approach can be viewed as using simulation feedback to determine problem specific heuristics e.g. Squeaky Wheel Optimization. These techniques are currently baselined for use in the ground operations of NASA’s next planetary rover, the Mars 2020 rover.}
}
  17. Yelamanchili, A., Agrawal, J., Chien, S., Biehl, J., Connell, A., Guduri, U., Hazelrig, J., Maxwell, K., Steadman, K. and Towey, S. (2020). Ground-Based Automated Scheduling for the Mars 2020 Rover . International Symposium on Artificial Intelligence, Robotics and Automation in Space. Source
    BibTeX
    @inproceedings{yelamanchili2020ground,
  title = {Ground-Based Automated Scheduling for the Mars 2020 Rover},
  author = {Yelamanchili, Amruta and Agrawal, Jagriti and Chien, S. and Biehl, James and Connell, Andrea and Guduri, Usha and Hazelrig, James and Maxwell, Kimberly and Steadman, K. and Towey, Shannon},
  booktitle = {International Symposium on Artificial Intelligence, Robotics and Automation in Space},
  publisher = {JPL Open Repository},
  year = {2020},
  url = {https://dataverse.jpl.nasa.gov/dataset.xhtml?persistentId=hdl:2014/53236}
}
  18. Siegfriedt, R. S., Girerd, A., Hazelrig, J., Gaines, D., Fosse, E., Appakonam, A., Waldram, N., Plave, A. and Rozek, M. (2023). Enabling Parallel Activities for Mars 2020 Rover Surface Operations . IEEE Aerospace Conference. Source
    BibTeX
    @inproceedings{siegfriedt2023enabling,
  title = {Enabling Parallel Activities for Mars 2020 Rover Surface Operations},
  author = {Siegfriedt, Rebekah S. and Girerd, Andre and Hazelrig, James and Gaines, Daniel and Fosse, Elyse and Appakonam, Ashwin and Waldram, Nicholas and Plave, Andrew and Rozek, Matthew},
  booktitle = {IEEE Aerospace Conference},
  address = {Big Sky, Montana},
  year = {2023},
  doi = {10.48577/jpl.obe5e4},
  abstract = {Level 1 requirements levied on the Mars 2020 mission from NASA Headquarters challenged the Mars 2020 surface mission (also known as the Perseverance rover) to perform significantly better relative to the 2012 Mars Science Lab (MSL) surface mission (also known as the Curiosity rover). In one and a quarter Mars years, the Perseverance rover was expected to drive 50 percent farther and collect over twice as many samples as its predecessor, Curiosity. In order to reach these requirements, Mars 2020 came up with five guiding principles, two of which were “Be fast, be flexible: perform flight and ground functions more quickly” and “Do more science: increase the time that the vehicle is actively pursuing science on Mars''. These guiding principles required the mission to lay the groundwork early on for more surface activities to be performed in parallel, such as thinking while driving. Parallelism enabled both direct efficiency gains, such as completing multiple activities simultaneously during a given time frame, and indirect gains, such as increased available energy and better informed tactical planning due to more data being available sooner. These efficiency gains allowed the rover to complete more complex plans and better handle adversity such as data return disruptions. Although the mission planned to test and approve most of the parallel activities in the development phase, limitations on budget, time and personnel drove the majority of parallel activity testing and approvals to occur in the operations phase. Ideally, any activity can run concurrently with any other activity, but constraints such as Electromagnetic Interference (EMI), hardware safety, and resource utilization prevent some activities from running in parallel. In order to coordinate these behaviors on the rover, the mission needed an efficient and streamlined mechanism to manage them on the ground and maximize the amount of time the rover could pursue science on Mars. In response to this challenge, the Mars 2020 Surface Operations Team overhauled a legacy product from MSL called the Parallelism Matrix. Over the course of the primary mission, the Mars 2020 Parallelism Team made the following improvements: established a process to triage untested activity parallelism, enabled automatic updates to the matrix after downlinked data was analyzed, created a thorough testing campaign to investigate and approve untested parallel interactions, and provided a tool to autonomously track executed parallel activities as soon as data hit the ground.This paper will discuss: similarities and differences between the Perseverance and Curiosity missions with respect to maximizing science exploration time, Mars 2020’s new Flight Software (FSW) capabilities that enabled more parallelism, the Surface EMI testing campaign, the Surface Operations Parallelism Working Group efforts, Surface Operations parallelism tools and processes, the current state of parallel activity efforts on Mars 2020, the measurable benefits and achievements of parallelism, and the lessons learned and recommendations for the future.}
}
  19. Nesnas, I. A. (2017). Experiences from planetary autonomy software from research to planetary flight robots. dataverse.jpl.nasa.gov/dataset.xhtml
    BibTeX
    @misc{nesnas2017experiences,
  title = {Experiences from planetary autonomy software from research to planetary flight robots},
  author = {Nesnas, Issa A.D.},
  howpublished = {Presentation at the JPL Open Repository},
  year = {2017},
  url = {https://dataverse.jpl.nasa.gov/dataset.xhtml?persistentId=hdl:2014/48929}
}
  20. McComas, D., Wilmot, J. and Cudmore, A. (2016). The Core Flight System (cFS) Community: Providing Low Cost Solutions for Small Spacecraft . Annual AIAA/USU Conference on Small Satellites. Source
    BibTeX
    @inproceedings{mccomas2016core,
  title = {The Core Flight System (cFS) Community: Providing Low Cost Solutions for Small Spacecraft},
  author = {McComas, David and Wilmot, Jonathan and Cudmore, Alan},
  booktitle = {Annual AIAA/USU Conference on Small Satellites},
  year = {2016},
  url = {https://ntrs.nasa.gov/citations/20160010300},
  abstract = {In February 2015 the NASA Goddard Space Flight Center (GSFC) completed the open source release of the entire Core Flight Software (cFS) suite. After the open source release a multi-NASA center Configuration Control Board (CCB) was established that has managed multiple cFS product releases. The cFS was developed and is being maintained in compliance with the NASA Class B software development process requirements and the open source release includes all Class B artifacts. The cFS is currently running on three operational science spacecraft and is being used on multiple spacecraft and instrument development efforts. While the cFS itself is a viable flight software (FSW) solution, we have discovered that the cFS community is a continuous source of innovation and growth that provides products and tools that serve the entire FSW lifecycle and future mission needs. This paper summarizes the current state of the cFS community, the key FSW technologies being pursued, the development/verification tools and opportunities for the small satellite community to become engaged. The cFS is a proven high quality and cost-effective solution for small satellites with constrained budgets.}
}
  21. Mccomas, D. (2019). The Core Flight System (cFS) Experiences in Opening an Architecture, 20180007319. ntrs.nasa.gov/citations/20180007319
    BibTeX
    @misc{mccomas2019core,
  title = {The Core Flight System (cFS) Experiences in Opening an Architecture},
  author = {Mccomas, David},
  howpublished = {Presentation at the Goddard Space Flight Center},
  number = {20180007319},
  year = {2019},
  url = {https://ntrs.nasa.gov/citations/20180007319},
  abstract = {This presentation presents a software architecture model that contains three perspectives: User, Business, and System. This model is used to evaluate the evolution of the cFS from a NASA/Goddard in-house product line to an open source open architecture used by a world wide community.

}
}
  22. Bocchino, R., Boyer-Chammard, T., Canham, T., Doran, S., Levison, J., Starch, M. and Ortega, K. (2024). F Prime Flight Software Update. doi.org/10.48577/jpl.jwewt9
    BibTeX
    @misc{bocchino2024prime,
  title = {F Prime Flight Software Update},
  author = {Bocchino, Rob and Boyer-Chammard, Thomas and Canham, Tim and Doran, Steven and Levison, Jeff and Starch, Michael and Ortega, Kevin},
  howpublished = {Presentation at the JPL Open Repository},
  year = {2024},
  doi = {10.48577/jpl.jwewt9},
  abstract = {No abstract available.}
}
  23. Tzanetos, T., Aung, M., Balaram, J. (., Grip, H. F., Karras, J. T., Canham, T. K., Kubiak, G., Anderson, J., Merewether, G., Starch, M., Pauken, M., Cappucci, S., Chase, M., Golombek, M., Toupet, O., Smart, M. C., Dawson, S., Blandon Ramirez, E., Lam, J., Stern, R., Chahat, N., Ravich, J., Hogg, R., Pipenberg, B., Keennon, M. and Williford, K. H. (2022). Ingenuity Mars Helicopter: From Technology Demonstration to Extraterrestrial Scout . IEEE Aerospace Conference. Source
    BibTeX
    @inproceedings{tzanetos2022ingenuity,
  title = {Ingenuity Mars Helicopter: From Technology Demonstration to Extraterrestrial Scout},
  author = {Tzanetos, Theodore and Aung, MiMi and Balaram, J. (Bob) and Grip, Håvard Fjær and Karras, Jaakko T. and Canham, Timothy K. and Kubiak, Gerik and Anderson, Joshua and Merewether, Gene and Starch, Michael and Pauken, Mike and Cappucci, Stefano and Chase, Matthew and Golombek, Matthew and Toupet, Olivier and Smart, Marshall C. and Dawson, Stephen and Blandon Ramirez, Erick and Lam, Johnny and Stern, Ryan and Chahat, Nacer and Ravich, Joshua and Hogg, Robert and Pipenberg, Benjamin and Keennon, Matthew and Williford, Kenneth H.},
  booktitle = {IEEE Aerospace Conference},
  pages = {01-19},
  publisher = {IEEE},
  year = {2022},
  doi = {10.1109/aero53065.2022.9843428},
  abstract = {On April 19, 2021, NASA's Ingenuity Mars Helicopter successfully executed humanity's historic first flight on Mars. In the flights that followed, Ingenuity continued to explore the boundaries of what was aerodynamically, energetically, and operationally possible, and took on increasingly daring missions in the process. Over time, Ingenuity's mission has evolved from a “Technology Demonstration” of the first rotorcraft to fly on Mars to an “Operations Demonstration” of scientific aerial exploration scenarios on Mars. Ingenuity's activities to date have yielded a rich first-of-its-kind data set and extensive operational experience. This paper describes the Ingenuity Mars Helicopter's operation and technical performance. It details the approach and considerations involved in remotely operating a rotorcraft on Mars from Earth. It presents the performance of the vehicle in the extremely thin Martian atmosphere compared to predicted design values, based on analysis and testing on Earth. The agreement between predicted and observed performance has been excellent. This paper also discusses scientific impacts that Ingenuity Mars Helicopter has been able to contribute to the Mars 2020 Perseverance mission during Ingenuity's Operations Demonstration phase. The performance of the vehicle, the operational experiences and lessons learned, anomalies encountered and their resolutions presented in this paper critically inform the formulation, design, and development of the next generation of advanced aerial rotorcraft platforms for Mars and other extra-terrestrial bodies.11Copyright 2021 Jet Propulsion Laboratory, California Institute of Technology. Government sponsorship acknowledged.22The research was carried out at the Jet Propulsion Laboratory, California Institute of Technology, under a contract with the National Aeronautics and Space Administration (80NM0018D0004).}
}
  24. Anderson, J. L., Brown, T. L., Cacan, M., Kubiak, G., Jasour, A. and Rothenberger, N. Z. (2024). Lessons From Ingenuity's Climb Up Jezero Crater Delta . IEEE Aerospace Conference. Source
    BibTeX
    @inproceedings{anderson2024lessons,
  title = {Lessons From Ingenuity's Climb Up Jezero Crater Delta},
  author = {Anderson, Joshua L. and Brown, Travis L. and Cacan, Martin and Kubiak, Gerik and Jasour, Ashkan and Rothenberger, Noah Z.},
  booktitle = {IEEE Aerospace Conference},
  pages = {1--15},
  publisher = {IEEE},
  year = {2024},
  doi = {10.1109/aero58975.2024.10521181},
  abstract = {As Perseverance began exploring the delta of Jezero crater, the Ingenuity team took on the most ambitious flights of the mission to date. Designed for the relatively flat terrain of the crater floor, the Ingenuity team now needed to climb up and fly through the rocky channels of the Jezero delta. Before the flights in the delta could even be attempted, the team needed to upgrade Ingenuity’s flight software to identify landing hazards and utilize digital elevation maps in the navigation filter. After upgrading the flight software, the team needed to work through a series of checkout flights to validate this new functionality prior to climbing the delta. The Jezero delta features narrow channels, limiting Ingenuity and Perseverance’s available traverse paths. This required Ingenuity and Perseverance to follow similar routes, necessitating new processes for coordinating Ingenuity and Perseverance’s parallel flights and drives. In previous traverses, Ingenuity was able to take separate, shorter routes to the destination, but this climb required Ingenuity to keep pace with Perseverance’s record setting drives. This rapid traverse pushed the Ingenuity team to optimize the flight planning process to shorten the nominal two week flight cadence to under a week between flights. The narrow passages of the delta also limited Ingenuity’s telecom propagation, providing only small windows of strong communication with Perseverance. All these above constraints required the Perseverance and Ingenuity teams to carefully orchestrate both vehicles’ journey up the delta, keeping both vehicles in lockstep while minimizing the chance that one vehicle would hold up the other’s progress. The paper will cover flight 34 and beyond, Ingenuity’s delta climb, as well as the lessons learned from both the challenging flights in the delta terrain and the required multi-vehicle coordination of the climb.12}
}
  25. Chien, S. A., Rabideau, G., Tran, D. Q., Troesch, M., Nespoli, F., Perez Ayucar, M., Costa Sitja, M., Vallat, C., Geiger, B., Vallejo, F., Andres, R., Altobelli, N. and Kueppers, M. (2021). Activity-based Scheduling of Science Campaigns for the Rosetta Orbiter . SPIE Defense and Security. Source
    BibTeX
    @inproceedings{chien2021activity,
  title = {Activity-based Scheduling of Science Campaigns for the Rosetta Orbiter},
  author = {Chien, Steve A. and Rabideau, Gregg and Tran, Daniel Q. and Troesch, Martina and Nespoli, Federico and Perez Ayucar, Miguel and Costa Sitja, Marc and Vallat, Claire and Geiger, Bernhard and Vallejo, Fran and Andres, Rafael and Altobelli, Nico and Kueppers, Michael},
  booktitle = {SPIE Defense and Security},
  publisher = {JPL Open Repository},
  year = {2021},
  doi = {10.48577/jpl.2yj427}
}
  26. Bernard, D. and Pell, B. (1997). Designed for Autonomy: Remote Agent for the New Millennium Program. dataverse.jpl.nasa.gov/dataset.xhtml
    BibTeX
    @misc{bernard1997designed,
  title = {Designed for Autonomy: Remote Agent for the New Millennium Program},
  author = {Bernard, D. and Pell, B.},
  year = {1997},
  url = {https://dataverse.jpl.nasa.gov/dataset.xhtml?persistentId=hdl:hdl:2014/21931}
}
  27. Matijevic, J. and Dewell, E. (2005). Anomaly Recovery and the Mars Exploration Rovers . SpaceOps Conference. Source
    BibTeX
    @inproceedings{matijevic2005anomaly,
  title = {Anomaly Recovery and the Mars Exploration Rovers},
  author = {Matijevic, Jacob and Dewell, Emily},
  booktitle = {SpaceOps Conference},
  year = {2005},
  doi = {10.2514/6.2006-5957},
  abstract = {The premise of the design of operations for the Mars Exploration Rovers (MER) is that the vehicles will drive each day. As a result, they will encounter some aspect of the terrain environment that cannot be anticipated or otherwise accommodated by the sequences linked onboard that day. The operations team then must correct the problem by planning then commanding the execution of a different drive the next day. Often other aspects of the operation on the surface of Mars: environmental changes, component degradation, errors in sequence design or execution, etc., lead to anomalies which must be addressed before normal operations can resume. The operational design that makes it possible to recover from a driving error each day also reduces the time needed to recover from anomalies. As an example of the efficiency achieved, less than 5% (about 30 sols out of 700 sols of operations) of the time on the surface has been devoted to recovery from anomalies for each vehicle. In this paper the major anomalies experienced by the MER rovers will be recounted and the streamlined approaches to addressing these problems described. The operational flexibility developed for these missions is also a function of the system design that anticipated a number of likely faults and conditions arising from uncertainty in sequence execution and environmental change. This design will be described as well as the considerations in operation that motivated this design. These considerations will likely be present in any future surface mission.}
}
  28. Greco, M. E. and Snyder, J. F. (2005). Operational Modification of the Mars Exploration Rovers Flight Software . IEEE International Conference on Systems, Man and Cybernetics. Source
    BibTeX
    @inproceedings{greco2005operational,
  title = {Operational Modification of the Mars Exploration Rovers Flight Software},
  author = {Greco, Martin E. and Snyder, Joseph F.},
  booktitle = {IEEE International Conference on Systems, Man and Cybernetics},
  address = {Waikoloa, Hawaii},
  year = {2005},
  url = {https://dataverse.jpl.nasa.gov/dataset.xhtml?persistentId=hdl:2014/37496}
}
  29. Bell, T. and D'Amico, S. (2025). Event-Driven Simulation for Rapid Iterative Development of Distributed Space Flight Software . IEEE Aerospace Conference. Source
    BibTeX
    @inproceedings{bell2025event,
  title = {Event-Driven Simulation for Rapid Iterative Development of Distributed Space Flight Software},
  author = {Bell, Toby and D'Amico, Simone},
  booktitle = {IEEE Aerospace Conference},
  pages = {1-19},
  year = {2025},
  doi = {10.1109/aero63441.2025.11068699},
  abstract = {This paper presents the design, development, and application of a novel space simulation environment for rapidly prototyping and testing flight software for distributed space systems. The environment combines the flexibility, determinism, and observability of software-only simulation with a level of fidelity and depth normally attained by real-time hardware-in-the-loop testing. Ultimately, this work enables an engineering process in which flight software is continuously improved and delivered in its final, flight-ready form, and which reduces the cost of design changes and software revisions with respect to a traditional linear development process. Three key methods not found in existing tools enable this environment's novel capabilities: first, a hybrid event-driven simulation architecture that combines continuous-time and discrete-event simulation paradigms; second, a design for lightweight application-layer software virtualization that allows executing compiled flight software binaries while modeling process scheduling, input/ output, and memory use; and third, high-fidelity models for the multi-spacecraft space environment, including for wireless communication, relative sensing such as differential GPS and cameras, and flight computer system health metrics like heap exhaustion and fragmentation. The simulation environment's capabilities are applied to the iterative development and testing of two flight-ready software packages: the guidance, navigation, and control software for the VISORS mission, and the Stanford Space Rendezvous Laboratory's software kit for rendezvous and proximity operations. Results from 33 months of flight software development demonstrate the use of this simulation environment to rapidly and reliably identify and resolve defects, characterize navigation and control performance, and scrutinize implementation details like memory allocation and inter-spacecraft network protocols.}
}
  30. José Franzim Miranda, D., Ferreira, M., Kucinskis, F. and McComas, D. (2019). A Comparative Survey on Flight Software Frameworks for ‘New Space’ Nanosatellite Missions . Journal of Aerospace Technology and Management. Source
    BibTeX
    @article{miranda2019comparative,
  title = {A Comparative Survey on Flight Software Frameworks for ‘New Space’ Nanosatellite Missions},
  author = {José Franzim Miranda, Danilo and Ferreira, Maurício and Kucinskis, Fabricio and McComas, David},
  journal = {Journal of Aerospace Technology and Management},
  publisher = {FapUNIFESP (SciELO)},
  year = {2019},
  doi = {10.5028/jatm.v11.1081},
  abstract = {Nanosatellite missions are becoming increasingly popular nowadays, especially because of their reduced cost. Therefore, many organizations are entering the space sector due to the paradigm shift caused by nanosatellites. Despite the reduced size of these spacecrafts, their Flight Software (FSW) complexity is not proportional to the satellite volume, thus creating a great barrier for the entrance of new players on the nanosatellite market. On the other side, there are some available frameworks that can provide mature FSW design approaches, implying in considerable reduction in software project timeframe and cost. This paper presents a comparative survey between six relevant flight software frameworks, compared according to commonly required ‘New Space’ criteria, and finally points out the most suitable one to the VCUB1 reference nanosatellite mission.}
}
  31. Dvorak, D. (2009). NASA Study on Flight Software Complexity . AIAA Infotech@Aerospace Conference. Source
    BibTeX
    @inproceedings{dvorak2009nasa,
  title = {NASA Study on Flight Software Complexity},
  author = {Dvorak, Daniel},
  booktitle = {AIAA Infotech@Aerospace Conference},
  year = {2009},
  doi = {10.2514/6.2009-1882},
  abstract = {In 2007 the NASA Office of Chief Engineer commissioned a multi-center study to bring forth technical and managerial strategies to address risks from growth in size and complexity of flight software in NASA’s space missions. The motivation for the study grew from problems attributed to flight software in a variety of missions—in both pre-launch and post-launch activities—and concerns that such problems were growing with the expanding role of flight software. The study was tasked to examine the growth in flight software size and complexity, recommend ways to reduce and better manage complexity, and identify methods of testing complex logic. This report examines complexity throughout the engineering lifecycle—from requirements definition through design, development, verification, and operations—and presents sixteen findings and associated recommendations.}
}
  32. Wang, E. and Brown, J. (2007). Cassini's Test Methodology for Flight Software Verification and Operations . AIAA SPACE Conference. Source
    BibTeX
    @inproceedings{wang2007cassini,
  title = {Cassini's Test Methodology for Flight Software Verification and Operations},
  author = {Wang, Eric and Brown, Jay},
  booktitle = {AIAA SPACE Conference},
  year = {2007},
  url = {https://dataverse.jpl.nasa.gov/dataset.xhtml?persistentId=hdl:2014/41356}
}