Results for “FSW” — Page 13

NASA NTRS2017

Automated Re-Entry System using FNPEG

This paper discusses the implementation and simulated performance of the FNPEG (Fully Numerical Predictor-corrector Entry Guidance) algorithm into GNC FSW (Guidance, Navigation, and Control Flight Software) for use in an autonomous re-entry vehicle. A few modifications to FNPEG are discussed that result in computational savings -- a change to the state propagator, and a modification to cross-range lateral logic. Finally, some Monte Carlo results are presented using a representative vehicle in both a high-fidelity 6-DOF (degree-of-freedom) sim as well as in a 3-DOF sim for independent validation.

Johnson, Wyatt R.↗

NASA NTRS2016

SLS Flight Software Testing: Using a Modified Agile Software Testing Approach

NASA's Space Launch System (SLS) is an advanced launch vehicle for a new era of exploration beyond earth's orbit (BEO). The world's most powerful rocket, SLS, will launch crews of up to four astronauts in the agency's Orion spacecraft on missions to explore multiple deep-space destinations. Boeing is developing the SLS core stage, including the avionics that will control vehicle during flight. The core stage will be built at NASA's Michoud Assembly Facility (MAF) in New Orleans, LA using state-of-the-art manufacturing equipment. At the same time, the rocket's avionics computer software is being developed here at Marshall Space Flight Center in Huntsville, AL. At Marshall, the Flight and Ground Software division provides comprehensive engineering expertise for development of flight and ground software. Within that division, the Software Systems Engineering Branch's test and verification (T&V) team uses an agile test approach in testing and verification of software. The agile software test method opens the door for regular short sprint release cycles. The idea or basic premise behind the concept of agile software development and testing is that it is iterative and developed incrementally. Agile testing has an iterative development methodology where requirements and solutions evolve through collaboration between cross-functional teams. With testing and development done incrementally, this allows for increased features and enhanced value for releases. This value can be seen throughout the T&V team processes that are documented in various work instructions within the branch. The T&V team produces procedural test results at a higher rate, resolves issues found in software with designers at an earlier stage versus at a later release, and team members gain increased knowledge of the system architecture by interfacing with designers. SLS Flight Software teams want to continue uncovering better ways of developing software in an efficient and project beneficial manner. Through agile testing, there has been increased value through individuals and interactions over processes and tools, improved customer collaboration, and improved responsiveness to changes through controlled planning. The presentation will describe agile testing methodology as taken with the SLS FSW Test and Verification team at Marshall Space Flight Center.

Bolton, Albanie T.↗

NASA NTRS2016

Enhancing the Cassini Mission Through FP Applications After Launch

Although rigorous pre-emptive measures are taken to preclude failures and anomalous conditions from occurring in JPL spacecraft missions prior to launch, unforeseeable problems can still surface after liftoff. In the case of the Cassini/Huygens Mission-to-Saturn spacecraft, several problems were observed post-launch: 1) immediately after takeoff, the collected engineering/science data stored on the Solid State Recorders (SSR) contained a significantly higher number of corrupted bits than was expected (considerably over spec) due to human error in the memory mapping of these devices, 2) numerous Solid State Power Switches (SSPS) sporadically tripped off throughout the mission due to cosmic ray bombardment from the unique space environment, and 3) false assumptions in the pressure regulator design in combination with missing heritage test data led to inaccurate design conclusions, causing the issuance of two waivers for the regulator to close properly (a potentially mission catastrophic single-point failure which occurred 24 days after launch) - amongst other problems. For Cassini, some of these anomalies led to arduous work-arounds or required continuous monitoring of telemetry variables by the ground-based Spacecraft Operations Flight Support (SOFS) team in order to detect and fix fault occurrences as they happened. Fortunately, sufficient funding and schedule margin allowed several Fault Protection (FP) solutions to be implemented into post-launch Flight Software (FSW) uploads to help resolve these issues autonomously, reducing SOFS ground support efforts while improving anomaly recovery time in order to preserve maximum science capture. This paper details the FP applications used to resolve the above issues as well as to optimize solutions for several other problems experienced by the Cassini spacecraft during its fight, in order to enhance the spacecraft's overall mission success throughout the 18 years of its 20 year expedition to and within the Saturnian system.

fault protection↗

NASA NTRS2017

