Search NASA⌕ Search

SEARCH · Search NASA

Results for “Mission Systems Architecture Process Modeling”

Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

262 records · Page 15
All sourcesNASA NTRSDOE OSTI
NASA NTRS2002

REACH: Real-Time Data Awareness in Multi-Spacecraft Missions

Missions have been proposed that will use multiple spacecraft to perform scientific or commercial tasks. Indeed, in the commercial world, some spacecraft constellations already exist. Aside from the technical challenges of constructing and flying these missions, there is also the financial challenge presented by the tradition model of the flight operations team (FOT) when it is applied to a constellation mission. Proposed constellation missions range in size from three spacecraft to more than 50. If the current ratio of three-to-five FOT personnel per spacecraft is maintained, the size of the FOT becomes cost prohibitive. The Advanced Architectures and Automation Branch at the Goddard Space Flight Center (GSFC Code 588) saw the potential to reduce the cost of these missions by creating new user interfaces to the ground system health-and-safety data. The goal is to enable a smaller FOT to remain aware and responsive to the increased amount of ground system information in a multi-spacecraft environment. Rather than abandon the tried and true, these interfaces were developed to run alongside existing ground system software to provide additional support to the FOT. These new user interfaces have been combined in a tool called REACH. REACH-the Real-time Evaluation and Analysis of Consolidated Health-is a software product that uses advanced visualization techniques to make spacecraft anomalies easy to spot, no matter how many spacecraft are in the constellation. REACH reads a real-time stream of data from the ground system and displays it to the FOT such that anomalies are easy to pick out and investigate. Data visualization has been used in ground system operations for many years. To provide a unique visualization tool, we developed a unique source of data to visualize: the REACH Health Model Engine. The Health Model Engine is rule-based software that receives real-time telemetry information and outputs "health" information related to the subsystems and spacecraft that the telemetry belong to. The Health Engine can run out-of-the-box or can be tailored with a scripting language. Out of the box, it uses limit violations to determine the health of subsystems and spacecraft; when tailored, it determines health using equations combining the values and limits of any telemetry in the spacecraft. The REACH visualizations then "roll up" the information from the Health Engine into high level, summary displays. These summary visualizations can be "zoomed" into for increasing levels of detail. Currently REACH is installed in the Small Explorer (SMEX) lab at GSFC, and is monitoring three of their five spacecraft. We are scheduled to install REACH in the Mid-sized Explorer (MIDEX) lab, which will allow us to monitor up to six more spacecraft. The process of installing and using our "research" software in an operational environment has provided many insights into which parts of REACH are a step forward and which of our ideas are missteps. Our paper explores both the new concepts in spacecraft health-and-safety visualization, the difficulties of such systems in the operational environment, and the cost and safety issues of multi-spacecraft missions.

Maks, Lori↗
NASA NTRS1998

Aerothermal Effects of Cavities and Protuberances for High-Speed Sample Return Capsules

Extraterrestrial sample return is a growing component of solar system exploration. Currently, four missions, Stardust, 1 Muses-C, 2 Genesis, and Mars Sample Return, are under development that employ sample return as a prime component of the mission architecture. Respectively, these missions will return samples from the tail of a comet, an asteroid, the solar wind, and, Mars. An important component of these missions and the focus of this paper is the design of the sample return capsule (SRC). The purpose of the SRC is to safely return to Earth any gathered samples for terrestrial analysis. The two major design constraints for any SRC are as follows: 1) it must be able to survive a high-speed Earth entry (11 km/s to as a high as 15 km/s), 2) the mass of the SRC must be as small as possible. Because the SRC mass is carried from Earth to the sample sight and back, the SRC mass is a strong driver in the mission mass budget. Further, for the Mars Sample Return Capsule, planetary protection is another constraint. For this capsule, the probability of planetary contamination at Earth due to an SRC failure at entry must be minimal. For an SRC, a possible failure mechanism is severe local heating as a result of cavities and or protuberances in the SRC forebody heatshield. For example, the Apollo Command Module had a number of cavities and protuberances as part of the baseline designs Wind-tunnel tests of models containing small cavities and protuberances showed severe local heating augmentations in the vicinity of these surface discontinuities.4-5 As another example, the Genesis SRC forebody heat-shield contains penetrations (cavities) to mount the vehicle to the carrier bus. It is expected that these penetrations will also experience a severe local heating environment. A concern is that the large thermal gradients may produce sufficient thermal stress to cause local mechanical failure of the heatshield. Penetrations to the forebody heat-shield can also result from damage at vehicle integration, during launch, or during transportation of the sample return capsule from earth to the sample site and back. For example, the Starting SRC was damaged near the shoulder during the heatshield integration process producing a local surface discontinuity. Also, the Starting SRC traverses through the tail of a comet and is in space for 7 years. Thus, damage to the heatshield as a result of micrometeroid impact is a concern. Finally, it is difficult to characterize the effects of these potential heatshield singularities with ground-test facilities. Either detailed simulation or a dedicated flight test is required.

