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,243 records · Page 69
All sourcesNASA NTRSDOE OSTI
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↗
NASA NTRSDate not supplied

HLS Mission Planning Using the STEDe Applications Suite of Timeline Evaluation and Development environments (STEDe)

STEDe applications work together to emulate the official HLS mission timeline and provide insight into potential mission constraints. They ingest HLS Program inputs such as ground rules and assumptions, requirements, and activity durations, informed by experts, to ensure that crew activities and critical vehicle events can transpire without conflicts and mission goals can be achieved. The STEDe applications provide timely assessments of what-if changes to the timeline with respect to different parameters and improve on the trial-and-error mission timeline development process.

Levi Gosdin↗
NASA NTRSDate not supplied

The Webb Space Telescope - An Engineering Marvel Story

This presentation will provide an overview of the James Webb Space Telescope (JWST) and its engineering development process. JWST has succeeded the Hubble Space Telescope in our quest for the first galaxies formed out of the darkness of the early universe. Since its launch in December 2021, JWST has helped us understand how these galaxies evolved over billions of years, how stars and planetary systems form, what exoplanets look like and if they can harbor life. JWST uses a ~6.5-m-diameter primary mirror to collect infrared light, which is sent to four scientific instruments. It operates at the second Sun-Earth Lagrange point and has a five-layer sunshield to be able to operate at cryogenic temperatures. JWST is an international effort of NASA and the European and Canadian Space Agencies.

James Webb Space Telescope↗
NASA NTRS2024

Independent Scientific Review of Biological Assumptions and Planned Ultraviolet Treatment for Mars Sample Return Backward Planetary Protection

The Backward Planetary Protection Study Team (“the Study Team”), assembled by the Office of the Chief Scientist (OCS) at the request of the Office of Planetary Protection (OPP), has conducted numerous detailed discussions on the potential use of an active ultraviolet (UV) approach for minimizing or eliminating biological contamination of the exterior of the planned Orbiting Sample container (OS) of the Mars Sample Return (MSR) mission. This review of the backward planetary protection (BPP) considerations for the MSR mission focused on two key parameters that are opportunities for further process development to support implementation of planetary protection practices in meeting mission requirements. These parameters include: 1) Sub-cellular biological assumptions – should Mars missions consider self-replicating organisms only or do they need to consider non-self-replicating entities without a cellular organization such as viruses, prions, etc. and macromolecules capable of genetic information transfer, as well? 2) UV biocidal impact – what is the UV fluence in the Mars atmosphere and its associated potential biocidal credit? The assembled subject matter experts (SMEs) in the Study Team are listed in Appendix A, with a brief description of each member’s relevant expertise.

Mamta Patel Nagaraja↗
NASA NTRSDate not supplied

The Collection, Usage, and Preliminary Examination of the Apollo Sample Suite: Lessons for Artemis

