Simulation Fidelity for Software

A simulator used to verify flight software is not asked to be physically correct. It is asked to produce, at the software’s interfaces, a signal the software cannot distinguish from the flight signal in the respects the software depends on. Where it fails at that, the failure is specific and mostly documented: force, imagery and time [1][2][3]. Flight software for a rover cannot be exercised against the real environment before launch, and flight-like hardware is scarce: on Mars 2020 the few available avionics testbeds ran three shifts a day, seven days a week, and were still short of the verification need [2]. Simulation exists to spend that scarce hardware only where hardware is the only venue that can find the defect. The terramechanics and rendering fidelity questions belong to simulation and digital twins. This page covers what the gaps do to the software under test.

Why the venues converged on a ladder

The flown programs converged on a ladder of venues ordered by cost and fidelity. MSL’s ladder runs unit test, the workstation test set, system integrated test, assembly test and launch operations, and the spacecraft. The workstation venue is simulated and not real time, running at 512 Hz under a VxWorks simulator, while the two upper venues run in real time at the flight rate groups of 8 Hz and 64 Hz [4]. NASA’s systems engineering guidance frames the same logic as a standing practice: verification by test, analysis, inspection and demonstration is distributed across the life cycle, and a product reused in a new environment is no longer credited at its earlier readiness level [21].

Surveying how autonomy software was verified from the Remote Agent experiment through the Mars 2020 onboard scheduler, Chien finds that the bulk of the effort was testing plus informal methods such as walkthroughs, coding rules and design reviews. Formal methods were largely reduced to static analyzers, with SPIN model checking of the Remote Agent executive and of MSL flight software as the narrow exceptions [22]. The consequence is that simulation fidelity is the quantity that decides what testing can find, and the following sections enumerate it interface by interface.

NASA-STD-7009B supplies the vocabulary for how much a simulated result is worth. It scores M&S Capability and M&S Results separately on 0 to 4 scales [23], and its top validation level requires results that compare favorably to measurements on the real system in its operating environment across the full domain of operation [23]. A flight software simulator with no flight comparison for its force or timing interfaces cannot reach that level on those interfaces.

The top of the ladder is a full-scale twin. The Mars 2020 Vehicle System Testbed carries the real motor controller, flight software and rover kinematics onto sloped terrain at once, which is what let the team check that the arm could apply its 50 N coring preload on a slope without the rover slipping; the hexapod venue tilts a fixed chassis with no rover kinematics, and the light Scarecrow rover, built at about three-eighths of flight weight, carries no flight avionics and cannot close verification items [24]. The twin has no thermal fidelity: most platinum resistance thermometers and heater circuits are omitted, the radioisotope generator is replaced by power supplies matched in voltage and current, and power and thermal signals are simulated so the flight software sees nominal values. No comparison of testbed behavior against flight behavior is reported [24].

Families of software-only venue

Four families appear in the record, and they differ in what they model and what they were built to answer.

Full avionics simulation with unmodified flight software. The MSL workstation test set models every device except the flight processor, which runs under a VxWorks simulator rather than being emulated. Its design rule is that the flight software must not be able to tell it is simulated; its objects are shared with the hardware-in-the-loop testbeds so a descoped device can be substituted there; and fault injection reaches down to individual bits in a device output packet, which hardware testbeds cannot do because flight hardware cannot be broken for a test [3]. By 2008 it carried about an order of magnitude more usage hours than the project hardware testbeds [3]. Flown: MSL, and its descendants on Mars 2020.

Stubbed flight software on commercial avionics. The Mars 2020 Surface System Development Environment runs real flight software against commercial avionics and stubbed subsystems. It supports iterating procedures cheaply, Monte Carlo campaigns over thousands of configuration permutations, and validating mitigations for problems found later on flight avionics. Its cost is stated plainly: multiple person-months went to deciding whether a bug was in the flight software or in the environment [2]. Flown: Mars 2020.

Operations simulation. SSim runs the actual flight software code against each candidate command sequence in the daily planning cycle. It must be deterministic although the flight software is not, and about a thousand times faster than real time on the flight compute element, and it has been used to plan every Curiosity robotic operation since landing [1]. Its requirements are the opposite of a development simulator’s, which is why it makes different fidelity choices.

Lightweight and system-level simulators. The onboard planner on Perseverance was verified with a lightweight planning simulator, software-only flight software venues and a vehicle system testbed, against 154 requirements in 32 verification activities, using scenarios taken from actual sol 100 to 600 plans [5]. DSENDS, the entry, descent and landing extension of JPL’s Darts and Dshell simulator, models aerodynamics, parachutes, terrain, lidar and radar and moves from Matlab and Simulink to a VxWorks real-time testbed. Its authors state that confidence in it was limited until its aerodynamic output was verified against a known standard, and its verification was described mostly as planned work [12]. For entry, descent and landing on MSL, the guidance, navigation and control team used Monte Carlo simulation to characterize the flight dynamics envelope, which is a statement about statistical coverage and not about interface fidelity [10].

Outside the rover branch, two recent efforts show the same trade in other settings. A hybrid continuous-time and discrete-event environment runs compiled distributed-spacecraft flight software as a shared library with modeled scheduling, I/O and heap, and was used over 33 months for a formation-flying mission and a rendezvous kit [13]. Its hardware validation is a single processor-in-the-loop test on boards that are not the flight computer, and it addresses Earth orbit only [13]. A bridge between the Basilisk astrodynamics simulator and ROS 2 ran a formation-flying scenario in simulation and on three planar air-bearing free-flyers, open loop with no simulator feedback to the hardware, so it is a laboratory demonstration and not a flight venue [20].

Fidelity is chosen per interface, not per simulator

MSL’s workstation simulator models every hardware behavior the flight software can observe, as finite state machines, integrating differential equations where the dynamics demand it [3]. The deliberate exception is content: for several science instruments it produces data that is correct in format and not in content, because the flight software depends on the format and not on the content [3]. The rule generalizes and bounds what these venues can find: nothing downstream of a value the simulator did not make right.

Mars 2020 makes the choice explicit by keeping one interface to the flight software and three interchangeable backends behind it: a deterministic abstraction layer for force and motion, a terrain simulator with slip modeling, visual odometry, pose tracking and rendered imagery, and a motor server driving real testbed hardware. The same test can be raised or lowered in fidelity without being rewritten [2].