Olynick, David↗
NASA NTRS2015

The Rapid Response Radiation Survey (R3S) Mission Using the HiSat Conformal Satellite Architecture

The Rapid Response Radiation Survey (R3S) experiment, designed as a quick turnaround mission to make radiation measurements in Low Earth Orbit (LEO), will fly as a hosted payload in partnership with NovaWurks using their Hyper-integrated Satlet (HISat) architecture. The need for the mission arises as the Nowcast of Atmospheric Ionization Radiation for Aviation Safety (NAIRAS) model moves from a research effort into an operational radiation assessment tool. Currently, airline professionals are the second largest demographic of radiation workers and to date their radiation exposure is undocumented in the USA. The NAIRAS model seeks to fill this information gap. The data collected by R3S, in addition to the complementary data from a NASA Langley Research Center (LaRC) atmospheric balloon mission entitled Radiation Dosimetry Experiment (RaD-X), will validate exposure prediction capabilities of NAIRAS. The R3S mission collects total dose and radiation spectrum measurements using a Teledyne μDosimeter and a Liulin-6SA2 LED spectrometer. These two radiation sensors provide a cross correlated radiometric measurement in combination with the Honeywell HMR2300 Smart Digital Magnetometer. The magnetometer assesses the Earth's magnetic field in the LEO environment and allows radiation dose to be mapped as a function of the Earth's magnetic shielding. R3S is also unique in that the radiation sensors will be exposed on the outer surface of the spacecraft, possibly making this the first measurements of the LEO radiation environment with bare sensors. Viability of R3S as an extremely fast turnaround mission is due, in part, to the nature of the robust, well-defined interfaces of the conformal satellite HiSat Architecture. The HiSat architecture, which was developed with the support of the Defense Advanced Research Projects Agency's (DARPA's) Phoenix Program, enabled the R3S system to advance from the first concept to delivery of preliminary design review (PDR) level documents in 29 calendar days. The architecture allows for interface complexities between the specific devices and the satellite bus to be resolved in a standardized interface control document (ICD). The ICD provided a readymade framework to interface to the modular satellite bus. This modularity allowed for approximately 90% of the R3S system to be designed and fabricated in two months without constraint of the hosting satellite's development cycle. This paper discusses the development of the R3S experiment as made possible by use of the HiSat architecture. The system design and operational modes of the experiment are described, as well as the experiment interfaces to the HiSat satellite via the user defined adapter (UDA) provided by NovaWurks. This paper outlines the steps taken by the project to execute the R3S mission in the 4 months of design, build, and test. Additionally portrayed is the ground work done at LaRC to posture the organization for a fast response and the process by which the opportunity was identified as aligning with key strategic goals. Finally, a description of the engineering process is provided, including the use of facilitated rapid/concurrent engineering sessions, the associated documentation, and the review process employed.

Miller, Nathanael A.↗
NASA NTRS2010

