Search NASA⌕ Search

SEARCH · Search NASA

Results for “lessons learned process”

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 109 records · Page 6
All sourcesNASA NTRSDOE OSTI
NASA NTRS2004

Mechanical Design of a Performance Test Rig for the Turbine Air-Flow Task (TAFT)

To support development of the Boeing-Rocketdyne RS84 rocket engine, a full-flow, reaction turbine geometry was integrated into the NASA-MSFC turbine air-flow test facility. A mechanical design was generated which minimized the amount of new hardware while incorporating all test and instrumentation requirements. This paper provides details of the mechanical design for this Turbine Air-Flow Task (TAFT) test rig. The mechanical design process utilized for this task included the following basic stages: Conceptual Design. Preliminary Design. Detailed Design. Baseline of Design (including Configuration Control and Drawing Revision). Fabrication. Assembly. During the design process, many lessons were learned that should benefit future test rig design projects. Of primary importance are well-defined requirements early in the design process, a thorough detailed design package, and effective communication with both the customer and the fabrication contractors.

Forbes, John C.↗
NASA NTRS2016

Design and Development of NEA Scout Solar Sail Deployer Mechanism

The 6U (approximately 10cm x 20cm x 30cm) cubesat Near Earth Asteroid (NEA) Scout1, projected for launch in September 2018 aboard the maiden voyage of the Space Launch System (SLS), will utilize a solar sail as its main method of propulsion throughout its approximately 3 year mission to a Near Earth Asteroid (NEA). Due to the extreme volume constraints levied onto the mission, an acutely compact solar sail deployment mechanism has been designed to meet the volume and mass constraints, as well as provide enough propulsive solar sail area and quality in order to achieve mission success. The design of such a compact system required the development of approximately half a dozen prototypes in order to identify unforeseen problems, advance solutions, and build confidence in the final design product. This paper focuses on the obstacles of developing a solar sail deployment mechanism for such an application and the lessons learned from a thorough development process. The lessons presented will have significant applications beyond the NEA Scout mission, such as the development of other deployable boom mechanisms and uses for gossamer-thin films in space.

Sobey, Alexander R.↗
NASA NTRS2016

Design and Development of NEA Scout Solar Sail Deployer Mechanism

The 6U (approx.10 cm x 20 cm x 30 cm) cubesat Near Earth Asteroid (NEA) Scout1, projected for launch in September 2018 aboard the maiden voyage of the Space Launch System, will utilize a solar sail as its main method of propulsion throughout its approx.3-year mission to a Near Earth Asteroid. Due to the extreme volume constraints levied onto the mission, an acutely compact solar sail deployment mechanism has been designed to meet the volume and mass constraints, as well as provide enough propulsive solar sail area and quality in order to achieve mission success. The design of such a compact system required the development of approximately half a dozen prototypes in order to identify unforeseen problems, advance solutions, and build confidence in the final design product. This paper focuses on the obstacles of developing a solar sail deployment mechanism for such an application and the lessons learned from a thorough development process. The lessons presented will have significant applications beyond the NEA Scout mission, such as the development of other deployable boom mechanisms and uses for gossamer-thin films in space.

Sobey, Alexander R.↗
NASA NTRSDate not supplied

Preliminary Examination Process of Apollo Core 73002 - Insights and Lessons Learned From ANGSA for Future Sample Return Missions

Apollo Sample 73002 is part of a 2-foot long “drive tube” (73001/73002) of regolith that was collected from a landslide deposit near Lara Crater at the Apollo 17 site, Station 3. The double drive tube is believed to have penetrated a lunar landslide deposit that was transported from the slope of the South Massif into the TLV [1]. As part of the ANGSA (Apollo Next Generation Sample Analyses) initiative, preparing preliminary examination (PE) catalog of 73002 is a crucial first step for the early identification of material types such as rock fragments, and potential stratigraphy within the core. PE of Apollo core 73002 is distinct from science activities with the main goal to produces a sample catalog with a level of detail about sample characterization that is sufficient for the ANGSA PIs (and later on the lunar sample community) to select and request the samples to conduct their individual, scientific studies. Ultimately, the PE catalog of 73002 will help to establish a better understanding of the stratigraphy of the land slide deposit; the processes of the landslide including the trigger(s) and possibly number of landslide events, as well as the role of volatiles [1] and will aid in the careful preservation of the material for future studies [2].

