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.

258 records · Page 15
All sourcesNASA NTRSDOE OSTI
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↗