Product Lifecycle Management and the Quest for Sustainable Space Exploration Solutions

Product Lifecycle Management (PLM) is an outcome of lean thinking to eliminate waste and increase productivity. PLM is inextricably tied to the systems engineering business philosophy, coupled with a methodology by which personnel, processes and practices, and information technology combine to form an architecture platform for product design, development, manufacturing, operations, and decommissioning. In this model, which is being implemented by the Engineering Directorate at the National Aeronautics and Space Administration's (NASA's) Marshall Space Flight Center, total lifecycle costs are important variables for critical decisionmaking. With the ultimate goal to deliver quality products that meet or exceed requirements on time and within budget, PLM is a powerful tool to shape everything from engineering trade studies and testing goals, to integrated vehicle operations and retirement scenarios. This paper will demonstrate how the Engineering Directorate is implementing PLM as part of an overall strategy to deliver safe, reliable, and affordable space exploration solutions. It has been 30 years since the United States fielded the Space Shuttle. The next generation space transportation system requires a paradigm shift such that digital tools and knowledge management, which are central elements of PLM, are used consistently to maximum effect. The outcome is a better use of scarce resources, along with more focus on stakeholder and customer requirements, as a new portfolio of enabling tools becomes second nature to the workforce. This paper will use the design and manufacturing processes, which have transitioned to digital-based activities, to show how PLM supports the comprehensive systems engineering and integration function. It also will go through a launch countdown scenario where an anomaly is detected to show how the virtual vehicle created from paperless processes will help solve technical challenges and improve the likelihood of launching on schedule, with less hands-on labor needed for processing and troubleshooting. Sustainable space exploration solutions demand that all lifecycle phases be optimized. Adopting PLM, which has been used by the automotive industry for many years, for aerospace applications provides a foundation for strong, disciplined systems engineering and accountable return on investment by making lifecycle considerations variables in an iterative decision-making process. This paper combines the perspectives of the founding father of PLM, along with the experience of Engineering leaders who are implementing these processes and practices real-time. As the nation moves from an industrial-based society to one where information is a valued commodity, future NASA programs and projects will benefit from the experience being gained today for the exploration missions of tomorrow.

Caruso, Pamela W.↗
NASA NTRS2016

Cryogenic Selective Surfaces

There are many challenges involved in deep-space exploration, but several of these can be mitigated, or even solved, by the development of a coating that can reject most of the Sun's energy and yet still provide some far-infrared heat emission. Such a coating would allow non-heat-generating objects in space to reach cryogenic temperatures without using an active cooling system. This would be a benefit to deep-space sensors that require low temperatures, such as the James Webb Telescope focal plane array. It would also allow the use of superconductors in deep space, which could lead to magnetic energy storage rings, lossless power delivery, or perhaps a large-volume magnetic shield against galactic cosmic radiation. But perhaps the most significant enablement achieved from such a coating would be the long-term storage in deep space of cryogenic liquids, such as liquid oxygen (LOX).In this report, we review the state of the art in low-temperature coatings and calculate the lowest temperatures each of these can achieve, demonstrating that cryogenic temperatures cannot be reached in deep space in this fashion. We then propose a new coating that does allow coated objects in deep space to achieve the very low temperatures required to store liquid oxygen or nitrogen. These new coatings consist of a moderately thick scattering layer (typically 5 mm) composed of a material transparent to most of the solar spectrum. This layer acts as a scatterer to the Sun's light, performing the same process as titanium dioxide in white paint in the visible. Under that layer, we place a metallic reflector, e.g. silver, to reflect long-wave radiation that is not well scattered. The result is a coating we call "Solar White," in that it scatters most of the solar spectrum just as white paint does for the visible. Our modeling of these coatings has shown that temperatures as low as 50 K can be reached for a coated object fully exposed to sunlight at 1 AU from the Sun and far from the Earth.In the second half of the report we explore a mission application of this coating in order to show that it allows LOX to be carried on a mission to Mars. Heat can reach a LOX tank in five ways: direct radiation from the Sun, scattered or reflected radiation from the Sun off of spacecraft components, radiation from nearby planets or the Moon, radiation from the infrared emission of other parts of the spacecraft, and conduction along support struts and flow lines. We discuss these and sum their total contribution when using a Solar White coating to demonstrate an architecture that allows the transportation of LOX to Mars. After this, other applications of Solar White are listed.