OpenSatKit Enables Quick Startup for CubeSat Missions

The software required to develop, integrate, and operate a spacecraft is substantial regardless of whether its a large or small satellite. Even getting started can be a monumental task. To solve this problem, NASAs Core Flight System (cFS), NASA's 42 spacecraft dynamics simulator, and Ball Aerospaces COSMOS ground system have been integrated together into a kit called OpenSatKit that provides a complete and open source software solution for starting a new satellite mission. Users can have a working system with flight software, dynamics simulation, and a ground command and control system up and running within hours.Every satellite mission requires three primary categories of software to function. The first is Flight Software (FSW) which provides the onboard control of the satellites and its payload(s). NASA's cFS provides a great platform for developing this software. Second, while developing a satellite on earth, it is necessary to simulate the satellites orbit, attitude, and actuators, to ensure that the systems that control these aspects will work correctly in the real environment. NASAs 42 simulator provides these functionalities. Finally, the ground has to be able to communicate with the satellite, monitor its performance and health, and display its data. Additionally, test scripts have to be written to verify the system on the ground. Ball Aerospace's COSMOS command and control system provides this functionality. Once the OpenSatKit is up and running, the next step is to customize the platform and get it running on the end target. Starting from a fully working system makes porting the cFS from Linux to a users platform much easier. An example Raspberry Pi target is included in the kit so users can gain experience working with a low cost hardware target. All users can benefit from OpenSatKit but the greatest impact and benefits will be to SmallSat missions with constrained budgets and small software teams. This paper describes OpenSatKits system design, the steps necessary to run the system to target the Raspberry Pi, and future plans. OpenSatKit is a free fully functional spacecraft software system that we hope will greatly benefit the SmallSat community.

Software↗

NASA NTRS2018

Plasticity and Damage Modeling of Stress Asymmetry and Dynamic Behavior of AFS Additive Manufactured Aluminum Alloy 2219

The Solid State Additive Manufacturing (AM) process referred as MELD that fabricated the samples in this study, provides a new path for repairing, coating, joining and additive manufacturing metals and metal matrix composites. This research will be the first application of a physics-based microstructure dependent internal state variable (ISV) plasticity and damage material model to capture the mechanical response of an AM Aluminum Alloy (AA) 2219 via the MELD process. In this research, a microstructure-based internal state variable (ISV) plasticity-damage model was used to capture the mechanical behavior of AFS 2219 aluminum alloy. Aeroprobe Corporation, creator and patent holder for the MELD process, fabricated the material by pushing a solid filler rod of AA2219-T861 material through a hollow rotating tool onto an AA2219 T851 plate substrate. As feedstock, solid or powder precursor metals are pushed through a nonconsumable rotating cylindrical tool. Herein, added layers are deposited and metallurgically bonded to substrate material or previously deposited layers by the heat generated from the rotating tool through plastic deformation of the filler material. Once a layer has been added, the tool height increases, and starts the deposition of the next layer. This process results in beneficial properties such as grain refinement, homogenization and reduced porosity (fully dense). This process will experience temperatures similar to those in the weld nugget zone (WNZ) in friction stir welding (FSW), ranging from 0.6-0.9 Tm, with Tm being the melting point of the material. MELD is highly scalable with AA deposition rates reaching over 1000 cm3/hr, which allows for MELD being used for repairs, coatings, and building components. A motivating factor driving the research for physics-based history dependent material modeling of MELD components is the ability to accurately capture the stress-state and strain rate dependence in the material caused by variations in material microstructure from the MELD processing of new or repaired components. The ISV model incorporates microstructural content and is consistent with continuum level kinematics, kinetics, and thermodynamics. These features allow the ISV model to capture large deformations at the structural scale using the kinematic and isotropic hardening, while microscale damage is obtained from the microstructural features. The benefits of the ISV model arise from the inclusion of structure-property relationships identified from microstructural characterization and experimentation. The Bauschinger effect (BE) is an important concept, vital in the accurate prediction of cyclic stress-strain response of ductile materials such as metals. The ISV model has been successfully used to capture the behavior and damage, and the BE of different aluminum alloys and steels. The ISV model uses kinematic and isotropic hardening to help capture deformations of the material at the macro scale. To understand this hardening relationship, calculating the kinematic and isotropic hardening relationship in the material is warranted for a high-fidelity model. Electron Backscattered Diffraction (EBSD) was used to characterize the as-fabricated microstructure, where a fully-dense equiaxed grain morphology with average grain size of 2.5 μm was observed. Microhardness mapping of the as-built structures, monotonic tension and compression experiments at both quasi-static (0.001/s) strain rates, tension-followed-by-compression and compression-followed-by-tension experiments were performed to obtain the set of plasticity and damage constants necessary to capture strain rate and stress state behavior of this additive material. To calibrate the plasticity-damage model, a single set of constants were determined to capture the different stress states the MELD AA2219. One set of the constants was determined from experimental true stress-strain curves for the tension and compression data. Additionally, microstructural information and data from the open literature were used as the other model constants. This research is a first of its kind for AFS AA2219, includes correlating the ISV model to the monotonic experimental results that capture the isotropic and kinematic plasticity mechanical response.

