Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “process development”

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.

At least 1,621 records · Page 90
All sourcesNASA NTRSDOE OSTI
NASA NTRSDate not supplied

Assessing the Needs for Space Reactor Standards

A U.S. governmental interagency space reactor standards working group (SWG) was convened to address the limited availability of voluntary consensus standards currently in place specifically for space nuclear reactor design and safety. The SWG focused on reviewing existing standards, assessing agency needs, specifying gaps that could be addressed by new standards, and prioritizing those gaps through consensus group deliberations. The SWG identified a series of findings and recommendations relative to the development of space reactor standards, including moving three specific high-priority gap items to be pursued through a consensus standards development process: Safety and Risk Analysis Methods for Space Reactors, Testing Requirements for Space Reactors, including Facility Requirements, and Safe Operating Practices for Space Reactors.

Andrew Klein↗
NASA NTRSDate not supplied

STMD-GCD Reactive Additive Manufacturing for Fourth Industrial Revolution Exploration Systems (RAMFIRE)

Elementum 3D, in partnership with NASA-MSFC under an ACO, seeks to help further increase launch performance and reduce launch and mission cost by advancing novel additively manufactured (AM) aluminum materials for large-scale complex rocket components and launch vehicle structures. The proposed outcome of this ACO is to advance large-scale directed energy deposition (DED) of highstrength aluminum alloys through process development, characterization, and testing.

RAMFIRE↗
NASA NTRSDate not supplied

Realizing a Spacesuit Compatible Augmented Reality System to Meet the Work Needs of Future Human Spaceflight Exploration

In this paper, we identify the broad range of challenges associated with creating an augmented reality for future spaceflight missions. The challenges were framed within a sociotechnical framework to explore how an imagined augmented reality system might one day help crew cope with future exploration mission demands. Key challenges include an augmented reality system cannot simply be designed to help a single suited astronaut and must enable the broader mission team. There exists a host of optical, compute, and control technical challenges that must be simultaneously addressed while the work domain itself is in development. There exist limited methods to help cope with the envisioned world problem; however, we emphasize a few strategies to articulate work design assumptions and host this detail in a transparent fashion. Finally, we note the broader organizational constraints that shape the creation of such novel technology for spaceflight. By addressing these broad range of challenges directly, early in the design and development process, key trade-offs can be considered and fundamental concerns within the community can be addressed to yield desired mission outcomes.

Matthew J. Miller↗
NASA NTRSDate not supplied

SERVIR: Cross-Comparison of Carbon Emission Estimates Based on Variable Land Use Land Cover Changes within SERVIR Focus Regions

Deforestation in the tropics contributes approximately one-fifth of the annual global greenhouse gas (GHG) emissions. In an effort to reduce GHG emissions, SERVIR - a joint USAID and NASA initiative - is currently implementing the SERVIR CArbon Pilot (S-CAP) activity. By developing a comprehensive CO2 tracking system in Google Earth Engine based on both remotely sensed data and in situ observations, S-CAP aims to build capacity within the SERVIR regional hubs to improve decision making and local monitoring efforts surrounding GHG emissions. The S-CAP estimations are being completed throughout 11 pilot countries within the SERVIR regions of Asia, Africa, and the Americas to integrate partner contributions and local input into the development process. These emission estimate calculations use country-level REDD+ FREL reported values, global remotely sensed data (e.g. Global Forest Watch) and regional datasets and are completed using the IPCC Guidelines for National Greenhouse Gas Inventories. From the S-CAP activity thus far, country CO2 estimations had varied differences, ranging from 56% to 197% between their lowest and highest estimates. The results from this study show that CO2 emission estimates can differ greatly depending on the land cover data sets used as well as the biomass values, and how a comprehensive database is essential in understanding the full range of impacts that land cover change has in these regions. Using this ensemble approach, SERVIR hubs can better select the most appropriate datasets available for estimating emissions.

Carbon Emission↗
NASA NTRSDate not supplied

Core Stage TVC Systems Engineering Challenges in Reusing Heritage Hardware