A review of onboard models for small body approach reaches the same conclusion from the spacecraft side. Raising fidelity in one subsystem forces a connection to another: modeling solar array efficiency needs thermal state, modeling generated power needs the maximum power point tracking process and bus conversion loss, and modeling battery capacity needs a cycle life model. The paper does not quantify the error a low-fidelity model incurs, and its navigation case feeds ground truth to the autonomy [14].

Contact force is modeled as a plane and a margin

The force interfaces are where the divergence is largest and best documented. SSim does not model the physics of a drill bit in rock. It uses force feedback averaged from past flight data with a margin allocation, and bounds terrain contact forces by an assumed hardness with margin [1]. That is sufficient for checking that a commanded sequence will complete and insufficient for predicting the force a specific rock will produce.

The Mars 2020 surface simulation treats the dock as a rigid flat plane and populates reaction forces into simulated strain gauge channels. It does not capture post-to-cone contact physics, so it validates sequencing rather than dynamics [8]. The consequence is a split. Sequencing, state and command ordering errors are found in simulation. Contact dynamics are found on hardware: a limit-cycling nonconvergence condition in docking appeared only in the system thermal test, and a stabilizer clearance under 1 mm only in assembly test and launch operations [8]. Docking was performed more than 1200 times on a testbed, over 400 times in the qualification dirty test at three times life, and 9 times on Mars starting on sol 87, all nominal [8]. The durability evidence is ground life testing; nine surface dockings are thin statistics.

Sensor models exist to keep the algorithms fed

The terrain simulator renders camera imagery for visual odometry, stereo ranging and map generation, and applies artificial visual texture to the terrain so the image processing has features to find [2]. The simulated world is deliberately easier to see than the real one. Feature starvation over bland terrain, a dominant flight failure mode of visual odometry, is therefore not something this venue can find. The slip model behind the imagery is approximated rather than terramechanics, and wheel drop is approximated from a moving window of poses [2]. Both serve the flight software’s decision logic and do not predict vehicle behavior.

The mechanical side shows why the gap matters. In the Perseverance tire work, a visual odometry thru-hole pattern in Curiosity’s tread increased both slip and sinkage, and slope-climbing slip on cohesionless sand at 13.5 degrees was 69.49 percent against a 60 percent requirement, a result measured on a test rover and not predicted by the software venues [9].

Navigation accuracy claims rest on error budgets and not on simulation alone. The Mars 2020 terrain relative navigation budget predicted about 45 m before launch, 33.05 m after in-flight calibration and 8.53 m on post-landing reconstruction, against a 5 m measured offset; the reconstruction is a re-run of the budget with updated inputs and not an independent measurement [18]. On Perseverance, global localization against orbital maps runs on a commercial processor in the helicopter base station, and its radiation mitigation (running the algorithm twice with a reboot between runs and comparing, plus checksums) is argued rather than measured [11]. A simulator cannot supply the single-event upset behavior of that processor.

Time is the fidelity that gets traded first

Every software-only venue in the record buys throughput by abandoning real time. The MSL workstation simulator runs 2 to 10 times faster than real time depending on scenario complexity [3]. SSim executes rover behaviors up to 1000 times faster than the flight compute element and does not reproduce the real-time constraints or determinism of the flight software [1]. The workstation venue’s step rate of 512 Hz sits above the flight rate groups of 8 and 64 Hz, so scheduling structure is reproduced and latency is not [4].

Two timing gaps follow. The first is bus response: a simulated bus cannot respond on the microsecond timescale of real hardware, and its responses are coordinated on simulator time slices [2]. The second is concurrency: a single-threaded deterministic simulator cannot produce the interleavings a preemptive multitasking flight software produces on the vehicle [1]. Two Mars 2020 findings sit on the hardware side of that line. A race condition between motor startup and ramp-down monitoring and visual odometry updates in the attitude and positioning module was found only on flight avionics, and SSDEV was then used to verify the mitigation configuration that became the deployed baseline [2]. Hall-based motor position correction was exercised only on flight-like avionics and shipped with a defect, because the commercial motor controllers in the software environment behaved differently from flight ones [2]. Testbed measurements of concurrent activities, such as imaging in parallel with communication window preparation, were taken on single testbed runs and not in simulation [7].

Event-driven simulation with modeled scheduling and heap is the one family that addresses this directly, but its evidence is the authors’ own two software packages and one processor-in-the-loop test [13].

What no simulator injects

Real hardware failures are not injected into hardware-in-the-loop venues, because damaging the testbed is expensive. Fault injection is therefore a software-venue capability: the MSL workstation simulator injects faults at the functional level or by setting individual bits, with pause, resume and single step around the injection [3]. Faults are exercised in the venue with the least physical fidelity, which puts the burden on the fault model being right.

Fault protection validation shows the scale of that burden. Mars 2020 derived over 400 scenario-based test cases from thousands of analyzed faults, prioritized a minimal set of 150, and executed 265 across all venues, using a shared fault injection library and per-response event signatures compared on every run [16]. Psyche’s design had a few thousand failure modes, about 650 monitors and 185 responses, against which 176 end-to-end cases were scoped and 76 executed before a launch slip. The extra year found attitude and rate error monitors whose thresholds, sized to tolerate slews, were also active during static pointing and so responded too slowly or could not detect certain faults. Early testing ran open loop because the dynamics simulations had not been vetted, and no closed-loop attitude control was available in ground testing [17]. Neither paper reports detection latency or a coverage fraction of the fault population, and the management account of Psyche’s testbed schedule under pandemic restrictions gives no test results [15].

The onboard planner verification states the limit that follows: the problem space met in flight is unbounded and had to be constrained to a finite set of testable units, and neither unknown deviations from predicted activity execution nor the behavioral uncertainty of flexible execution could be covered [5]. Its scenarios were drawn from real planning rather than generated, a statement about what the team trusted to be representative.

The fidelity that matters is not always physical