Rivera, O. G.↗

NASA NTRS2019

Rapid Development of the Seeker Free-Flying Inspector Guidance, Navigation, and Control System

Seeker is an automated extravehicular free-flying inspector CubeSat designed and built in-house at the Johnson Space Center (JSC). As a Class 1E project funded by the International Space Station (ISS) Program, Seeker had a streamlined process to flight certification, but the vehicle had to be designed, developed, tested, and delivered within approximately one year after authority to pro-ceed (ATP) and within a $1.8 million budget. These constraints necessitated an expedited Guidance, Navigation, and Control (GNC) development schedule, development began with a navigation sensor trade study using Linear Covariance (LinCov) analysis and a rapid sensor downselection process, resulting in the use of commercial off-the-shelf (COTS) sensors which could be procured quickly and subjected to in-house environmental testing to qualify them for flight. A neural network was used to enable a COTS camera to provide bearing measurements for visual navigation. The GNC flight software (FSW) algorithms utilized lean development practices and leveraged the Core Flight Software (CFS) architecture to rapidly develop the GNC system, tune the system parameters, and verify performance in simulation. This pace was anchored by several Hardware-Software Integration (HSI) milestones, which forced the Seeker GNC team to develop the interfaces both between hardware and software and between the GNC domains early in the project and to enable a timely delivery.

Sullivan, Jacob↗

NASA NTRS2019

Rapid Development of the Seeker Free-Flying Inspector Guidance, Navigation, and Control System

Seeker is an automated extravehicular free-flying inspector CubeSat designed and built in-house at the Johnson Space Center (JSC). As a Class 1E project funded by the International Space Station (ISS) Program, Seeker had a stream-lined process to flight certification, but the vehicle had to be designed, developed, tested, and delivered within approximately one year after authority to proceed (ATP) and within a $1.8 million budget. These constraints necessitated an expedited Guidance, Navigation, and Control (GNC) development schedule. Development began with a navigation sensor trade study using Linear Covariance (LinCov) analysis and a rapid sensor down-selection process, resulting in the use of commercial off-the-shelf (COTS) sensors which could be procured quickly and subjected to in-house environmental testing to qualify them for flight. A neural network was used to enable a COTS camera to provide bearing measure-ments for visual navigation. The GNC flight software (FSW) algorithms utilized lean development practices and leveraged the Core Flight Software (CFS) architecture to rapidly develop the GNC system, tune the system parameters, and verify performance in simulation. This pace was anchored by several Hardware-Software Integration (HSI) milestones, which forced the Seeker GNC team to develop the interfaces both between hardware and software and between the GNC domains early in the project and to enable a timely delivery.

Sullivan, Jake↗

NASA NTRS2019

CHANGO: A Software Tool for Boost Stage Guidance of the Space Launch System Exploration Mission 1