Apollo↗
NASA NTRS2022

Flight Software Dictionary Development for the Mars2020 Rover

The Mars2020 project, developed and operated by the Jet Propulsion Laboratory (JPL), successfully landed the Perseverance rover and its flying companion Ingenuity on the surface of Mars on February 18th 2021. Perseverance combines heritage and cutting-edge flight software and hardware to accomplish crucial mission requirements related to Martian surface sampling. The design, development, and operation of NASA’s large strategic science missions require the ability to communicate spacecraft capabilities to hundreds of engineers across multiple disciplines. The interaction between flight and ground software development, Verification and Validation (V&V), Assembly, Test, and Launch Operations (ATLO), and management each demand quick understanding of unique slices of information for each discipline. This information includes the current capabilities of the flight system as well as future capabilities and their status as they are developed and tested. Despite the fundamental and critical nature of this information, the flight software dictionaries used to track it are a stumbling block for many projects. These dictionaries provide the cornerstone for the interpretation of data sent from the spacecraft, allowing for quick comprehension by engineers on the ground. During both spacecraft development and operations, flight software dictionary management includes significant challenges due to the large number of interfacing systems and the subtle yet distinct needs of each.The engineering of flight software dictionaries for Mars2020 had numerous challenges, most-notably: parallel dictionary development to support simultaneous separate flight software build campaigns for each mission phase (cruise and surface), managing requests for operations-enabling information without perturbing the heritage interface with the rover, and the introduction of new tools by the dictionary stakeholders that forced the dictionary team to innovate and redesign the heritage tool chain. These challenges generated guiding principles for the dictionary development effort: emphasize coding best practices and unit testing in the dictionary code development tool chain, use institutionally provided COTS (commercial-off-the-shelf) tools whenever possible, and maintain the heritage flight-ground interface all while advancing operations-enabling information via a loosely coupled interface.Throughout development and operations, the Mars2020 dictionary toolchain included IBM DOORS Next Generation, GitHub, Microsoft Excel, Docker, Jenkins, and a significant custom-built Python codebase. Significant interfaces included JPL’s command and control software, heritage flight software team tools and processes, and the many cloud-based ground tools developed for the mission.This paper will discuss the requirements for the Mars2020 dictionary development, the development team’s response to those requirements, lessons learned throughout the process, steps taken towards automated deliveries and continuous integration of stakeholder inputs, potential toolchain improvements for Mars2020, and key takeaways that could be applied to future missions.

Pyrzak, Guy↗
NASA NTRS2005

REIMR: A Process for Utilizing Propulsion-Oriented 'Lessons-Learned' to Mitigate Development Risk

This paper is a summary overview of a study conducted a t the NASA Marshall Space Flight Center (MSFC) during the initial phases of the Space Launch Initiative (SLI) program to evaluate a large number of technical problems associated with the design, development, test, evaluation and operation of several major liquid propellant rocket engine systems (i.e., SSME, Fastrac, J-2, F-1). The results of this study was the identification of the "Fundamental Root Causes" that enabled the technical problems to manifest, and practices that can be implemented to prevent them from recurring in future engine development efforts. This paper will discus the Fundamental Root Causes, cite some examples of how the technical problems arose from them, and provide a discussion of how they can be mitigated or avoided.

Ballard, Richard O.↗
NASA NTRS2010

Anatomy of a Security Operations Center