Cryogenic Materials↗
NASA NTRS2021

Assessment of M2020 Terrain Relative Landing Accuracy: Flight Performance vs Predicts

Terrain Relative Navigation (TRN) was a critical enabling Entry, Descent, and Landing (EDL) technology that enabled Mars 2020 mission Perseverance rover to land at Jezero crater. TRN pro-vides real-time, autonomous, map-relative position determination and generates a landing target based on a priori knowledge of hazards. The required performance for TRN was to land within 60m of the selected target. The required 60m was sub-allocated to various error sources in three major categories: targeting error, knowledge error, and control error. The targeting error is the error in selecting an appropriate landing target and the knowledge of the target on the surface. It includes the Lander Vision System (LVS) position localization with respect the ground, the synchronization between the Lander Vision System measurement and the main Navigation filter, and errors associated with the LVS Reference Map and Safe Target Selec-tion (STS). The knowledge error is the contribution of knowledge growth from the synchronization with LVS to touchdown. The control error encompasses how accurately the system could stay on the desired reference trajectory. The TRN error budget uses a combination of analysis, simulation, and hardware test-ing results to bound the various error contributions obtained during the verification and validation process. This paper first presents a description the TRN system, focusing on the architecture of LVS and STS. The paper then gives detailed overview of the TRN error budget, with a description of the major error contribu-tions in each of the three categories. Next, the paper gives the results for three versions of the error budget, pre-launch, in-flight pre-landing, and post-landing. The paper compares the pre-flight analysis, the pre-landing analysis using in-flight data during cruise, to the post-landing analysis of the TRN performance. Pre-landing analysis best estimate of the landing performance was 33m, compared to the 60m require-ment. Post-landing analysis estimated a landing accuracy of 8.53m or better, much better than the 33m pre-landing estimate. The actual post-landing imagery calculated the distance of the rover to the targeted location to be 5m. The post-landing analysis closely bounds the image-based assessment of landing accu-racy, indicating the success of the error budget architecture in bounding the landing accuracy, as well as the fidelity of the simulations used to model and predict performance.

Chen, Allen↗
NASA NTRSDate not supplied

22 N HPGP Thruster Life Testing

