Search NASA⌕ Search

SEARCH · Search NASA

Results for “lessons”

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 253 records · Page 14
All sourcesNASA NTRSDOE OSTI
NASA NTRS2013

Service Oriented Robotic Architecture for Space Robotics: Design, Testing, and Lessons Learned

This paper presents the lessons learned from six years of experiments with planetary rover prototypes running the Service Oriented Robotic Architecture (SORA) developed by the Intelligent Robotics Group (IRG) at the NASA Ames Research Center. SORA relies on proven software engineering methods and technologies applied to space robotics. Based on a Service Oriented Architecture and robust middleware, SORA encompasses on-board robot control and a full suite of software tools necessary for remotely operated exploration missions. SORA has been eld tested in numerous scenarios of robotic lunar and planetary exploration. The experiments conducted by IRG with SORA exercise a large set of the constraints encountered in space applications: remote robotic assets, ight relevant science instruments, distributed operations, high network latencies and unreliable or intermittent communication links. In this paper, we present the results of these eld tests in regard to the developed architecture, and discuss its bene ts and limitations.

service oriented architecture↗
NASA NTRS2013

X-43A lessons learned

The primary discussion in this paper is about the lessons learned in the loss of the first Hyper-X vehicle and how those problems were overcome.

lessons learned↗
NASA NTRS2015

Lessons Learned in Thermal Coatings from the DSCOVR Mission

Finding solutions to thermal coating issues on the Deep Space Climate Observatory (DSCOVR) mission was a very challenging and unique endeavor. As a passive thermal control system, coatings provide the desired thermal, optical, and electrical charging properties, while surviving a harsh space environment. DSCOVR mission hardware was repurposed from the late 1990s satellite known as Triana. As a satellite that was shelved for over a decade, the coating surfaces consequently degraded with age, and became fairly outdated. Although the mission successfully launched in February 2015, there were unfamiliar observations and unanticipated issues with the coating surfaces during the revival phases of the project. For example, the thermal coatings on DSCOVR experienced particulate contamination and resistivity requirement problems, among other issues. While finding solutions to these issues, valuable lessons were learned in thermal coatings that may provide great insight to future spaceflight missions in similar situations.

thermal coatings↗
NASA NTRS2016

How Do Lessons Learned on the International Space Station (ISS) Help Plan Life Support for Mars?

How can our experience in developing and operating the International Space Station (ISS) guide the design, development, and operation of life support for the journey to Mars? The Mars deep space Environmental Control and Life Support System (ECLSS) must incorporate the knowledge and experience gained in developing ECLSS for low Earth orbit, but it must also meet the challenging new requirements of operation in deep space where there is no possibility of emergency resupply or quick crew return. The understanding gained by developing ISS flight hardware and successfully supporting a crew in orbit for many years is uniquely instructive. Different requirements for Mars life support suggest that different decisions may be made in design, testing, and operations planning, but the lessons learned developing the ECLSS for ISS provide valuable guidance.

Lessons learned↗
NASA NTRSDate not supplied

Best Practices, Lessons Learned, and Examples on the Application of Damage Tolerance in Space Structures

Damage tolerance is an important consideration in space structures applications. The intent of damage tolerance is to demonstrate that the structure is robust to the presence of flaws over the service life of the space vehicle. Damage tolerance requirements in documents such as those in NASA, AIAA, and ISO can be challenging to implement. The intent of this paper is three-fold: (1) Provide best practices in the application of damage tolerance requirements for space applications, (2) Provide lessons learned for each of class of hardware, (3) Provide examples of challenging situations encountered in the application of damage tolerance. Examples cover additive manufacturing, composite overwrapped pressure vessels, pressurized structures, liquid rocket engines, thermal protection systems, and other classes of hardware. The philosophy and limitations of leak before burst and proof test logic are also discussed. Finally, a discussion on elastic-plastic fracture mechanics with comparisons to test data will be presented.

Best Practices↗
NASA NTRSDate not supplied

NASA’s Student Airborne Science Activation for Minority Serving Institutions: Inaugural Program, Educational Outcomes, and Lessons Learned