The defect study across seven spacecraft found that 41 percent of 199 critical post-launch anomalies were triggered by data access or delivery problems, that about a third involved rare events needing new fault protection, and that around a fifth to a quarter were fixed by writing or updating a procedure rather than software [6]. Raising the fidelity of a contact model reaches none of these classes. The same study’s 311 MER developmental problem reports were useful in a way no simulator intends: reports where testers believed the software was wrong when it was correct predicted which features would later confuse operators [6].

Operator-facing fidelity has its own evidence. In a 24-participant laboratory study, operators who first practiced on a digital twin of a small rover finished a later teleoperation task 28 percent faster with 85 percent fewer unrecoverable errors; the task was a single lab task with students and no communication latency, so the result is not evidence about lunar operations [19].

Summary of the known divergences

Interface	What the simulator does	What it therefore cannot find
Contact force	penetration into a parameterized plane converted to strain gauge voltages [2]; historical averages with margin [1]	contact dynamics, limit cycling, load prediction [8]
Camera imagery	rendered with artificial texture added to guarantee features [2]	feature starvation and the visual odometry failures that follow from it
Slip and wheel drop	approximated models, not terramechanics [2]	mobility performance, sinkage, embedding [9]
Concurrency	single-threaded deterministic execution [1]	races found on flight avionics [2]
Timing	2 to 1000 times real time [1][3]	interrupt latency, priority inversion under load
Bus response	coordinated on simulator time slices [2]	microsecond-scale hardware response
Instrument data	correct format, sometimes not correct content [3]	anything downstream of instrument data values
Hardware faults	injected in software only, functionally or bitwise [3]	failure modes the fault model does not contain [16][17]

What is not established

The standard sets no numeric accuracy threshold, leaving “favorable comparison” to each program, and it is tailorable, so credibility scores are not comparable across programs [23]. No source quantifies which defect classes each venue finds. The Mars 2020 environment paper reports no defect counts, test hours or coverage figures, and its fidelity gaps are documented by their consequences rather than characterized [2]. The workstation simulator paper credits the simulator with uncovering defects without counts or a per-hour comparison against hardware testbeds [3]. The operations simulator’s thousand-times-real-time figure has no benchmark and no measured catch rate [1]. The fault protection papers report workload and not performance [16][17], and the onboard planner report gives no runtime or resource figures [5]. Formal verification has not been applied beyond static analysis on any of the surveyed flight systems [22]. The event-driven, ROS 2 bridge and digital twin results are laboratory or ground results with no flight comparison [13][19][20].

References

Verma, V. and Leger, C. (2019). SSim: NASA Mars Rover Robotics Flight Software Simulation . IEEE Aerospace Conference. Source

BibTeX

@inproceedings{verma2019ssim,
  title = {SSim: NASA Mars Rover Robotics Flight Software Simulation},
  author = {Verma, Vandi and Leger, Chris},
  booktitle = {IEEE Aerospace Conference},
  pages = {1-11},
  address = {Big Sky, Montana},
  year = {2019},
  doi = {10.1109/aero.2019.8741862},
  abstract = {Each new Mars rover has pursued increasingly richer science while tolerating a wider variety of environmental conditions and hardware degradation over longer mission operation duration. Sojourner operated for 83 sols (Martian days), Spirit for 2208 sols, and Opportunity is at 5111 sols, and Curiosity operation is ongoing at 2208 sols. To handle this increase in capability, the complexity of onboard flight software has increased. MSL (also known as Curiosity), uses more flight software lines of code than all previous missions to Mars combined, including both successes and failures[1]. MSL has more than 4,200 commands with as many as dozens of arguments, 54,000 parameters, and tens of thousands of additional state variables. A single high-level command may perform hours of configurable robotic arm and sampling behavior. Incorrect usage can result in the loss of an activity or the loss of the mission. Surface Simulation (“SSim”) was developed to address the challenge of making full and effective use of many capabilities of MSL, while managing complexity and risk. SSim is software that performs rapid context sensitive simulation of flight software. NASA Mars missions are comprised of three phases: several months of Cruise, a brief but exciting Entry Descent and Landing (EDL), and a Surface mission that typically lasts as long as the hardware survives. SSim is meant for use during the surface phase when the mission fulfills its primary objectives. The focus of SSim on MSL was the robotic flight software, including rover mobility and navigation, robotic arm manipulation, and sample acquisition, processing, and delivery. It can execute behaviors in simulation a thousand times faster than they execute in real time on the flight compute element. SSim is used by rover drivers to develop and validate command sequences throughout the planning cycle. SSim has been used to plan all of the Curiosity robotic operations since landing and is expected to continue to be used for the remaining life of the rover. Due to the impact of SSim on MSL, the Mars 2020 mission plans to increase the scope of SSim during flight operations, simulating not only rover planner operations, but all surface operations, including the instrument, power, thermal and telecommunication behavior. SSim is part of the Rover Sequencing and Visualization (RSVP) suite of Rover Planning tools [2]. In the paper we provide an overview of SSim architecture, design, implementation, and usage on MSL, as well as an overview of plans for Mars 2020.}
}

Brooks, S., Litwin, T., Biesiadecki, J., Abcouwer, N., Del Sesto, T., McHenry, M., Myint, S., Twu, P. and Wai, D. (2022). Testing Mars 2020 Flight Software and Hardware in the Surface System Development Environment . IEEE Aerospace Conference. Source

BibTeX