In the ever-changing paradigm of efficient and capable spacecraft design, scientific missions continue pushing the envelope enabling spacecraft subsystems to deliver effective solutions to meet challenging new mission/spacecraft needs. From an in-space storable liquid chemical propulsion perspective, monopropellant hydrazine has been, and continues to be, a dependable propellant with considerable flight heritage, a variety of engine thrust classes available from multiple vendors, with repeatable and reliable performance. Additionally, the space propulsion industry has learned to successfully handle hydrazine, its regulations, the safety protocols, the personnel protective equipment, and the unique training standards–all requisite for loading spacecraft propulsion systems with toxic hypergolic hydrazine. The question now arises as to “what is next for in-space chemical propulsion?” Further, with the evolution and concrete advancements in innovative in-space green propellant technologies, capable of providing realizable benefits to scientific missions, concern over the reliability and availability of this higher performing and safer to handle class of propellants is waning. As science missions move forward with the potential flight in fusion of High Performance Green Propulsion (HPGP), NASA and its industry partners are working to address any gaps in system reliability, performance, or unique operational considerations. Propellant technology that offers both higher performance and significant reduction in personnel hazards compared to hydrazine presents an attractive propulsion subsystem design opportunity. Increased propulsion subsystem performance can result in lower spacecraft launch mass, larger scientific payloads, or extended on-orbit lifetimes. Mission trades using green propulsion technologies have been documented on multiple NASA Goddard Space Flight Center (GSFC) mission classes, examining various parameters and requirements to support mission architectures in Low Earth Orbit (LEO), High Earth Orbit (HEO), geostationary, lunar, planetary, and Quasi-halo orbit around Sun-Earth Lagrange point (L2). The results of these trade studies show promising, attainable benefits. The perceived programmatic risk of flying a newer propulsion technology has, unfortunately, not outweighed the benefits to date. To take advantage of the improved performance and mitigate programmatic risk, HPGP engines must demonstrate life testing at higher propellant throughputs than have currently been demonstrated. In an effort to proactively address the challenges with technology infusion into a risk-averse community, NASA and the Swedish National Space Agency (SNSA) outlined a collaborative Implementing Arrangement (IA) for the respective agencies to pursue increased HPGP technology maturation. This initial IA effort began in 2013, fresh off the heels of the successful PRISMA HPGP technology demonstration mission. The IA targeted objective is to reduce risk to potential future HPGP missions and fully characterize the LMP-103S propellant and associated engine performance. Over the past eight years, HPGP has flown in propulsion systems on twenty-five(25) spacecraft from seven(7) different Launch Ranges around the globe and on seven (7) different Launch Vehicles. Six(6) of these launches involved multiple loading operations for multiple spacecraft. For U.S. Range operations, nine (9) HPGP systems have been processed at Vandenberg Space Force Base(VSFB):six(6) in 2017, and three (3) in 2018. Six (6) more have been processed at Cape Canaveral Air Force Station (CCAFS)in May 2020, with three (3) systems launched in June 2020 and the remaining three (3) system were left loaded and ready until their launch in August of 2020. Three (3) more systems have been processed at Wallops Flight Facility(WFF)and launched in June 2021. In addition, these propulsion subsystems employed heritage propulsion subsystem component such as valves, filters, and pressure transducers, and have further demonstrated nominal functionality in both diaphragm and Propellant Management Device (PDM) propellant tanks. Based on these successes, HPGP technology continues to be considered for NASA Science Mission Directorate missions at GSFC. The work presented herein represents many years of development and collaborative efforts to successfully align higher performance, low toxicity hydrazine alternatives into scientific missions. NASA GSFC Propulsion Engineering, in collaboration with Bradford ECAPS, has developed mission specific thruster design and testing requirements to establish GSFC’s desired test conditions and firing sequences.In2017, the first flight-like 22N HPGP thruster Engineering Qualification Model (EQM-1)was designed and built by Bradford ECAPS to prove out the thruster design, materials, build process, and test campaign with respect to NASA GSFC critical component and mission requirements. This test program was developed to comprehensively test the thruster, the technology, and ultimately increase the 22N HPGP Technology Readiness Level(TRL). EQM-1was tested to environmental qualification levels prior to hot fire performance testing to represent the relevant end-to-end environment (launch to on-orbit operation)with required margin. This thruster demonstrated steady-state and pulse mode operational capability with propellant thruster throughput up to~53kg.At this throughput level, the EQM-1 engine began to present off-nominal performance and the test campaign was halted to allow for non-destructive testing and identify the root cause for the an omalous performance. Capitalizing on the successful elements of the EQM-1 campaign, an upgraded 22N HPGP EQM-2 has been manufactured by Bradford ECAPS to meet the complete GSFC requirements. The EQM-2 thruster’s test campaign has further demonstrated the robustness of the HPGP propulsion technology and increased the Technology Readiness Level (TRL) by undergoing a full acceptance test program, then proceeding into qualification, including environmental testing (vibration and shock to qualification levels),as well as hot-fire life testing, operating at steady-state and pulse modes with increased propellant thruster throughput to~150kg. The HPGP thruster performance testing enables effective HPGP thruster readiness evaluation to meet NASA candidate mission requirements in the future.

High↗
NASA NTRS2016

Modeling in the State Flow Environment to Support Launch Vehicle Verification Testing for Mission and Fault Management Algorithms in the NASA Space Launch System