The NASA Student Airborne Science Activation (SaSa) for Minority Serving Institutions (MSIs) held its inaugural summer research program for early career undergraduates interested in the Geosciences. SaSa is a NASA Science Activation funded 8-week summer internship program. Twenty-four first- and second-year undergraduates from MSIs across the U.S. participated in the summer program - June 6 to July 29, 2022. Students had the opportunity to gain hands-on research experience in all components of an airborne science campaign including flying on-board a NASA research aircraft to collect atmospheric measurements. Students conducted independent research projects related to the atmosphere, ocean, and geosciences that feed into NASA’s broader Earth Science Division’s and Decadal Survey goals using air quality, meteorological, and oceanic measurements from surface, airborne, and satellite-based observations. The program split its time between partner institution, University of Maryland Baltimore County and NASA’s Wallops Flight Facility in Wallops Island, Virginia. Students also made site visits at partner institutions, including: Hampton University, University of Maryland Eastern Shore, Morgan State University, Howard University, and Coppin State University and attended lectures from visiting faculty and NASA Subject Matter Experts. Students were guided on their research projects by near-peer graduate mentors, SaSa program leadership, co-Is at partner institutions, and NASA scientists to address two major research themes: 1) how human-caused air pollution has human and environmental implications, and 2) how large-scale meteorological factors influence local weather conditions. Students sorted into research groups, based on sub-discipline areas in the Geosciences, including: “Clouds, Aerosols and Radiation”, “Meteorology and Planetary Boundary Layer”, “Air Quality: Particle Pollution and Trace Gases”, and “Air-Water-Land Interface”. Their research was presented as 3-minute lightning talks and in-person poster presentations at a close-out event at NASA Goddard Space Flight Center in Greenbelt, Maryland. The students’ inter- and trans-disciplinary research experiences centered in the use of multiple ground, airborne, and satellite remote sensing NASA Earth Science Division assets. Providing a unique experience aligned to recognize the societal benefits that NASA contributes in the areas of resource management, air quality monitoring and policy decisions, energy and weather predictions, and research on the Earth’s climate. The SaSa program aims to increase the number of students from MSIs that identify as underrepresented or underserved individuals in the Geosciences discipline, Earth System Science graduate programs, and the NASA workforce. A summary of the summer research program, educational, scientific, and programmatic outcomes, as well as lessons learned will be presented.

NASA↗
NASA NTRSDate not supplied

Lessons Learned With Risk Management: A Systems Engineer's Perspective

Risk management is a communications device that, when executed as an essential task, enables systems engineering to effectively balance risk across the project. Developing and baselining risks is an essential continuous task to ensure top project concerns both from bottom up and top down are being mitigated. Risk management provides the opportunity to avoid the consequence of the risk when mitigation steps start early enough. Just discussing risk with all the project flight elements during development, even if no risks are open, provides an excellent communication opportunity between systems engineering and those elements, ensuring concerns and worries have a platform for discussion. A well-managed risk identification process will identify concerns that are serious but not being clearly communicated, and it will enable mitigation of those potential problems before they cause a failure. Effective risk management requires considerable time and effort, but that effort will save time and money across the development. Risk management must be frequent enough to be useful and in depth enough to bring out emerging issues. It also requires a trusting relationship between the lead systems engineer and element and/or subsystem leads. The discussions need to be with the right number of individuals (typically a handful) and the right duration in time (typically an hour a month). Outside of these risk working groups, there is a formal management process to input, status, and disposition risks, and a monthly Risk Management Board meeting where key project stakeholders are informed. This paper provides good guidance on effective risk management from a systems engineering perspective and provides project lessons learned from the NASA spaceflight missions NICER, Landsat 9, LRO, and OSIRIS-REx to demonstrate the effectiveness of risk management.

Lessons Learned↗
NASA NTRSDate not supplied

Lessons Learned With Risk Management: A Systems Engineer’s Perspective

Risk management is a communications device that, when executed as an essential task, enables systems engineering to effectively balance risk across the project. Developing and baselining risks is an essential continuous task to ensure top project concerns both from bottom up and top down are being mitigated. Risk management provides the opportunity to avoid the consequence of the risk when mitigation steps start early enough. Just discussing risk with all the project flight elements during development, even if no risks are open, provides an excellent communication opportunity between systems engineering and those elements, ensuring concerns and worries have a platform for discussion. A well-managed risk identification process will identify concerns that are serious but not being clearly communicated, and it will enable mitigation of those potential problems before they cause a failure. Effective risk management requires considerable time and effort, but that effort will save time and money across the development. Risk management must be frequent enough to be useful and in depth enough to bring out emerging issues. It also requires a trusting relationship between the lead systems engineer and element and/or subsystem leads. The discussions need to be with the right number of individuals (typically a handful) and the right duration in time (typically an hour a month). Outside of these risk working groups, there is a formal management process to input, status, and disposition risks, and a monthly Risk Management Board meeting where key project stakeholders are informed. This paper provides good guidance on effective risk management from a systems engineering perspective and provides project lessons learned from the NASA spaceflight missions NICER, Landsat 9, LRO, and OSIRIS-REx to demonstrate the effectiveness of risk management.