The Day of Launch Initiation Load Update (DOLILU) System is the means by which the Space Launch System (SLS) Vehicle trajectory is designed, verified, and uploaded on the Day of Launch (DOL) in order to ensure a safe flight. Launch vehicles are designed to fly down a narrow angle of attack and sideslip angle corridor in order to keep them within structural load limits. The angle of attack and sideslip angle response to the launch vehicle experiences can vary significantly based upon the winds experienced on the DOL. SLS Boost Stage flight employs an open-loop guidance scheme through Solid Rocket Booster (SRB) separation. In the SLS open-loop scheme, the vehicle will fly a prescribed set of attitudes as a function of the change in altitude since launch. This set of reference attitude values and corresponding altitude reference independent values are designed with ground software using winds measured on the DOL with the goal of minimizing angle of attack and sideslip angle, thereby minimizing related ascent integrated vehicle structural loads. The table of Boost Stage attitude commands as a function of altitude gained since launch is called the chi table. A software tool called CHANGO (Chi Angle Optimizer) designs the Boost Stage chi table which is uploaded to the vehicle’s flight computer and used during ascent by the flight software (FSW). The wind and atmospheric conditions are measured prior to launch and pre-processed to become input to the CHANGO software along with a set of parameters developed in advance of the DOL. CHANGO’s target set consists of the heading and altitude rate at SRB separation determined well before launch by the Program to Optimize Simulated Trajectories (POST). CHANGO consists of a simplified three degree-of-freedom (3-DOF) simulation representing the SLS launch configuration. In general, the launch azimuth is strongly correlated with the heading at SRB separation, and the initial pitchover rate is strongly correlated with the altitude rate at SRB separation. CHANGO uses an adaptation of Powell’s method to vary the initial pitchover rate and launch azimuth to solve a 2-dimentional minimization problem. CHANGO’s trajectory simulation is phase-based, with flight events separating the phases. Each flight phase has different attitude alignment logic. CHANGO’s 3-DOF simulation starts when the vehicle’s thrust-to-weight ratio equals one, and ends at a pre-calculated SRB separation time.

Ahmad, Naeem↗

NASA NTRS2018

Boundary of the Slow Solar Wind

This work argues that there are two fundamental states of the non-transient solar wind, and that these can be distinguished by a number of criteria. Here we define the states, which will be termed slow and fast, or SSW and FSW, for lack of better terms, by the level of velocity fluctuations, v, in them, with the slow wind having systematically lower fluctuations than the fast wind. Almost all winds with speeds less than 450 km s1 are in the slow class, and winds with speeds greater than 600 km s1 are fast, but we argue that in between, consistent with other work, the v classification is more fundamental than speed. We show that the fluctuation categorization coincides well with classes based on AlfvÃ©nicy, proton specific entropy, ion thermal speed, and ionic composition. This correlated behavior among these solar wind parameters exists regardless of it being associated with a heliospheric current sheet or a pseudostreamer. This work provides evidence that both the so-called SSW I and SSW II scenarios coexist for the SSW formation. In addition, that the dynamical properties (thermal, magnetic, and turbulence properties) correlate well with properties set at the inner corona (ion ionization states and FIP bias)implies that there exists a boundary layer on the Sun within which the SSW is formed. This boundary layer would set up the coronal conditions for the source and transport of the SSW.

Ko, Yuan-Kuen↗

NASA NTRSDate not supplied

cFS Test Framework (CTF)

NASA's Core Flight System (cFS) provides a generic flight software framework architecture for developing flight software. As the cFS framework has gained popularity over the years within the flight software community, supporting software tools have been developed to assist in the design, development, testing and verification of flight software. The cFS Test Framework (CTF) is a recently developed cFS tool with capabilities to develop and run automated test and verification scripts against flight software targets. The CTF tool parses and executes JSON-based test scripts containing test instructions, while logging and reporting the results. CTF utilizes a plugin-based architecture to allow developers to extend CTF with new test instructions, external interfaces, and custom functionality. To interface with flight software, CTF parses a set of CCSDS message definition files to create the necessary command and telemetry structures for use during the test run. Additionally, CTF also supports interfacing with multiple cFS instances, allowing a test script to verify requirements that involve multiple flight software targets. Lastly, CTF provides support for executing test scripts against FSW running on remote or embedded hardware. This allows CTF to execute the same test scripts across different target configurations throughout the development process. In this presentation, we will introduce the cFS Test Framework (CTF) architecture, discuss the history of cFS testing frameworks, and present the features and capabilities currently provided by CTF. Lastly, we will show a demo of the CTF tool being used to execute test scripts against flight software.

Aly I Shehata↗

NASA NTRS2018

ST7 Disturbance Reduction System (DRS) Colloid Micronewton Thruster Performance and Control Algorithm Model Simulation Validation in Flight