@inproceedings{brooks2022testing,
  title = {Testing Mars 2020 Flight Software and Hardware in the Surface System Development Environment},
  author = {Brooks, Sawyer and Litwin, Todd and Biesiadecki, Jeffrey and Abcouwer, Neil and Del Sesto, Tyler and McHenry, Michael and Myint, Steven and Twu, Philip and Wai, Dennis},
  booktitle = {IEEE Aerospace Conference},
  pages = {1-13},
  address = {Big Sky, Montana},
  year = {2022},
  doi = {10.1109/aero53065.2022.9843794},
  abstract = {The Mars 2020 (M2020) Perseverance Rover is NASA's most advanced planetary rover mission to date. It includes a novel Sample Caching Subsystem (SCS) which will collect rock cores for possible future return to Earth, as well as an improved mobility system with enhanced autonomous navigation which will enable it to traverse faster and farther than prior rovers. The development of both systems required extensive flight software and flight hardware testing. To support this testing, we developed the Surface System Development Environment (SSDEV) and used it for a wide variety of testing. SSDEV is a bundled subset of M2020 Flight Software which runs on commercially available Linux computers and can be combined with multiple backend options for simulation and hardware control. The SSDEV architecture enabled our teams to perform much more testing of flight software and flight hardware than would have otherwise been possible. As a secondary benefit, the SSDEV-based test campaigns also helped our teams enter the operations phase of the mission with greater readiness of operations products and tools. In this paper, we summarize the motivation for SSDEV, provide an overview of the SSDEV architecture, list several examples of how SSDEV was used, and summarize lessons learned. SSDEV is not a substitute for integrated testing with flight-like avionics, but it enabled substantially more testing than would have otherwise been possible and also provided some unique benefits. We recommend architectures like SSDEV to future projects that need to perform extensive hardware and software testing using a limited set of flight-like avionics.}
}

Henriquez, D., Canham, T., Chang, J. T. and McMahon, E. (2008). Workstation-Based Avionics Simulator to Support Mars Science Laboratory Flight Software Development . AIAA SPACE Conference. Source

BibTeX

@inproceedings{henriquez2008workstation,
  title = {Workstation-Based Avionics Simulator to Support Mars Science Laboratory Flight Software Development},
  author = {Henriquez, David and Canham, Timothy and Chang, Johnny T. and McMahon, Elihu},
  booktitle = {AIAA SPACE Conference},
  year = {2008},
  doi = {10.2514/6.2008-6550},
  abstract = {The Mars Science Laboratory developed the WorkStation TestSet (WSTS) to support flight software development. The WSTS is the non-real-time flight avionics simulator that is designed to be completely software-based and run on a workstation class Linux PC. This provides flight software developers with their own virtual avionics testbed and allows device-level and functional software testing when hardware testbeds are either not yet available or have limited availability. The WSTS has successfully off-loaded many flight software development activities from the project testbeds. At the writing of this paper, the WSTS has averaged an order of magnitude more usage than the project's hardware testbeds.}
}

Jones, J. D. and Lam, D. (2011). Mars Science Laboratory Flight Software Internal Testing . NASA Jet Propulsion Laboratory, Undergraduate Student Research Program Final Report. Source

BibTeX

@techreport{jones2011mars,
  title = {Mars Science Laboratory Flight Software Internal Testing},
  author = {Jones, Justin D. and Lam, Danny},
  institution = {NASA Jet Propulsion Laboratory, Undergraduate Student Research Program Final Report},
  year = {2011},
  url = {https://dataverse.jpl.nasa.gov/dataset.xhtml?persistentId=hdl:2014/43488}
}

Parjan, S. and Gaines, D. (2024). In OBP We Trust: Verification and Validation of the M2020 On Board Planner Flight Software . IEEE Aerospace Conference. Source

BibTeX

@inproceedings{parjan2024obp,
  title = {In OBP We Trust: Verification and Validation of the M2020 On Board Planner Flight Software},
  author = {Parjan, Shreya and Gaines, Dan},
  booktitle = {IEEE Aerospace Conference},
  address = {Big Sky, Montana},
  year = {2024},
  doi = {10.48577/jpl.67lmez},
  abstract = {With a planned deployment to the Perseverance roverin October 2023, the Mars 2020 On Board Planner (OBP) flightsoftware (FSW) will allow the rover to conserve energy and au-tonomously perform more activities when surplus resources (i.e.energy, data volume, time) are available. This functionality iscritical to support efficient resource management and maximizethe productivity of the vehicle as the rover’s battery degradesover time, particularly as the Mars Sample Return mission(MSR) may rely on Perseverance to facilitate sample deliveryto the return lander. Up until OBP’s deployment, operatorshave used the Master/Sub-Master paradigm (M/SM) for allMars missions to-date, in which rigid plans are uplinked to therover based on highly conservative models of activity resourceconsumption and duration that can unnecessarily constrain on-board plans. Thus, OBP must be robust enough to merit thetrust of mission science and operations personnel and preservethe health and safety of the spacecraft. To this end, we havecompleted a thorough verification and validation (V&V) cam-paign of the first iteration of OBP that will be deployed to therover as part of new Simple Planner (SP) operations paradigm.The campaign heavily relied on software testing to ensure thatcore flight software capabilities were met and that the softwarecomprehensively covered potential edge cases. In this paper,we motivate the need for a thorough V&V campaign going intothe deployment of On Board Planner to the Perseverance rover,contextualize how OBP integrates with the rest of the vehicle’sflight software, and leverage three case studies to evidence howtesting provided critical support towards the successful infusionof onboard scheduling software on the rover.}
}

Lutz, R. R. and Mikulski, I. C. (2003). Patterns of Software Defect Data on Spacecraft . NASA Office of Safety and Mission Assurance, Jet Propulsion Laboratory. Source

BibTeX

@techreport{lutz2003patterns,
  title = {Patterns of Software Defect Data on Spacecraft},
  author = {Lutz, Robyn R. and Mikulski, Ines Carmen},
  institution = {NASA Office of Safety and Mission Assurance, Jet Propulsion Laboratory},
  year = {2003},
  url = {https://dataverse.jpl.nasa.gov/dataset.xhtml?persistentId=hdl:2014/7132}
}

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.}
}

Brooks, S., Townsend, J., Collins, C., Carsten, J., Frost, M., Reid, J., Robinson, M. and Warner, A. (2022). Docking the Mars 2020 Perseverance Robotic Arm . IEEE Aerospace Conference. Source

BibTeX

@inproceedings{brooks2022docking,
  title = {Docking the Mars 2020 Perseverance Robotic Arm},
  author = {Brooks, Sawyer and Townsend, Julie and Collins, Curtis and Carsten, Joseph and Frost, Matthew and Reid, Jason and Robinson, Matthew and Warner, Antonia},
  booktitle = {IEEE Aerospace Conference},
  pages = {1-12},
  address = {Big Sky, Montana},
  year = {2022},
  doi = {10.1109/aero53065.2022.9843517}
}

Rieber, R., McHenry, M., Twu, P. and Stragier, M. M. (2022). Planning for a Martian Road Trip - The Mars2020 Mobility Systems Design . IEEE Aerospace Conference. Source

BibTeX

@inproceedings{rieber2022planning,
  title = {Planning for a Martian Road Trip - The Mars2020 Mobility Systems Design},
  author = {Rieber, Richard and McHenry, Michael and Twu, Philip and Stragier, Michael M.},
  booktitle = {IEEE Aerospace Conference},
  pages = {01-18},
  publisher = {IEEE},
  year = {2022},
  doi = {10.1109/aero53065.2022.9843375},
  abstract = {The Perseverance rover landed in Jezero Crater on Mars on February 18, 2021, marking the beginning of an epic road trip across Mars. The guiding principle of the Perseverance rover design was to replicate Curiosity, except for when the new mission objectives mandated a change. The scientific objectives require that Perseverance drive more quickly and more efficiently through more complex terrain than its predecessors. The mobility system for Perseverance exemplifies this, in that key portions are identical, yet others have had major upgrades. Key upgrades include more tractive and more robust tires, new engineering cameras, a new computer dedicated for image processing, and a more efficient AutoNav software suite. This paper will follow how the scientific objectives led to the key and driving mobility requirements and how these requirements were decomposed at the different subsystems.}
}

San Martin, A. M., Lee, S. W. and Wong, E. C. (2013). The Development of the MSL Guidance, Navigation, and Control System for Entry, Descent, and Landing . Annual AAS Guidance and Control Conference. Source

BibTeX

@inproceedings{sanmartin2013development,
  title = {The Development of the MSL Guidance, Navigation, and Control System for Entry, Descent, and Landing},
  author = {San Martin, A. Miguel and Lee, Steven W. and Wong, Edward C.},
  booktitle = {Annual AAS Guidance and Control Conference},
  year = {2013},
  url = {https://dataverse.jpl.nasa.gov/dataset.xhtml?persistentId=hdl:2014/44894}
}

Nash, J., Verma, V., Graser, E., Wang, H., Kubiak, G., Maimone, M., Myint, S., Biesiadecki, J. and Romano, P. (2026). A Software-Based Approach to Radiation Mitigation for Planetary Mission . IEEE Aerospace Conference. Source

BibTeX

@inproceedings{nash2026software,
  title = {A Software-Based Approach to Radiation Mitigation for Planetary Mission},
  author = {Nash, Jeremy and Verma, Vandi and Graser, Evan and Wang, Haoda and Kubiak, Gerik and Maimone, Mark and Myint, Steven and Biesiadecki, Jeffrey and Romano, Philip},
  booktitle = {IEEE Aerospace Conference},
  publisher = {JPL Open Repository},
  year = {2026},
  doi = {10.48577/jpl.okks5v},
  abstract = {The Perseverance Mars rover needs to drive long distances between regions of scientific interest to collect a diverse set of samples. Position knowledge is needed for navigating to the region of interest. Planetary mobile robots accumulate position uncertainty as they move. Globally localizing the robot to an orbital map of Mars removes this uncertainty. Previously this was performed manually on the ground by humans for mobile surface and aerial robots. This can be accurate but requires communication between planets. This takes significant time and the need for it limits how far Perseverance can autonomously navigate without ground-in-the-loop.The Perseverance Mars rover is in the process of deploying a new onboard global localization capability that has the potential for significantly improving long-distance autonomous navigation. It allows the rover to precisely determine its position by comparing panoramic images from its navigation cameras with high-resolution orbital maps. This paper provides an outline of the development and successful deployment of onboard global localization system on the Perseverance Mars rover and the challenges encountered. Leveraging a fast, commercial off-the-shelf (COTS) Snapdragon 801 processor from the Ingenuity Helicopter Base Station, the system performs complex image-processing tasks to accurately determine the rover's position relative to orbital maps. This approach overcomes the limitations of the rover's slower, radiation-hardened processor, and is a paradigm shift in planetary robotics.}
}

Balaram, J., Austin, R. A., Banerjee, P., Bentley, T., Henriquez, D., Martin, B., McMahon, E. and Sohl, G. (2002). DSENDS: A High-Fidelity Dynamics and Spacecraft Simulator for Entry, Descent and Surface Landing . Proceedings, IEEE Aerospace Conference. Source

BibTeX

@inproceedings{balaram2002dsends,
  title = {{DSENDS}: A High-Fidelity Dynamics and Spacecraft Simulator for Entry, Descent and Surface Landing},
  author = {Balaram, J. and Austin, Rebekah A. and Banerjee, P. and Bentley, T. and Henriquez, D. and Martin, Bill and McMahon, Elihu and Sohl, Garett},
  booktitle = {Proceedings, IEEE Aerospace Conference},
  volume = {7},
  pages = {7-3343-7-3359},
  publisher = {IEEE},
  year = {2002},
  doi = {10.1109/aero.2002.1035313},
  abstract = {The Jet Propulsion Laboratory (JPL) is developing a high-fidelity spacecraft simulator for entry, descent and landing (EDL) on planetary and small-bodies. This simulator, DSENDS (Dynamics Simulator for Entry, Descent and Surface landing), is an EDL-specific extension of a JPL multi-mission simulation toolkit (Darts/Dshell) which is capable of modeling spacecraft dynamics, devices, and subsystems, and is in use by interplanetary and science-craft missions such as Cassini, Galileo, SIM, and Starlight. DSENDS is currently in use by the JPL Smart Lander project to provide a high-fidelity testbed for the test of precision landing and hazard avoidance functions for future Mars missions. We first briefly describe the core tool capabilities in dynamics, instrument/actuator device models, and real-time simulation engineering. These allow the modeling of the flight-train elements during various phases of EDL and all of the spacecraft responses. We then address the various EDL-specific aspects of the simulator. These include the high-fidelity entry-body and parachute aerodynamic models and supporting atmospheric models.}
}

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.}
}

Agia, C., Casadesus Vila, G., Bandyopadhyay, S., Bayard, D. S., Cheung, K.-M., Lee, C. H., Aenishanslin, I., Ardito, S., Fesq, L., Pavone, M. and Nesnas, I. A. D. (2024). Modeling Considerations for Developing Deep Space Autonomous Spacecraft and Simulators . IEEE Aerospace Conference. Source

BibTeX

@inproceedings{agia2024modeling,
  title = {Modeling Considerations for Developing Deep Space Autonomous Spacecraft and Simulators},
  author = {Agia, Christopher and Casadesus Vila, Guillem and Bandyopadhyay, Saptarshi and Bayard, David S. and Cheung, Kar-Ming and Lee, Charles H. and Aenishanslin, Ian and Ardito, Steven and Fesq, Lorraine and Pavone, Marco and Nesnas, Issa A. D.},
  booktitle = {IEEE Aerospace Conference},
  publisher = {JPL Open Repository},
  year = {2024},
  doi = {10.48577/jpl.qmq6ph},
  abstract = {Over the last two decades, space exploration systems have incorporated increasing levels of onboard autonomy to perform mission-critical tasks in time-sensitive scenarios or to bolster operational productivity for long-duration missions. Such systems use models of spacecraft subsystems and the environment to enable the execution of autonomous functions (functional-level autonomy) within limited time windows and/or with constraints. These models and constraints are carefully crafted by experts on the ground and uploaded to the spacecraft via prescribed safe command sequences for the spacecraft to execute. Such practice is limited in its efficacy for scenarios that demand greater operational flexibility. To extend the limited scope of autonomy used in prior missions for operation in distant and complex environments, there is a need to further develop and mature autonomy that jointly reasons over multiple subsystems, which we term system-level autonomy. System-level autonomy establishes situational awareness that resolves conflicting information across subsystems, which may necessitate the refinement and interconnection of the underlying spacecraft and environment onboard models. However, with a limited understanding of the assumptions and tradeoffs of modeling to arbitrary extents, designing onboard models to support system-level capabilities presents a significant challenge. For example, simple onboard models that exclude cross-subsystem effects may compromise the efficacy of an autonomous spacecraft, while complex models that capture interdependencies among spacecraft subsystems and the environment may be infeasible to simulate under the real-world operating constraints of the spacecraft (e.g., limited access to spacecraft and environment states, and computational resources). In this paper, we provide a detailed analysis of the increasing levels of model fidelity for several key spacecraft subsystems, with the goal of informing future spacecraft functional- and systemlevel autonomy algorithms and the physics-based simulators on which they are validated. We do not argue for the adoption of a particular fidelity class of models but, instead, highlight the potential tradeoffs and opportunities associated with the use of models for onboard autonomy and in physics-based simulators at various fidelity levels. We ground our analysis in the context of deep space exploration of small bodies, an emerging frontier for autonomous spacecraft operation in space, where the choice of models employed onboard the spacecraft may determine mission success. We conduct our experiments in the Multi- Spacecraft Concept and Autonomy Tool (MuSCAT), a software suite for developing spacecraft autonomy algorithms.}
}

Maxwell, J. L., Dahya, N., Imken, T., Mase, R., Oh, D., Safavizadeh, M., Solish, B., Stone, H., Elkins-Tanton, L. T. and Lord, P. (2022). Psyche Project Implementation During the COVID Pandemic . IEEE Aerospace Conference. Source

BibTeX

@inproceedings{maxwell2022psyche,
  title = {Psyche Project Implementation During the COVID Pandemic},
  author = {Maxwell, Jennifer L and Dahya, Neil and Imken, Travis and Mase, Robert and Oh, David and Safavizadeh, Melody and Solish, Benjamin and Stone, Henry and Elkins-Tanton, Linda T. and Lord, Peter},
  booktitle = {IEEE Aerospace Conference},
  pages = {1-15},
  year = {2022},
  doi = {10.1109/aero53065.2022.9843595},
  abstract = {In January 2017, “Psyche: Journey to a Metal World” was selected for implementation as part of NASA's Discovery program. The Psyche mission will utilize electric propulsion with SPT-140 Hall thrusters to rendezvous and orbit the metal-rich asteroid (16) Psyche, in the main asteroid belt between Mars and Jupiter. The Psyche spacecraft requires no chemical propulsion and, when launched in 2022, will be the first mission to use Hall thrusters beyond lunar orbit. The Psyche spacecraft is a hybrid development with Jet Propulsion Laboratory (JPL)-provided deep-space avionics and communications equipment mounted on a high-heritage MAXAR (formerly Space Systems Loral) Solar-Electric Propulsion (SEP) Chassis, based on their 1300 series of GEO communications satellites. The spacecraft is equipped to support a suite of science instruments, as well as a demonstration of the Deep Space Optical Communications (DSOC) technology. The spacecraft has sufficient onboard resources, autonomy, redundancy, and operability to complete a 3.5-year cruise to 16 Psyche, followed by a 20-month campaign of science investigations while orbiting the asteroid. The mission's early concept design and progress through Preliminary Design Review (PDR) has been described in previous work. The paper will cover the recent mission progress from the Critical Design Review (CDR) through the start of Spacecraft Environmental Testing, which took place during the COVID pandemic. The authors will highlight the successful remote collaboration between the major partners: ASU, JPL, MAXAR, and the Payload teams that led to the initiation of the Assembly, Test, Launch, Operations Phase (ATLO) in early March 2021. Emphasis will be placed on the effects that the COVID-19 pandemic had on the work environment over the last 16+ months, including challenges to delivery of flight hardware and test equipment. In addition to the COVID-19 challenges, other significant anomalies discovered during design and test will be described along with any impacts to the overall science capability of the mission.}
}

Clark, J. J., Lam, M., DuCharme, L., Lumnah, A. and Morantz, C. (2022). Validation of the Mars 2020 Fault Protection Design: Navigating the Infinity of the Off-Nominal . IEEE Aerospace Conference. Source

BibTeX

@inproceedings{clark2022validation,
  title = {Validation of the Mars 2020 Fault Protection Design: Navigating the Infinity of the Off-Nominal},
  author = {Clark, Jessica J and Lam, Mary and DuCharme, Lauren and Lumnah, Alex and Morantz, Chaz},
  booktitle = {IEEE Aerospace Conference},
  pages = {1-8},
  publisher = {IEEE},
  year = {2022},
  doi = {10.1109/aero53065.2022.9843661},
  abstract = {On July 30th 2020, the Mars 2020 mission successfully launched out of Cape Canaveral, Florida, passed through the Earth's shadow, and began its short cruise to Mars. Less than seven months later, the Perseverance rover touched down safely in Jezero Crater to begin its ambitious mission that includes looking for signs of ancient life and collecting samples for future return to Earth. Getting to the successful landing, or “Tango Delta Nominal,” could not have been achieved without also considering the off-nominal. One of the teams supporting this ambitious mission is the fault protection (FP) team. This team is tasked with assessing the various failures, or faults, that could prevent mission success and with ensuring that the autonomous behaviors built into the software and hardware can detect faults and recover the vehicle to a safe state. As part of its charter, the FP team designed a test campaign to provide confidence in the system's robustness to off-nominal scenarios across all of Mars 2020's mission phases. The greatest challenge associated with designing such a validation campaign was reducing the infinite number of anomalous scenarios into a finite test suite. In addition, the tests needed to be executed efficiently in order to utilize the team's limited test venue access, but still needed to maintain a level of rigor that guaranteed confidence in the test outcomes. Given that each test scenario generated massive amounts of data, the team also developed methods for quickly ascertaining whether the autonomous fault protection behaviors maintained vehicle safety in the presence of an anomaly. This paper summarizes the processes that the Mars 2020 fault protection team employed to execute its off-nominal validation campaign. It captures both the methods of generating a suite of off-nominal tests, as well as reducing it to a subset that can be realistically executed within schedule and resource constraints. It also describes the various processes and philosophies that the team utilized to execute the tests efficiently, including creating a standardized procedure template, keeping the test cases modular so that they could be easily interchanged, and capturing common fault injections in a change-controlled database. Finally, it will describe the tools and processes for assessing the test data, focusing in particular on a tool that evaluated vehicle state using “secondary” sources of data to validate that the software had truly configured the spacecraft to the expected safe state.}
}

Pujari, S., Summer, J., Sereno, V. and Lumnah, A. (2024). Two Steps Forward: Evolving Psyche's Fault Protection Validation Post-Launch Slip . IEEE Aerospace Conference. Source

BibTeX

@inproceedings{pujari2024two,
  title = {Two Steps Forward: Evolving Psyche's Fault Protection Validation Post-Launch Slip},
  author = {Pujari, Swapnil and Summer, Jonathan and Sereno, Virginia and Lumnah, Alexander},
  booktitle = {IEEE Aerospace Conference},
  publisher = {JPL Open Repository},
  year = {2024},
  doi = {10.48577/jpl.grmhhb},
  abstract = {On October 5th, 2023, the Psyche Mission is targeted to launch to the large metallic asteroid (16) Psyche that will be exploring the exposed core material of a differentiated planetesimal-class asteroid. This unique NASA Discovery-class Mission combines a Solar Electric Propulsion (SEP) Chassis from Maxar Technologies with JPL’s contribution of avionics, flight software, and fault protection design. The Psyche Fault Protection (FP), implemented as autonomous algorithms, can detect, isolate, respond to, and recover from off-nominal conditions that may prevent mission success.The FP Verification and Validation (V&V) campaign involved numerous types of testing including FP infrastructure, monitor & response end-to-end (E2E) functionality, scenario testing, and stress and robustness testing across both high and low-fidelity venues. Due to delays in system level software testing, Psyche had to reschedule its original launch window from July 2022 to October 2023. This paper focuses on how the V&V campaign was scoped and executed prior to the launch slip and then improved after the launch slip. Adaptations included testing a comprehensive E2E regression test suite by targeting updates made to the GNC FP design, a streamlined data execution that employed variance of initial conditions and a consistent test procedure, and a robust and efficient data review strategy including tooling to automate checks. By capitalizing on the additional time, resources, and insights gained from Psyche’s launch slip, the Fault Protection V&V campaign benefited from a more comprehensive and rigorous validation process. This paper captures the knowledge and processes employed to validating Psyche’s Fault Protection design such that future FP V&V campaigns can benefit from more robust testing.}
}

Mohan, S., Johnson, A. E., Brugarolas, P., Cheng, Y., Otero, R., Trawny, N., Aaron, S., Serricchio, F., Montgomery, J., Casoliva, J. and Chen, A. (2021). Assessment of M2020 Terrain Relative Landing Accuracy: Flight Performance vs Predicts . AAS/AIAA Astrodynamics Specialist Conference. Source

BibTeX

@inproceedings{mohan2021assessment,
  title = {Assessment of M2020 Terrain Relative Landing Accuracy: Flight Performance vs Predicts},
  author = {Mohan, Swati and Johnson, Andrew E. and Brugarolas, Paul and Cheng, Yang and Otero, Richard and Trawny, Nikolas and Aaron, Seth and Serricchio, Fred and Montgomery, James and Casoliva, Jordi and Chen, Allen},
  booktitle = {AAS/AIAA Astrodynamics Specialist Conference},
  publisher = {JPL Open Repository},
  year = {2021},
  url = {https://dataverse.jpl.nasa.gov/dataset.xhtml?persistentId=hdl:2014/55252}
}

O'Keefe, X., McCutchan, K., Muniz, A., Burns, J. and Szafir, D. (2025). Practice Makes Perfect: A Study of Digital Twin Technology for Assembly and Problem-solving using Lunar Surface Telerobotics . Advances in Space Research. Source

BibTeX

@article{okeefe2025practice,
  title = {Practice Makes Perfect: A Study of Digital Twin Technology for Assembly and Problem-solving using Lunar Surface Telerobotics},
  author = {O'Keefe, Xavier and McCutchan, Katy and Muniz, Alexis and Burns, Jack and Szafir, Daniel},
  journal = {Advances in Space Research},
  volume = {76},
  pages = {1550-1562},
  year = {2025},
  doi = {10.1016/j.asr.2025.05.048}
}

Krantz, E., Chan, N. N., Tibert, G., Mao, H. and Fuglesang, C. (2025). Bridging the Basilisk Astrodynamics Framework with ROS 2 for Modular Spacecraft Simulation and Hardware Integration . International Conference on Space Robotics. Source

BibTeX

@inproceedings{krantz2025bridging,
  title = {Bridging the Basilisk Astrodynamics Framework with ROS 2 for Modular Spacecraft Simulation and Hardware Integration},
  author = {Krantz, Elias and Chan, Ngai Nam and Tibert, Gunnar and Mao, Huina and Fuglesang, Christer},
  booktitle = {International Conference on Space Robotics},
  pages = {343-348},
  year = {2025},
  doi = {10.1109/isparo66239.2025.11437323},
  abstract = {Integrating high-fidelity spacecraft simulators with modular robotics frameworks remains a challenge for autonomy development. This paper presents a lightweight, open-source communication bridge between the Basilisk astro-dynamics simulator and the Robot Operating System 2 (ROS 2), enabling real-time, bidirectional data exchange for spacecraft control. The bridge requires no changes to Basilisk’s core and integrates seamlessly with ROS 2 nodes. We demonstrate its use in a leader-follower formation flying scenario using nonlinear model predictive control, deployed identically in both simulation and on the ATMOS planar microgravity testbed. This setup supports rapid development, hardware-in-the-loop testing, and seamless transition from simulation to hardware. The bridge offers a flexible and scalable platform for modular spacecraft autonomy and reproducible research workflows.}
}

NASA. (2017). NASA Systems Engineering Handbook, Revision 2 (NASA SP-2016-6105 Rev 2) . NASA Headquarters. Source

BibTeX

@techreport{nasa2017systems,
  title = {NASA Systems Engineering Handbook, Revision 2 (NASA SP-2016-6105 Rev 2)},
  author = {{NASA}},
  institution = {NASA Headquarters},
  year = {2017},
  url = {https://ntrs.nasa.gov/citations/20170001761},
  abstract = {The update of this handbook continues the methodology of the previous revision: a top-down compatibility with higher level Agency policy and a bottom-up infusion of guidance from the NASA practitioners in the field. This approach provides the opportunity to obtain best practices from across NASA and bridge the information to the established NASA systems engineering processes and to communicate principles of good practice as well as alternative approaches rather than specify a particular way to accomplish a task. The result embodied in this handbook is a top-level implementation approach on the practice of systems engineering unique to NASA. Material used for updating this handbook has been drawn from many sources, including NPRs, Center systems engineering handbooks and processes, other Agency best practices, and external systems engineering textbooks and guides. This handbook consists of six chapters: (1) an introduction, (2) a systems engineering fundamentals discussion, (3) the NASA program project life cycles, (4) systems engineering processes to get from a concept to a design, (5) systems engineering processes to get from a design to a final product, and (6) crosscutting management processes in systems engineering. The chapters are supplemented by appendices that provide outlines, examples, and further information to illustrate topics in the chapters. The handbook makes extensive use of boxes and figures to define, refine, illustrate, and extend concepts in the chapters. }
}

Chien, S. (2022). Formal Methods for Trusted Space Autonomy, Boon or Bane? . NASA Formal Methods. Source

BibTeX

@inproceedings{chien2022formal,
  title = {Formal Methods for Trusted Space Autonomy, Boon or Bane?},
  author = {Chien, Steve},
  booktitle = {NASA Formal Methods},
  series = {Lecture Notes in Computer Science},
  pages = {3-13},
  publisher = {Springer International Publishing},
  year = {2022},
  doi = {10.1007/978-3-031-06773-0_1}
}

NASA. (2024). NASA-STD-7009B: Standard for Models and Simulations . NASA Office of the Chief Engineer. Source

BibTeX

@techreport{nasa2024models,
  title = {NASA-STD-7009B: Standard for Models and Simulations},
  author = {{NASA}},
  institution = {NASA Office of the Chief Engineer},
  year = {2024},
  url = {https://standards.nasa.gov/standard/nasa/nasa-std-7009}
}

Matthes, C., Stumbo, M. and Foley, J. (2021). How to Build a Rover: An Overview of the Mars 2020 Mission's Vehicle System Testbed . IEEE Aerospace Conference. Source

BibTeX

@inproceedings{matthes2021how,
  title = {How to Build a Rover: An Overview of the Mars 2020 Mission's Vehicle System Testbed},
  author = {Matthes, Christopher and Stumbo, Matthew and Foley, Justin},
  booktitle = {IEEE Aerospace Conference},
  pages = {1-12},
  year = {2021},
  doi = {10.1109/aero53065.2022.9843658},
  abstract = {While NASA's Mars rover Perseverance continues to make groundbreaking achievements on the Red Planet, its twin is hard at work here on Earth. The Operational Perseverance Twin for the Integration of Mechanisms and Instruments Sent to Mars, or OPTIMISM, is the Mars 2020 Vehicle System Testbed (VSTB) rover operated by NASA Jet Propulsion Laboratory (JPL) in Pasadena, California. OPTIMISM's home is the JPL Mars Yard; an outdoor field with red soil that simulates the terrain encountered by Perseverance. The VSTB is a full-scale engineering model of the flight rover, serving a number of functions to ensure mission operations can continue smoothly and on schedule. The VSTB possesses instrumentation, computers, mechanisms, cameras, and a Mobility subsystem that are nearly identical to its extraterrestrial twin. Its high fidelity allows the rover to be a highly effective tool to fully test system functionality and performance prior to commanding the flight rover. The early stages of building OPTIMISM began a few months prior to Perseverance departing JPL for Cape Canaveral, FL in early 2020. Electrical integration of the flight system avionics, and compatibility checkouts of the electrical ground support equipment ensured that the foundation of the electrical system was operational and in place. Next, the internal harnessing was installed and compatibility checks of the rover instrumentation and mechanisms were performed to confirm the system was prepared for full buildup. Finally, mechanical assembly of the rover chassis with its external components completed the integration of the system before it was moved to the Mars Yard for its initial phase of testing to perform verification & validation (V&V) of the Mobility subsystem requirements. By the time Perseverance landed at Jezero Crater in February 2021, the first phase of VSTB operations was underway. Surface guidance, navigation, and control (SGNC) testing for the Mobility subsystem ensured functionality and performance requirements were met for various capabilities such as visual odometry (VO), mapping, and automatic navigation (AutoNav). Subsequent integration of the robotic arm (RA) onto the VSTB enabled the V&V campaign for surface sampling operations (SSO) to commence. As the mission's engineering operations (EO) have gotten underway, the VSTB has been utilized for an array of purposes including troubleshooting software anomalies, and performing dry-runs for first time activities (FTAs) prior to sending the commands to Perseverance. OPTIMISM will continue to serve mission critical functions as long as Perseverance is roving the Red Planet.}
}