The Space Launch System (SLS) Core Stage (CS) Thrust Vector Control (TVC) system is comprised of 8 mechanical feedback Shuttle heritage Type III TVC actuators and four RS-25 engines, each attached to a Shuttle heritage gimbal block/bearing. Two actuators are used to move each engine in two planes perpendicular to one another (i.e., pitch and yaw). The TVC system design leverages hardware from the Space Shuttle program as well as new hardware designed specifically for the Core Stage. The Space Shuttle heritage hardware directly reused on SLS includes the Orbiter TVC hydraulic servo-actuators (with two slight design modifications), the Orbiter hydraulic circulation pumps, the Orbiter gimbal block/bearing, and the Solid Rocket Booster hydraulic pumps. The Core Auxiliary Power Unit (CAPU) is derived from the Orbiter Auxiliary Power Unit (APU). The Orbiter and Solid Rocket Booster APU turbines are powered by hot gas produced by catalyzed hydrazine decomposition. On the SLS Core Stage, the CAPU turbine is spun using cold gas tapped-off from the RS-25 to CS liquid hydrogen autogenous pressurization line. While direct reuse or slight modification of existing hardware may seem to be a triple-win for a program in cost, schedule, and technical risk mitigation, those benefits can only be realized when its degree of application in a new system is carefully and thoughtfully managed. The heritage hardware reuse should be prescribed within the heritage design capability and reuse environments must lie within the envelope of heritage qualification testing. Despite the significant test and flight experience of the Shuttle heritage hardware components, successful integration with the newly designed CS TVC components and incorporation into the stage design proved to be a challenge which required re-qualification of the heritage hardware as well as thorough integrated testing to support flight certification. Examples of the challenges that were overcome include: re-qualifying heritage hardware to survive new shock and vibration environments, certifying performance of extensively modified heritage hardware, regenerating design insight due to lack of available heritage vendor data, showing compliance to modern structural design standards, translation of heritage requirements for analog avionics to modern digital avionics, and interfacing heritage mechanical hardware with newly designed avionics. This paper is the second installment in a seven-paper series surveying the design, engineering, test validation, and flight performance of the Core Stage Thrust Vector Control system. This paper will discuss several engineering challenges encountered during the development process for SLS CS TVC and how they were successfully overcome to reach flight readiness.

Thrust Vector Control↗
NASA NTRSDate not supplied

Space Launch System: Core Stage Thrust Vector Control Systems Engineering Challenges in Reusing Heritage Hardware

The Space Launch System (SLS) Core Stage (CS) Thrust Vector Control (TVC) system is comprised of 8 mechanical feedback Shuttle heritage Type III TVC actuators and four RS-25 engines, each attached to a Shuttle heritage gimbal block/bearing. Two actuators are used to move each engine in two planes perpendicular to one another (i.e., pitch and yaw). The TVC system design leverages hardware from the Space Shuttle program as well as new hardware designed specifically for the Core Stage. The Space Shuttle heritage hardware directly reused on SLS includes the Orbiter TVC hydraulic servo-actuators (with two slight design modifications), the Orbiter hydraulic circulation pumps, the Orbiter gimbal block/bearing, and the Solid Rocket Booster hydraulic pumps. The Core Auxiliary Power Unit (CAPU) is derived from the Orbiter Auxiliary Power Unit (APU). The Orbiter and Solid Rocket Booster APU turbines are powered by hot gas produced by catalyzed hydrazine decomposition. On the SLS Core Stage, the CAPU turbine is spun using cold gas tapped-off from the RS-25 to CS liquid hydrogen autogenous pressurization line. While direct reuse or slight modification of existing hardware may seem to be a triple-win for a program in cost, schedule, and technical risk mitigation, those benefits can only be realized when its degree of application in a new system is carefully and thoughtfully managed. The heritage hardware reuse should be prescribed within the heritage design capability and reuse environments must lie within the envelope of heritage qualification testing. Despite the significant test and flight experience of the Shuttle heritage hardware components, successful integration with the newly designed CS TVC components and incorporation into the stage design proved to be a challenge which required re-qualification of the heritage hardware as well as thorough integrated testing to support flight certification. Examples of the challenges that were overcome include: re-qualifying heritage hardware to survive new shock and vibration environments, certifying performance of extensively modified heritage hardware, regenerating design insight due to lack of available heritage vendor data, showing compliance to modern structural design standards, translation of heritage requirements for analog avionics to modern digital avionics, and interfacing heritage mechanical hardware with newly designed avionics. This paper is the second installment in a seven-paper series surveying the design, engineering, test validation, and flight performance of the Core Stage Thrust Vector Control system. This paper will discuss several engineering challenges encountered during the development process for SLS CS TVC and how they were successfully overcome to reach flight readiness.

Thrust Vector Control↗
NASA NTRSDate not supplied

Analysis of the Artemis I Orion Spacecraft Power System Performance