Colloid Micronewton Thrusters (CMNT) were flight demonstrated for the first time on the ST7Disturbance Reduction System (DRS) payload on the European Space Agency (ESA) Laser Interferometer Space Antenna (LISA) Pathfinder spacecraft for attitude and drag-free spacecraft control. LISA Pathfinder was a technology demonstration mission for ESA’s LISA gravitational wave observatory, currently in Phase A with a launch date of 2034. The DRS included the Integrated Avionics Unit (IAU), eight Colloid Micronewton Thrusters (CMNT), Dynamic Control Software (DCS) and Flight Software (FSW). The CMNT technology met performance requirements operating at 5-30 µN of thrust with ≤0.1 µN resolution and ≤0.1 µN/Hz thrust noise to deliver the required nanometer-level precision spacecraft control measured by the gravitational reference sensor (GRS) in the ESA LISA Technology Package (LTP). The performance of seven of the CMNT in flight was consistent with ground test results. The colloid thruster performance model of thrust and thrust noise as a function of operational parameters (i.e. beam current, voltage, temperature, etc.) was validated in flight over a wide range of conditions. A model and simulation of the thruster control algorithm was developed and validated with flight data to predict thrust noise. This capability is important because it is considered to be a significant source of position noise on the spacecraft and, therefore, the acceleration noise on the test masses, which provide the gravity wave measurements. The CMNT thruster model data and validation with LISA Pathfinder/ST7-DRS flight experiments are discussed in this paper.

Hruby, Vlad↗

NASA NTRSDate not supplied

CFS Test Framework

NASA's Core Flight System (cFS) provides a generic flight software framework architecture for developing flight software. As the cFS framework has gained popularity over the years within the flight software community, supporting software tools have been developed to assist in the design, development, testing and verification of flight software. The cFS Test Framework (CTF) is a recently developed cFS tool with capabilities to develop and run automated test and verification scripts against flight software targets. The CTF tool parses and executes JSON-based test scripts containing test instructions, while logging and reporting the results. CTF utilizes a plugin-based architecture to allow developers to extend CTF with new test instructions, external interfaces, and custom functionality. To interface with flight software, CTF parses a set of CCSDS message definition files to create the necessary command and telemetry structures for use during the test run. Additionally, CTF also supports interfacing with multiple cFS instances, allowing a test script to verify requirements that involve multiple flight software targets. Lastly, CTF provides support for executing test scripts against FSW running on remote or embedded hardware. This allows CTF to execute the same test scripts across different target configurations throughout the development process. In this presentation, we will introduce the cFS Test Framework (CTF) architecture, discuss the history of cFS testing frameworks, and present the features and capabilities currently provided by CTF. Lastly, we will show a demo of the CTF tool being used to execute test scripts against flight software.

cfs↗

NASA NTRS2022

Advanced Lightweight Metallic Fuselage Project Manufacturing Trade Study

Recent advances in large-scale flow forming of integrally stiffened cylinders (ISCs) have motivated evaluation of available technologies for rapid manufacturing of metallic fuselages. The current state-of-the-art in flow forming of ISCs produces 10-ft. diameter, 5-ft. long barrels with integral longitudinal blade stiffeners, and these single-piece ISCs are produced in approximately 1.5 hours. While other manufacturing processes are required to incorporate additional structural elements (ASE) such as circumferential ring frames, reinforcements around window and door cut-outs, and floors to the ISCs to complete the fuselage structure, flow forming technology may assist the aerospace industry in meeting manufacturing rate demands. In order to evaluate this technology, a fuselage manufacturing demonstration article (MDA) fabricated from two ISCs is scheduled for fabrication and delivery to NASA Langley Research Center (LaRC) by the end of 2022. In this study, eight manufacturing technologies were assessed to downselect candidate manufacturing processes for adding ASE to complete the MDA. A literature review and evaluation of contractor-produced panels covering a spectrum of welding and additive manufacturing (AM) processes were conducted at NASA LaRC. The analytical hierarchy process (AHP) was used to evaluate figures of merit (FOMs) for selecting manufacturing process(es) to integrate ASE with the ISCs to form a fuselage MDA. The AHP results revealed that scalability, structural performance, and distortion control were the most valued criteria for downselecting the manufacturing process to construct the internal stiffening structures. Based on the FOMs, this study concluded that a welding process is best suited for integrating the majority of the ASE, namely the circumferential ring frames. All of the welding processes received higher scores than AM processes due to higher maturity, higher structural performance, fewer post-processing requirements in machining and heat treating, and faster deposition rates. Among the welding processes, cold metal transfer (CMT) welding was ranked the most favorable process for assembling the MDA, with the other welding processes (laser welding (LW), friction stir welding (FSW), and refill friction stir spot welding (RFSSW)) scoring slightly lower. This was a consequence of the perceived maturity of the CMT welding process and its relatively high structural performance and low distortion resulting from the low heat input. Among the AM processes, CMT AM showed the greatest promise due to benefits derived from its scalability, lower 1st order process complexity, and low distortion. The AM processes may have potential for select applications, such as adding structural reinforcements around window and door cut-outs, but are not considered optimal for integrating the entire MDA.