Analysis methods and testing processes are essential activities in the engineering development and verification of the National Aeronautics and Space Administration's (NASA) new Space Launch System (SLS). Central to mission success is reliable verification of the Mission and Fault Management (M&FM) algorithms for the SLS launch vehicle (LV) flight software. This is particularly difficult because M&FM algorithms integrate and operate LV subsystems, which consist of diverse forms of hardware and software themselves, with equally diverse integration from the engineering disciplines of LV subsystems. M&FM operation of SLS requires a changing mix of LV automation. During pre-launch the LV is primarily operated by the Kennedy Space Center (KSC) Ground Systems Development and Operations (GSDO) organization with some LV automation of time-critical functions, and much more autonomous LV operations during ascent that have crucial interactions with the Orion crew capsule, its astronauts, and with mission controllers at the Johnson Space Center. M&FM algorithms must perform all nominal mission commanding via the flight computer to control LV states from pre-launch through disposal and also address failure conditions by initiating autonomous or commanded aborts (crew capsule escape from the failing LV), redundancy management of failing subsystems and components, and safing actions to reduce or prevent threats to ground systems and crew. To address the criticality of the verification testing of these algorithms, the NASA M&FM team has utilized the State Flow environment6 (SFE) with its existing Vehicle Management End-to-End Testbed (VMET) platform which also hosts vendor-supplied physics-based LV subsystem models. The human-derived M&FM algorithms are designed and vetted in Integrated Development Teams composed of design and development disciplines such as Systems Engineering, Flight Software (FSW), Safety and Mission Assurance (S&MA) and major subsystems and vehicle elements such as Main Propulsion Systems (MPS), boosters, avionics, Guidance, Navigation, and Control (GN&C), Thrust Vector Control (TVC), liquid engines, and the astronaut crew office. Since the algorithms are realized using model-based engineering (MBE) methods from a hybrid of the Unified Modeling Language (UML) and Systems Modeling Language (SysML), SFE methods are a natural fit to provide an in depth analysis of the interactive behavior of these algorithms with the SLS LV subsystem models. For this, the M&FM algorithms and the SLS LV subsystem models are modeled using constructs provided by Matlab which also enables modeling of the accompanying interfaces providing greater flexibility for integrated testing and analysis, which helps forecast expected behavior in forward VMET integrated testing activities. In VMET, the M&FM algorithms are prototyped and implemented using the same C++ programming language and similar state machine architectural concepts used by the FSW group. Due to the interactive complexity of the algorithms, VMET testing thus far has verified all the individual M&FM subsystem algorithms with select subsystem vendor models but is steadily progressing to assessing the interactive behavior of these algorithms with LV subsystems, as represented by subsystem models. The novel SFE applications has proven to be useful for quick look analysis into early integrated system behavior and assessment of the M&FM algorithms with the modeled LV subsystems. This early MBE analysis generates vital insight into the integrated system behaviors, algorithm sensitivities, design issues, and has aided in the debugging of the M&FM algorithms well before full testing can begin in more expensive, higher fidelity but more arduous environments such as VMET, FSW testing, and the Systems Integration Lab7 (SIL). SFE has exhibited both expected and unexpected behaviors in nominal and off nominal test cases prior to full VMET testing. In many findings, these behavioral characteristics were used to correct the M&FM algorithms, enable better test coverage, and develop more effective test cases for each of the LV subsystems. This has improved the fidelity of testing and planning for the next generation of M&FM algorithms as the SLS program evolves from non-crewed to crewed flight, impacting subsystem configurations and the M&FM algorithms that control them. SFE analysis has improved robustness and reliability of the M&FM algorithms by revealing implementation errors and documentation inconsistencies. It is also improving planning efficiency for future VMET testing of the M&FM algorithms hosted in the LV flight computers, further reducing risk for the SLS launch infrastructure, the SLS LV, and most importantly the crew.

Trevino, Luis↗
NASA NTRS2020