NASA successfully completed an uncrewed test flight of the Orion spacecraft during the 26-day Artemis I mission in November and December 2022. The Artemis I mission profile included several potentially stressing features for Orion electrical power system (EPS) performance, including eclipse duration, multiple propulsive or navigational maneuvers which constrained positioning of the solar array wings (SAWs), and the proximity and phasing of various events together. All of these features vary significantly with Earth-sun-moon geometry, providing a unique challenge for predicting EPS performance before an exact launch date is known. This presentation will provide a brief mission overview, discuss the different computer models with varying levels of fidelity used to analyze Orion EPS performance, as well as the screening process developed to incorporate EPS performance as a consideration for launch epoch selection. Final preflight model predictions of EPS performance will be compared to in-flight telemetry measurements, and several EPS anomalies observed will be briefly discussed.

Orion↗
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↗
NASA NTRS2022

Reliability-Aware Requirements Development for Autonomy Software

Autonomy is the ability of a system to make decisions and take actions in the presence of uncertainty. Validating autonomy, therefore, is a matter of validating that the system makes intelligent decisions even when there might be discrepancies between the observed and the expected state of the world as well as when the possible outcome of each of the possible courses of action is uncertain. During the requirements engineering phase, the functions, including those that are required to be autonomous and their expected behavior are specified. However, in the case of autonomous software system, it is challenging to specify all possible scenarios that the software may encounter. Additionally, since autonomous behaviors cannot always be fully predetermined, it is difficult to reason about their completeness and correctness. While these challenges are also faced with non-autonomous system, they are more prevalent for autonomous system due to their complexity and emergent behavior. Our efforts have been three-fold. On one hand, we have developed a goal-based method for requirements decomposition. We have embedded this approach into a higher-level systems engineering framework and then developed methods for decision and reliability analysis within this framework. And finally, we use simulation analysis to validate the more theoretical methods and provide a feedback mechanism. The decision analysis approach (DA) helps in identifying and mitigating the run-time risks, by bringing to the forefront the uncertainties, decisions, interactions, and other factors that may cause autonomous software to make erroneous decisions. The DA framework is used to quantify, for each decision that the software can make, failure risk due to uncertainties. The information about the key decisions and circumstances that can cause autonomous system to make incorrect decisions are used to generate test scenarios to be run in a simulator to ensure that the system can handle error-prone circumstances. The results or outcomes from decisions, based on the simulated scenarios, can then be leveraged to further gain insight of the assured system. We combine a goal-based approach with simulation analysis to facilitate requirements development for autonomous systems and further provide a method for run-time systems level reliability considerations during the autonomous software development process. The DA and the reliability analysis methods provide a formalism for the consideration of uncertainty in the run time decision-making process for autonomous software. This formalism considers the uncertainty involved in the outcome of different courses of action, in terms of performance and cost, as well as a method to consider the system level reliability implications. System level reliability considerations for autonomous software decision making contribute to the satisfaction of the system level goals over the lifecycle of a given mission. We demonstrate our approach using a hypothetical rover path planning example. The requirements for our rover simulator are based on existing literature about Mars rovers and lessons learned from real world observations at JPL. The specifics of the autonomy design for the Mars rovers, that have not been previously cleared for external release, are not used for our demonstrations.

Lindvall, Mikael↗
NASA NTRSDate not supplied

A Four-Stage Continuous ADR for Space Missions

The cryogenics group at NASA-Goddard has provided adiabatic demagnetization refrigerators (ADRs) for cooling detectors to sub-Kelvin temperatures in space. These ADRs were single-shot devices that produced cooling at 0.05 K for tens of hours before needing to be recycled. Our group also developed a four-stage laboratory ADR system which holds one stage continuously at 0.05K, or colder, while using the other stages to pump heat from the continuous stage up to a heat sink near 4K. This continuous ADR (CADR) provides a useful cooling power that is more than 10 times greater at 0.050 K than what was required by the single-shot space systems. Over the past several years, this system was updated so that it can withstand the rigors of a launch into space. We describe this development process and report its final results.

Continuous ADR↗
NASA NTRSDate not supplied

A Four-Stage Continuous ADR for Space Missions