Manufacturing↗

NASA NTRS2022

FPP: A Modeling Language for F Prime

We present F Prime Prime (FPP), a new open-source modeling language for F Prime. F Prime is an open-source flight software framework developed at JPL and deployed, among other places, on the Mars helicopter Ingenuity. FPP provides a convenient way to model the architectural elements of an F Prime application, e.g., components, ports, and their connections. It has a succinct and readable syntax, a well- defined semantics, and robust error checking and reporting. The FPP tool suite, written in Scala, analyzes FPP models, reports errors, and translates correct FPP models to a combination of XML and C++. Existing F Prime tools translate the XML to a partial implementation in C++, to be completed by the developers. The model elements have clean interfaces and are highly reusable. An accompanying visualization tool constructs diagrams of components and connections that FSW developers can use to understand and communicate their designs, for ex- ample at reviews. We discuss the design and implementation of FPP and the integration of FPP into F Prime. We also discuss our experience using FPP to construct F Prime models. Finally, we discuss our plans for future work, including improved code generation, improved visualization, and more advanced analysis capabilities.

Starch, Michael D.↗

NASA NTRSDate not supplied

The Core Flight System (cFS): NASA Quality Flight Software to Power Science and Exploration Available to the World

The presentation is planned to be a continuation of two previous discussions completed at the FSW Workshop regarding the cFS Test Framework (CTF) and Engineering Data Sheets (EDS). The presentation will also cover the latest advancements in cFS, including: 1. Quick into to cFS 2. An overview of our software release process + Git repo 3. Release of EDS files for the cFE + open-source apps 4. Overview of how to independently verify EDS files using CTF + what they can be used for. 5. Future plans for cFS. This presentation complements the talk on configuration management of distributed cFS repos, to be presented by Tam Ngo from Johnson Space Center.

Dan Knutsen↗

NASA NTRS2022

Mars 2020 Perseverance Rover Surface Operations Commissioning Phase Overview

This paper presents work done by the Mars 2020 Project to plan, test, and execute the Mars 2020 Perseverance Rover surface operations commissioning phase. Immediately after the successful landing of Mars 2020 Perseverance rover at Jezero Crater on February 18, 2021, the rover autonomously initiated mission critical commanding necessary to transition the vehicle from a Cruise/EDL to Surface operations configuration. This began the surface operations commissioning phase, referred to as Surface Operations Transition (SOX). The objective of SOX phase is to establish vehicle health and safety and to verify that the operational characteristics of the vehicle, now operating in the Martian environment, are as-expected and safe to proceed into nominal operations. The SOX commissioning phase is organized into six logical sub-phases occurring in the following chronological order; (1) SOX1a, (2) FSW Transition, (3) SOX1b, (4) SOX2a, (5) Heli, (6) SOX2b. In total, the SOX commissioning phase was expected to take up-to 111 sols (Martian days). The Perseverance rover is an extremely complex, highly-integrated, robotic system-of-systems that requires numerous activities to incrementally and methodically verify their safe operations. This paper will discuss the development process used to plan, test, and execute the SOX commissioning phase for Mars 2020 Perseverance rover surface operations. We will discuss key challenges associated with SOX development as well as actual operations execution experience.

Koch, Justin↗

NASA NTRS2022

Making or Breaking a Rover: System Engineering Parameters On-Board the Mars 2020 Perseverance Rover