Many agencies and corporations are either contemplating or in the process of building a cyber Security Operations Center (SOC). Those Agencies that have established SOCs are most likely working on major revisions or enhancements to existing capabilities. As principle developers of the NASA SOC; this Presenters' goals are to provide the GFIRST community with examples of some of the key building blocks of an Agency scale cyber Security Operations Center. This presentation viII include the inputs and outputs, the facilities or shell, as well as the internal components and the processes necessary to maintain the SOC's subsistence - in other words, the anatomy of a SOC. Details to be presented include the SOC architecture and its key components: Tier 1 Call Center, data entry, and incident triage; Tier 2 monitoring, incident handling and tracking; Tier 3 computer forensics, malware analysis, and reverse engineering; Incident Management System; Threat Management System; SOC Portal; Log Aggregation and Security Incident Management (SIM) systems; flow monitoring; IDS; etc. Specific processes and methodologies discussed include Incident States and associated Work Elements; the Incident Management Workflow Process; Cyber Threat Risk Assessment methodology; and Incident Taxonomy. The Evolution of the Cyber Security Operations Center viII be discussed; starting from reactive, to proactive, and finally to proactive. Finally, the resources necessary to establish an Agency scale SOC as well as the lessons learned in the process of standing up a SOC viII be presented.

Wang, John↗
NASA NTRS2006

Human Factors Lessons Learned on the International Space Station

Experience on International Space Station (ISS) provides many important lessons for future space flight. NASA human factors engineers have been systematically collecting lessons learned from crew debriefs, as well as working with ground support teams to continuously improve crew operations. This paper describes the methods for collecting data from debriefs, lessons learned through that process, and an example of a technology development task funded through the Space Human Factors Engineering (SHFE) program element in response to an identified operational need. Each ISS increment crew spends many hours after the flight answering questions from the various subsystem leads. The Flight Crew Integration subsystem lead asks questions specific to human factors and habitability issues. In addition, crew comments on many other subsystems provide insight into interface designs, operability and maintainability. The debrief comments are unique to each crew, and must be categorized to provide operational lessons learned. Personal identifiers are removed and comments aggregated to separate consistent issues from personal preferences. Examples will be given, and the procedure for incorporating the lessons into requirements and guidelines for the next human space vehicle will be described. In flight, very few astronauts are medical doctors. Written medical procedures during flight need to be easy to follow and quick to understand. The problem was analyzed as part of a SHFE task. Organization was analyzed and reorganizations were created and tested. Results will be reported. The ISS is a very important analog for planning future long-term missions. Collection of data from debriefs, studying the lessons learned and focusing on requirements for future missions are examples of the accomplishments through the SHFE program.

Woolford, Barbara↗
NASA NTRS2011

Shaping NASA's Kennedy Space Center Safety for the Future

With the completion of the Space Shuttle Program, the Kennedy Space Center (KSC) safety function will be required to evolve beyond the single launch vehicle launch site focus that has held prominence for almost fifty years. This paper will discuss how that evolution is taking place. Specifically, we will discuss the future of safety as it relates to a site that will have multiple, very disparate, functions. These functions will include new business; KSC facilities not under the control of NASA; traditional payload and launch vehicle processing; and, operations conducted by NASA personnel, NASA contractors or a combination of both. A key element in this process is the adaptation of the current KSC set of safety requirements into a multi-faceted set that can address each of the functions above, while maintaining our world class safety environment. One of the biggest challenges that will be addressed is how to protect our personnel and property without dictating how other Non-NASA organizations protect their own employees and property. The past history of KSC Safety will be described and how the lessons learned from previous programs will be applied to the future. The lessons learned from this process will also be discussed as information for other locations that may undergo such a transformation.

Kirkpatrick, Paul↗
NASA NTRSDate not supplied

Introduction of an Agile Systems Engineering Process to the NASA Armstrong Flight Research Center