Is Structured Agile an Oxymoron? Tales from Implementing and Executing Agile in a US Government Environment

To paraphrase a famous quote, "No plan survives contact with the reality." Software (SW) development is often a classic example of this: whatever the plan was for a particular development, it often does not survive contact with technical realities, budget realities, program realities and schedule realities. Traditionally, SW development has followed a waterfall methodology with requirements being rigorously specified before the design, which was completed before the coding and unit testing started, which were in turn finished before validation and verification started. This model of SW engineering derives much from the HW engineering of large systems, and has been the standard methodology used in US government software acquisitions and systems for decades, with highly variable results. US Government SW requirements are built around Waterfall concepts, which assume that the plan will survive contact with reality, or at least that modifications to the plan are relatively small, and relatively few.Because of the inefficiencies and difficulties inherent in Waterfall, the commercial SW world started using a different SW development methodology called Agile more than 20 years ago. Agile believes that a plan should evolve and learn rapidly in response to the realities encountered. At its core, there are a few key elements of Agile:- A small team of people which is highly flexible and adaptive. The team collaborates and interoperates through sophisticated development architectures and release environments- An iterative, incremental development and release approach which is based upon the concept that knowledge comes from experience within the team, and that the team makes decisions based upon what it knows- A team culture which prizes transparency, inspection and adaptation. These values are necessary so that the team experience and decision making is transparent and responsive to the realities encountered during development and testingSo, how to use Agile in a US Government environment? GMSEC (Goddard Mission Services Evolution Center) develops satellite ground system software for NASA and other US Government agencies. The SW developed by the team contains a large code base of many applications used within satellite mission operations centers. It spans the full gamut of SW development types: from SW which is in a classic maintenance and sustainment mode, to new developments with a fairly well understood scope and approach, to new developments whose scope and approach are quite unclear and which require significant research and prototyping. Team members move between all of these different types of SW development. Waterfall was inadequate to the programmatic and technical needs of the team, as well as the various types of SW development being done. The software plan was not surviving contact with the technical and programmatic realities experienced by the team. To address this, the team started a small pilot project in 2016 to test the use of Agile within a small subset of the team for a new web services application. In early 2018, the use of Agile was expanded to the whole team and all the software, but we had to fulfill the NASA SW development requirements. And we needed to do this while still remaining true to the key Agile elements of transparency, inspection and adaption. In order to do this, the team worked very closely with the Software Process Improvement (SPI) team at NASA Goddard, as well as NASA engineering manageme

Beech, Theresa W.↗
NASA NTRS2024

Flight Mechanics Modeling and Simulation of the Earth Entry System