Lessons Learned↗
NASA NTRSDate not supplied

Ideas for Applying Artificial Intelligence to NASA Lessons Learned

Artificial intelligence is it tool that has existed for many years. Recent developments in generative AI has rapidly expanded the applications for this tool across many domains such as writing, analyzing, summarizing, creating videos, creating graphics and others. Charts in this presentation will prompt attendees to discuss the pros and cons, and potential validation methodology for imbedding artificial intelligence tools in the NASA lessons learned knowledge sharing environment.

Knowledge Management↗
NASA NTRS2024

Lessons Learned from Particulate Characterization Laboratory Anomalies

The White Sands Test Facility chemistry laboratory provides quality control for cleanroom operations including cleanliness verification of aerospace hardware by particulate counts and non-volatile residue determinations, particulate counts for liquid hypergolic propellants, gaseous helium and nitrogen propellant pressurizing agents used for ground support equipment and flight test article valve actuation, gaseous oxygen primarily used for component testing, and deionized water for refurbished propellant hardware flushing. Cleanliness verification includes particulate counts and non-volatile residue determinations to industry standard, NASA, and program specifications and levels. Particulate counts are typically to customer-specified specifications and levels including JPR 5322.1H (2016) Levels 50 and 100, Orion (MPCV 70156. Revision H (2018)) Level 100, RPTSTD-8070-0001 Revision 3 (2022), and IEST-STD-CC1246E (2013) Levels 50 and 100. The laboratory issues high pressure filter holders containing membrane filters to test operations personnel, who collect samples by flowing the required volumes of fluid through the filter holder, and the filter holder is returned to the lab for counting. A passing particulate count is required before testing may proceed. Rapid data reduction and issuing of reports indicating a pass or fail of the particulate specification are required. Corrective action and resampling invariably occurs if a sample fails. Consequently, the laboratory must maintain the highest degree of reliability to facilitate quality data used to decide if testing may proceed. Experience and continual improvements have enabled reliability. However, anomalies attributed to lab processes and hardware including filter holders, membranes, and Petri dishes have been encountered. This paper presents a summary of problems, solutions, successes, and lessons learned from particle counting experience for over 35 years.

Lessons Learned↗
DOE OSTI2026

Lessons Learned from the Energy to Communities (E2C) Peer-Learning Cohort on Engaging with Electric Utilities for Successful Local Partnerships

NLR designed and led a six-month peer-learning cohort from July through December 2025 on “Engaging With Electric Utilities for Successful Local Partnerships” as part of the U.S. Department of Energy’s Energy to Communities (E2C) program. Representatives from 15 local and regional governments from across the United States participated in monthly workshops covering best practices for engaging with their utilities to advance their own energy goals. This document shares key takeaways, lessons learned, and resources from the cohort that may be useful to local governments, regional governments, or Tribes.

29 ENERGY PLANNING, POLICY, AND ECONOMY↗
DOE OSTI2025

Lessons Learned and Scalability Achieved When Porting Uintah to DOE Exascale Systems

A key challenge faced when preparing codes for Department of Energy (DOE) exascale systems was designing scalable applications for systems featuring hardware and software not yet available at leadership-class scale. With such systems now available, it is important to evaluate scalability of the resulting software solutions on these target systems. One such code designed with the exascale DOE Aurora and DOE Frontier systems in mind is the Uintah Computational Framework, an open-source asynchronous many-task (AMT) runtime system. To prepare for exascale, Uintah adopted a portable MPI+X hybrid parallelism approach using the Kokkos performance portability library (i.e., MPI+Kokkos). This paper complements recent work with additional details and an evaluation of the resulting approach on Aurora and Frontier. Results are shown for a challenging benchmark demonstrating interoperability of 3 portable codes essential to Uintah-related combustion research. These results demonstrate single-source portability across Aurora and Frontier with scaling characteristics shown to 3,072 Aurora nodes and 9,216 Frontier nodes. In addition to showing results run to new scales on new systems, this paper also discusses lessons learned through efforts preparing Uintah for exascale systems.

Holmen, John [ORNL] (ORCID:0000000259342641)↗