This paper will provide background on the National Aeronautics and Space Administration (NASA) Aeronautics Research Mission Directorate (ARMD) ARMD Test Data Portal (ATDP) effort along with the rationale that motivated the ATDP team to consider implementing an agile systems engineering (SE) process. The primary motivation for using this new SE process was based on the desire to mitigate a major risk to project success. Since the agile SE process had never been used before at the NASA Armstrong Flight Research Center (AFRC), utilizing this new SE process required a trailblazing effort to introduce it to NASA AFRC leadership. As a result, the ATDP team chose to adhere to the agile SE process in addition to the trusted classical waterfall SE process on ATDP. Through successful execution of this hybrid SE process during Phase I, along with demonstrating the value and rigor of the agile SE process, NASA AFRC leadership ultimately permitted the ATDP project to solely use the agile SE process for developments beyond Phase I. While it is the opinion of the authors that the classical SE process is more effective for most projects at NASA AFRC, some projects may deem that the agile SE process is more advantageous. Although this paper is focused on introducing the agile SE process to NASA AFRC, lessons learned will be valuable to other organizations as well. Details of how the ATDP team implemented the agile SE process during Phase I will be summarized, along with how the team met all required classical SE milestones. Lessons learned throughout Phase I of this effort will also be highlighted.

Daniel S. Jones↗
NASA NTRS2012

Model Based Systems Engineering on the Europa Mission Concept Study

At the start of 2011, the proposed Jupiter Europa Orbiter (JEO) mission was staffing up in expectation of becoming an official project later in the year for a launch in 2020. A unique aspect of the pre-project work was a strong emphasis and investment on the foundations of Model-Based Systems Engineering (MBSE). As so often happens in this business, plans changed: NASA's budget and science priorities were released and together fundamentally changed the course of JEO. As a result, it returned to being a study task whose objective is to propose more affordable ways to accomplish the science. As part of this transition, the question arose as to whether it could continue to afford the investment in MBSE. In short, the MBSE infusion has survived and is providing clear value to the study effort. By leveraging the existing infrastructure and a modest additional investment, striking advances in the capture and analysis of designs using MBSE were achieved. In the process, the need to remain relevant in the new environment has brought about a wave of innovation and progress. The effort has reaffirmed the importance of architecting. It has successfully harnessed the synergistic relationship of architecting to system modeling. We have found that MBSE can provide greater agility than traditional methods. We have also found that a diverse 'ecosystem' of modeling tools and languages (SysML, Mathematica, even Excel) is not only viable, but an important enabler of agility and adaptability. This paper will describe the successful application of MBSE in the dynamic environment of early mission formulation, the significant results produced and lessons learned in the process.

Bayer, Todd J.↗
NASA NTRS2011

Gain Scheduling for the Orion Launch Abort Vehicle Controller

One of NASAs challenges for the Orion vehicle is the control system design for the Launch Abort Vehicle (LAV), which is required to abort safely at any time during the atmospheric ascent portion of ight. The focus of this paper is the gain design and scheduling process for a controller that covers the wide range of vehicle configurations and flight conditions experienced during the full envelope of potential abort trajectories from the pad to exo-atmospheric flight. Several factors are taken into account in the automation process for tuning the gains including the abort effectors, the environmental changes and the autopilot modes. Gain scheduling is accomplished using a linear quadratic regulator (LQR) approach for the decoupled, simplified linear model throughout the operational envelope in time, altitude and Mach number. The derived gains are then implemented into the full linear model for controller requirement validation. Finally, the gains are tested and evaluated in a non-linear simulation using the vehicles ight software to ensure performance requirements are met. An overview of the LAV controller design and a description of the linear plant models are presented. Examples of the most significant challenges with the automation of the gain tuning process are then discussed. In conclusion, the paper will consider the lessons learned through out the process, especially in regards to automation, and examine the usefulness of the gain scheduling tool and process developed as applicable to non-Orion vehicles.

McNamara, Sara J.↗
NASA NTRS2013

Moving Technologies from the Test Tube to Commercial Products

Successful technologies include objects, processes, and procedures that share a common theme; they are being used to generate new products that create economic growth. The foundation is the invention, but the invention is a small part of the overall effort. The pathway to success is understanding the competition, proper planning, record keeping, integrating a supply chain, understanding actual costs, intellectual property (IP), benchmarking, and timing. Additionally, there are obstacles that include financing, what to make, buy, and sell, and the division of labor i.e. recognizing who is best at what task. Over the past two decades, NASA Langley Research Center (LaRC) has developed several commercially available technologies. The approach to commercialization of three of these inventions; Langley Research Center-Soluble Imide (LaRC-SI, Imitec Inc.), the Thin Layer Unimorph Driver (THUNDER, FACE International), and the Macrofiber Composite (MFC, Smart Material Corp.) will be described, as well as some of the lessons learned from the process. What makes these three inventions interesting is that one was created in the laboratory; another was built using the previous invention as part of its process, and the last one was created by packaging commercial-off-the-shelf (COTS) materials thereby creating a new component.