The cryogenics group at NASA-Goddard has provided adiabatic demagnetization refrigerators (ADRs) for cooling detectors to sub-Kelvin temperatures in space. These ADRs were single-shot devices that produced cooling at 0.05 K for tens of hours before needing to be recycled. Our group also developed a four-stage laboratory ADR system which holds one stage continuously at 0.05K, or colder, while using the other stages to pump heat from the continuous stage up to a heat sink near 4K. This continuous ADR (CADR) provides a useful cooling power that is more than 10 times greater at 0.050 K than what was required by the single-shot space systems. Over the past several years, this system was updated so that it can withstand the rigors of a launch into space. We describe this development process and report its final results.

Continuous ADR↗
NASA NTRSDate not supplied

The HySICS Pointing System: Precision Pointing of CLARREO Pathfinder from the ISS

The CLARREO (Climate Absolute Radiance and Refractivity Observatory) Pathfinder (CPF) mission will measure Earth-reflected sunlight with unparalleled accuracy over existing reflected solar (RS) sensors and will also serve as an on-orbit inter-calibration reference to other orbiting sensors. In order to achieve these goals, the HySICS (HyperSpectral Imager for Climate Science) instrument will need to be pointed at a diverse set of targets including: nadir earth, co-aligned earth scans with other orbiting sensors, the Sun, and the Moon. The HySICS Pointing System (HPS) was developed to provide independent pointing at these targets from its mounting location on the ISS. This paper is focused on the HPS and describes: an overview of the CPF mission, an overview of the HPS requirements, the HPS hardware architecture, the various pointing modes that allow the HPS to point at its targets, challenges associated with performing this mission on the ISS, test results from subsystem-level HPS testing, and finally lessons learned that pertain to algorithm/software development and to the benefits of reusing pointing control hardware/architecture from the TSIS-1 mission that also has a 2-axis pointing system on the ISS from the development process.

orbit↗
NASA NTRSDate not supplied

Characterization of Fluorescence Signals in Synthetic Anorthite

In-situ resource utilization (ISRU) is a key capability to enable a long term presence on the Moon and other planetary bodies. For example, efforts have been underway to develop processes to utilize the lunar regolith to produce building materials and extract useful resources. In processes that utilize the regolith directly to produce construction materials, such as in various sintering methods, characterizing the composition of the regolith is important as the composition can affect the optimal process parame-ters. In processes that involve extracting resources such as iron, oxygen, hydrogen, etc., identifying areas with higher abundance of a particular resource will be critical since different regions of the Moon exhibit differing regolith composition. To this end, Ra-man is one technique that can rapidly characterize the mineralogy of rock samples. This technique has al-ready been deployed on Mars to detect various miner-als including olivine, carbonates, phosphates, etc. Besides characterizing the mineralogy, Raman spectra often contain unwanted fluorescence signals that can mask Raman peaks. In some cases, the fluorescence signals are narrow enough to aid in the identification of specific elements in soils. In this work, we explore fluorescence peaks in a synthetic anorthite sample, which are at the same position as Ruby fluorescence peaks attributed to chromium. These fluorescence peaks, as well as similar fluorescence peaks attributed to other elements, could have important implications for ISRU and the mining of critical resources as has been previously described.

Raman Spectroscopy↗
NASA NTRSDate not supplied

International Space Station Space Environments Performance and Anomaly Resolution

The International Space Station is the largest and most complex on-orbit platform for space science utilization in low Earth orbit. The Space Environments Team addresses natural and induced environments for the ISS Program including external contamination, ionizing radiation, neutral atmosphere and solar ultraviolet radiation, plasma effects, and acoustics. For the ISS to fulfill its mission as a long-duration science platform, space environments effects are assessed, monitored, and controlled through design or operational mitigation. Interactions of ISS hardware with the natural and induced space environments, and the assessment and mitigation of those effects play a critical role in ISS mission operations. The Space Environments Team has complete system integration responsibility in these area for U.S./International Partner/Russian hardware, visiting vehicles, ISS payloads and operation. Lessons learned and processes developed for ISS are applicable to the design, assembly, and operations of long-duration space systems.

space environments↗
NASA NTRSDate not supplied

PAX Mobility

Pax Mobility is a Wicked Wild Discovery activity under the Convergent Aeronautics Solutions (CAS) project. It is intended to cut down the end-to-end travel time and friction for people and goods (referred to as passengers) through: (1) A passenger-oriented paradigm to enable faster mobility that is accessible by all people, end to end (rather than port to port), and that is also safer, more efficient, and sustainable. (2) A total mobility paradigm that integrates modes of mobility to achieve end-to-end passenger objectives. (3) Digital transformation that establishes an agile research and development process to reduce the time to reach end-to-end mobility solutions.

Passenger-oriented total mobility↗