Apollo Sample Collection and Usage: From 1969 to 1972 there were six Apollo missions to the surface of the Moon during which the astronauts collected 382 kg of rock and regolith (~2200 samples). The samples collected fall into these general categories: rocks (~66% by mass), rake samples (~4%), bulk regolith (~24%), and specialty regolith (deep drill cores, drive tubes, sealed bulk regolith) samples (~6%). In each category there are a variety of different subtypes available for study, e.g., among the bulk regolith samples there are also skim, trench, and (partially) shaded regolith samples each sampling unique types or depths of regolith. This variety of subsamples has enabled a multitude of different studies over the past 55 years (>3400 individual requests). We are still averaging ~50 unique requests and have allocated >500 individual Apollo samples annually for the past 10 years (2020 excepted). Looking at the 4,675 non-ANGSA (Apollo Next Generation Sample Analysis) samples allocated over the past 10 years, the proportions of allocated samples do not precisely align with the abundance (by mass) of those samples withing the collection: Rock (69.4 %); Rake (10.8 %); Bulk Regolith (15.5 %); Drive Tube (3.3 %); Core/Specialty (1.0 %). Apollo Preliminary Examination (PE): The PE process differs significantly for the various sample types enumerated above; we focus on regolith and rock samples here. During the Apollo mission era, the PE process evolved over the course of the missions; below is what was done for the Apollo 17 mission. For regolith samples, the PE process was: (1) documented bags containing regolith are opened, photographed, and described; (2) large rocks are removed and treated separately; (3) 25% to 33% of the bulk soil is scooped out, weighed, and stored in reserve; (4) the remaining sample is sieved to produce the size fractions <1, 1- 2, 2-4, and 4-10 mm, all of which are weighed. For rock samples, the process is: (1) removing rocks from the container(s) it came back from the Moon in; (2) rematching any materials that spalled off the rock to their original location; (3) numbering, weighing, and basic photographic documentation; (4) dusting with a gentle N2 gas jet; (5) Orthogonal photography; (6) detailed description of the textures and features of the rock; (7) rock modelling and measurement; (8) stereophotography; (9) determination of the orientation of the rock on the lunar surface. Drive tubes and deep drill cores were not characterized during PE beyond an initial weight and a sketch of the interior tube materials derived from 2D medical X-ray images. Catalogs: The ongoing utility of the Apollo samples is enabled by the robust cataloguing process for the samples [3-5], which allows the scientific community to accurately request samples uniquely suited to their proposed studies. A common misconception, however, is the amount of detail that goes into the initial catalog (e.g., [6]) for a collection from the preliminary examination (PE) period, versus what goes into the catalogs that come later in the life cycle of the samples from that mission (e.g., [7]). The only required data for a PE catalog is a weight, a basic photograph, and a description of the nature of the sample. Artemis PE: Over the past few years, the ongoing ANGSA project studied previously unopened Apollo 17 double drive tube samples 73001/2 [1], and a PE of the drive tubes was done. The PE took the existing core dissection process (developed during PE of Apollo cores in the 1970s, 1980s), and modernized it [7]. The main lesson from the ANGSA PE relative to future missions was that the physical work done during PE of lunar samples has not changed much over the past 5 decades. The use of “modern” technology during PE (e.g., XCT; multispectral analyses) resulted in an enhanced initial understanding of the 73001 and 73002 drive tubes, but greatly increased the time required. The lessons learned from recent astromaterial PEs (e.g., ANGSA and OREx) are important to consider when planning for Artemis, but the unique nature of the Artemis Campaign means many lessons learned from these mission will not be applicable. Given the time constraints (6 months) and likely number of samples that will be returned by Artemis (>200), the Artemis PE catalog will necessarily look much more like [4] than [6].

J Gross↗
NASA NTRSDate not supplied

X-57 Traction Power and Command Systems Development

This paper describes the final, as-built design of the X‑57 Maxwell aircraft power and command system architecture that implements the electrified propulsion capability. The development of the traction power, command, and avionics power subsystems proceeded as planned at the initial project critical design review, but improvements to the design were identified following the development of detailed operations concepts and integrated subsystem and system testing. The redundant architecture with A‑side and B‑side buses provided a robust framework for a developmental system that would turn out to have a lower technology readiness than had been assumed upon project formulation. As the project team identified reliability or performance gaps in the electrified propulsion powertrain components and their interactions with the other vehicle systems, the traction power, command, and avionics architectures were modified to accommodate the modified systems. Following the publication of the planned design approach at the critical design review milestone [1], the project team developed the flight hardware and software, integrated the systems, and adjusted the design and qualification activities to address gaps in the components, system architecture, and requirements as the gaps were realized. In addition to inherent challenges in development of these subsystems, the integration of this new technology with adjacent critical systems in an aircraft configuration posed additional challenges that drove design considerations across the subsystem development and the other vehicle systems. Integration complications included electromagnetic compatibility, thermal performance, and tolerance of single-point failures internal and external to the powerplant. Development of a qualification program was required for the new motors, inverters, and batteries, and hardware performance during component qualification fed back into the development process and led lessons learned and redesign of key elements.