On February 18, 2021, Perseverance, NASA’s Jet Propulsion Laboratory’s (JPL’s) Mars 2020 Rover, successfully landed on Mars with all systems nominal, despite the risk surrounding the over 200,000 internal flight parameters that had to be properly configured. The Perseverance team defines these parameters as software variables that are configurable, commandable and retrievable from Earth. In 2015, the Mars 2020 project leaders focused on improving systems engineering of parameters based on their experiences from parameter management on previous Mars rovers (Curiosity, Opportunity, Spirit, and Pathfinder) and parameter failures of past missions, such as the mission-ending parameter of the Mars Climate Orbiter. The new rigorous development process allowed for efficient certification and effective implementation of the parameters, allowing the rover to approach and land on the red planet (the most challenging phase of the mission) with zero parameter issues. Although successful, the Perseverance team learned many lessons for how to better manage parameters for the continued surface operations of the Mars 2020 mission and future missions. This paper will discuss eight parameter-management topics for the Perseverance Mission. The first is parameter definition: how we define parameters on our mission, where they are physically located on the vehicle, and why we have so many of them. The second topic is the updated parameter flight software module from Curiosity, including details on the 99% reduction in parameter commands, new bulk configuration capabilities, and improved parameter traceability. The third topic is parameter selection for different mission phases; this includes improving and tweaking our preferred parameter settings until they become certification candidates and managing parameter configurations based on test venue throughout the mission life cycle. The fourth topic is our flight certification process; this includes certification of flight values for four different epochs in the mission: Launch, Entry Decent and Landing (EDL) - 6days, Landing + 5 Sols (Martian Days, still on Cruise Flight Software), and once are on Surface Flight Software (FSW). The fifth topic covers in-flight command implementation, along with details on testing, validation, and verification of those commands. In the sixth section, we will explain our use of open-source management tools, including how we used GitHub for version control and management approvals. The seventh topic will describe the ground tools used in operations, including capabilities of the in-house built tool called Parasol. The eighth and final topic will dig into lessons learned for improving parameter management in the future of this mission and others.

Roth, Brian↗

NASA NTRS2022

Making or Breaking a Rover- Systems Engineering Parameters On-Board the Mars 2020 Perseverance Rover

On February 18, 2021, Perseverance, NASA’s Jet Propulsion Laboratory’s (JPL’s) Mars 2020 Rover, successfully landed on Mars with all systems nominal, despite the risk surrounding the over 200,000 internal flight parameters that had to be properly configured. The Perseverance team defines these parameters as software variables that are configurable, commandable and retrievable from Earth. In 2015, the Mars 2020 project leaders focused on improving systems engineering of parameters based on their experiences from parameter management on previous Mars rovers (Curiosity, Opportunity, Spirit, and Pathfinder) and parameter failures of past missions, such as the mission-ending parameter of the Mars Climate Orbiter. The new rigorous development process allowed for efficient certification and effective implementation of the parameters, allowing the rover to approach and land on the red planet (the most challenging phase of the mission) with zero parameter issues. Although successful, the Perseverance team learned many lessons for how to better manage parameters for the continued surface operations of the Mars 2020 mission and future missions. This paper will discuss eight parameter-management topics for the Perseverance Mission. The first is parameter definition: how we define parameters on our mission, where they are physically located on the vehicle, and why we have so many of them. The second topic is the updated parameter flight software module from Curiosity, including details on the 99% reduction in parameter commands, new bulk configuration capabilities, and improved parameter traceability. The third topic is parameter selection for different mission phases; this includes improving and tweaking our preferred parameter settings until they become certification candidates and managing parameter configurations based on test venue throughout the mission life cycle. The fourth topic is our flight certification process; this includes certification of flight values for four different epochs in the mission: Launch, Entry Decent and Landing (EDL) - 6days, Landing + 5 Sols (Martian Days, still on Cruise Flight Software), and once are on Surface Flight Software (FSW). The fifth topic covers in-flight command implementation, along with details on testing, validation, and verification of those commands. In the sixth section, we will explain our use of open-source management tools, including how we used GitHub for version control and management approvals. The seventh topic will describe the ground tools used in operations, including capabilities of the in-house built tool called Parasol. The eighth and final topic will dig into lessons learned for improving parameter management in the future of this mission and others.

Roth, Brian↗