Introduction: The Mars Sample Return (MSR) Campaign being planned by NASA and ESA has the ambitious goal to return Mars samples back to Earth. This international collaboration had developed a concept of operations that included a ESA-designed Earth Return Orbiter (ERO) and NASA-designed Capture, Containment, and Return System (CCRS). The Earth Entry System (EES), consisting of a protective aeroshell that houses the samples as well as sample containment vessels, would conduct entry, descent, and landing (EDL) on a direct Earth trajectory. The EES would enter on a spin-stabilized ballistic trajectory with the goal to passively achieve aerodynamic stability throughout all regions of flight. The EDL sequence would end with the EES impacting the soft playa soil of the Utah Test and Training Range (UTTR). As of the submission of this abstract, the MSR campaign is undergoing a re-architecture leading to a pause in EES development. However, the novel approaches developed in flight mechanics modeling and simulation can significantly benefit the greater IPPW community in the development of Earth return vehicles. This paper will present the latest state of EES flight mechanics modeling and simulation. The paper will highlight the simulation architecture developed and key lessons learned from understanding of EDL trajectory sensitivities. Modeling and Simulation: Figure 1 provides a high-level concept of operations for the approach, entry, descent, and landing (AEDL) phase of the CCRS-portion of MSR. The objective of EES flight mechanics is to model and simulate the EES trajectory from ERO separation to ground impact at UTTR. A variety of flight mechanics simulation models were utilized to model both exo-atmopsheric and atmospheric portions of flight. 42, a 6-DOF simulation developed at Goddard Space Flight Center, is utilized for propagating the attitude of EES during exo-atmospheric flight. 42 allows for a variety of spin eject mechanism scenarios to be simulated for analysis. 10 minutes prior to entry, the 42 states are handed off to the EDL sims. The prime EDL sim utilized by EES is the Program to Optimize Simulated Trajectories II (POST2), a 6-DOF sim developed at Langley Research Center, and the independent verification and validation EDL sim utilized is DSENDS, a 6-DOF sim developed at Jet Propulsion Laboratory. Figure 2 provides a visualization of the flight mechanics simulation model flow through various points in the AEDL phase. Due to the existence of a variety of sim models, the EES flight mechanics team developed processes for data hand-off. These processes included the development of a centralized coordinate frame document, utilization of a single, centralized simulation input document for all sims to reference, and hand-off files containing both the technical data to be ingested by other flight mechanics sims as well as annotations of modeling assumptions utilized to generate the data. Figure~\ref{fig:post2simarchitecture} provides an overview of the POST2 sim architecture wherein POST2 ingests numerous subsystem models and input files. The dispersed state file generated by MONTE provides the position/velocity state of the trajectory while the 42 Handoff file provides the attitude. The aerodynamics database, delivered by the EES aeroscience team, is utilized to simulate the aerodynamic forces and moments experienced during EDL. A custom atmosphere model, developed by EES atmosphere team, is utilized to simulate the anticipated atmosphere environment around the region of Earth through which the EES trajectory flys. These inputs and subsystem models can be varied depending on the AEDL flight mechanics scenario being simulated. Monte Carlo simulations are utilized to generate statistical AEDL performance metrics in the form of scorecards and violin plots. Furthermore, outputs from the POST2 simulation are utilized for follow-on analyses including aerothermal and landing performance. \section{Flight Mechanics Lessons Learned} Though the EES flight mechanics team uncovered a variety of lessons learned through the analysis conducted to support CCRS through preliminary design review, this paper will highlight the most important lessons. A key AEDL performance goal is to ensure the landing footprint of EES remains on the UTTR south range. A common modeling strategy used in EDL analysis is One-Variable-At-a-Time (OVAT). OVAT analysis provides insight into the key drivers that affect AEDL performance metrics. Figure 3 shows the landing ellipses for single dispersion sources as compared to the baseline aggregate of all dispersions. The figure shows that atmosphere winds alone dominate the size of the footprint ellipse (note: EES does not use a parachute unlike previous Earth-return missions and is in wind-driven free fall for ~5min). The significance of the wind led the EES flight mechanics team to pursue the development of a Custom Atmosphere Model [4], in lieu of EarthGRAM [1], built on actual radiosonde wind measurements around the UTTR-region. This decision was driven by the realism in the generated footprint ellipses and lessons-learned from Stardust [5]. These findings will be invaluable for future Earth-return missions in providing an early understanding of the key drivers affecting footprint size and modeling considerations for which to account. Another lesson learned is tied to the AEDL performance goal of achieving passive stability throughout all regions of flight. It is well understood that blunt-body aeroshells are less stable as they transition from supersonic to subsonic. Eliminating a backshell does help improvestability; however, other phenomena such as roll-induced instability during terminal descent can still arise. The EES flight mechanics team developed stability metrics as tools to better understand the causes of and better predict the onset of dynamic instability. These tools were built upon analytical models developed by Jaffe [3] and Murphy [2]. The tools were shown to both be very accurate in correlation with actual unstable cases and useful in developing stability margin policies based on the vehicle design and simulation considerations (e.g. sphere-cone angle change, mass change, wind turbulence). These tools allowed for the current EES design to demonstrate the ability to achieve passive stability and can be an invaluable tool for consideration in the design of parachute-less Earth-return vehicles.

Rohan Deshmukh↗