Bryant, Robert G.↗
NASA NTRS1972

Formulation of an effective safety design review for the Skylab Program.

The Skylab Program is presenting a unique set of requirements by extending the capabilities of both men and equipment to withstand extended periods of time in space. The progression of space programs which preceded Skylab have provided a set of building blocks of knowledge and experience coupled with an extensive ground test program which makes it possible to plan its flight program without earlier, unmanned test flights. This approach, however, makes it mandatory that to the maximum extent possible, we factor into the design review process all the 'lessons learned' which are applicable. It is this conscious review of the Skylab design, based on checklists prepared from design criteria, gleaned from a variety of sources and experiences, which is the subject of this paper. A brief description of the Skylab Program, its objectives, and the missions planned for it are presented briefly to better understand the degree of extrapolation of hardware development from previous programs.

Cohen, H.↗
NASA NTRS1988

Post-Challenger evaluation of space shuttle risk assessment and management

As the shock of the Space Shuttle Challenger accident began to subside, NASA initiated a wide range of actions designed to ensure greater safety in various aspects of the Shuttle system and an improved focus on safety throughout the National Space Transportation System (NSTS) Program. Certain specific features of the NASA safety process are examined: the Critical Items List (CIL) and the NASA review of the Shuttle primary and backup units whose failure might result in the loss of life, the Shuttle vehicle, or the mission; the failure modes and effects analyses (FMEA); and the hazard analysis and their review. The conception of modern risk management, including the essential element of objective risk assessment is described and it is contrasted with NASA's safety process in general terms. The discussion, findings, and recommendations regarding particular aspects of the NASA STS safety assurance process are reported. The 11 subsections each deal with a different aspect of the process. The main lessons learned by SCRHAAC in the course of the audit are summarized.

Source record↗
NASA NTRS1989

The Real Time Interactive Display Environment (RTIDE), a display building tool developed by Space Shuttle flight controllers

NASA's Mission Control Center, located at Johnson Space Center, is incrementally moving from a centralized architecture to a distributed architecture. Starting with STS-29, some host-driven console screens will be replaced with graphics terminals driven by workstations. These workstations will be supplied realtime data first by the Real Time Data System (RTDS), a system developed inhouse, and then months later (in parallel with RTDS) by interim and subsequently operational versions of the Mission Control Center Upgrade (MCCU) software package. The Real Time Interactive Display Environment (RTIDE) was built by Space Shuttle flight controllers to support the rapid development of multiple new displays to support Shuttle flights. RTIDE is a display building tool that allows non-programmers to define object-oriented, event-driven, mouseable displays. Particular emphasis was placed on upward compatibility between RTIDE versions, ability to acquire data from different data sources, realtime performance, ability to modularly upgrade RTIDE, machine portability, and a clean, powerful user interface. The operational and organizational factors that drove RTIDE to its present form, the actual design itself, simulation and flight performance, and lessons learned in the process are discussed.

Kalvelage, Thomas A.↗
NASA NTRS1995

High-Temperature Optical Window Design

A high-temperature optical window is essential to the optical diagnostics of high-temperature combustion rigs. Laser Doppler velocimetry, schlieren photography, light sheet visualization, and laser-induced fluorescence spectroscopy are a few of the tests that require optically clear access to the combustor flow stream. A design was developed for a high-temperature window that could withstand the severe environment of the NASA Lewis 3200 F Lean Premixed Prevaporized (LPP) Flame Tube Test Rig. The development of this design was both time consuming and costly. This report documents the design process and the lessons learned, in an effort to reduce the cost of developing future designs for high-temperature optical windows.

Roeloffs, Norman↗