distributed propulsion↗
NASA NTRSDate not supplied

Mirror Surface Contamination Specification Derived from Coronagraphy Scatter Error Budget Allocation

Near-Angle Scatter (NAS) of the host star’s light may limit the ability of a potential Habitable Worlds Observatory (HWO) to detect and characterize an Earth-like planet around a Sun-like star via coronagraphy. NAS from each optical surface before the coronagraph’s focal plane mask produces an E-field across the dark hole that is coherent. These E-fields sum and could be as large or larger than the coronagraph mask leakage E-field. This paper assumes an error budget allocation for scatter of 20 ppt. NAS E-fields contribute to the dark hole noise floor via both shot noise and heterodyne amplification of the wavefront instability. While previous papers have developed specifications for scatter from surface scatter, this paper develops specifications for scatter from surface contamination and micrometeoroid impacts. The development process utilizes an expression that predicts scatter throughput into the dark hole based on surface BRDF. Analysis does not include scatter from coating columnar structure, edges, contamination, micrometeoroid impacts, or polarization.

near angle scatter↗
NASA NTRSDate not supplied

Technology Transfer Plan: LuNaMaps Project

The main contribution of this project is the combined knowledge of terrain relative navigation experts and lunar scientists who are familiar with both the lunar orbital imagery and the instruments that collected the data as well as how a TRN system utilizes map data. This knowledge comes in the form of published technical papers, benchmark map data sets, and software tools that can help others automate the process of creating the necessary maps for their own landing sites in the future. This document represents the project's plans to share all the lessons learned, processes developed, and applicable software tools with the public.

optical navigation↗
NASA NTRSDate not supplied

Discovering Digital Engineering Needs Through Human-Centered Approaches

Digital engineering has the power to transform organizations in profound ways, but digitizing legacy workflows and infusing new technologies into existing practices may not yield the intended results or address the underlying problems or bottlenecks. This paper describes the human-centered approaches used to understand stakeholder challenges and identify digital engineering needs during the design-build-test portion of the systems development lifecycle. Through a series of interactive stakeholder workshops and need-finding activities, key stakeholder needs were identified to help guide the integration of digital engineering technologies. The overarching need was for downstream system development steps to be considered further upstream in the project lifecycle in a manner that allows for proactive and interactive co-constructive idea exploration, problem resolution, and requirements considerations in a collective engagement with engineers and technicians from multiple disciplines to increase efficiency and reduce risks while offering opportunities to improve the final engineered system. Supporting this need was a wide-ranging desire from stakeholders for digital and non-digital support structures for efficient rapid iteration during system development. This work yielded several improvements for system development processes and for digital engineering infusion.

Human-centered Design↗
NASA NTRSDate not supplied

Discovering Digital Engineering Needs Through Human-Centered Approaches

Digital engineering has the power to transform organizations in profound ways, but digitizing legacy workflows and infusing new technologies into existing practices may not yield the intended results or address the underlying problems or bottlenecks. This paper describes the human-centered approaches used to understand stakeholder challenges and identify digital engineering needs during the design-build-test portion of the systems development lifecycle. Through a series of interactive stakeholder workshops and need-finding activities, key stakeholder needs were identified to help guide the integration of digital engineering technologies. The overarching need was for downstream system development steps to be considered further upstream in the project lifecycle in a manner that allows for proactive and interactive co-constructive idea exploration, problem resolution, and requirements considerations in a collective engagement with engineers and technicians from multiple disciplines to increase efficiency and reduce risks while offering opportunities to improve the final engineered system. Supporting this need was a wide-ranging desire from stakeholders for digital and non-digital support structures for efficient rapid iteration during system development. This work yielded several improvements for system development processes and for digital engineering infusion.

Design Science↗