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 37 records · Page 2
All sourcesNASA NTRSDOE OSTI
NASA NTRS2010

Project Interface Requirements Process Including Shuttle Lessons Learned

Most failures occur at interfaces between organizations and hardware. Processing interface requirements at the start of a project life cycle will reduce the likelihood of costly interface changes/failures later. This can be done by adding Interface Control Documents (ICDs) to the Project top level drawing tree, providing technical direction to the Projects for interface requirements, and by funding the interface requirements function directly from the Project Manager's office. The interface requirements function within the Project Systems Engineering and Integration (SE&I) Office would work in-line with the project element design engineers early in the life cycle to enhance communications and negotiate technical issues between the elements. This function would work as the technical arm of the Project Manager to help ensure that the Project cost, schedule, and risk objectives can be met during the Life Cycle. Some ICD Lessons Learned during the Space Shuttle Program (SSP) Life Cycle will include the use of hardware interface photos in the ICD, progressive life cycle design certification by analysis, test, & operations experience, assigning interface design engineers to Element Interface (EI) and Project technical panels, and linking interface design drawings with project build drawings

Bauch, Garland T.↗
NASA NTRS2000

Supporting Development of Satellite's Guidance Navigation and Control Software: A Product Line Approach

The NASA Goddard Space Flight Center Flight Software Branch (FSB) is developing a Guidance, Navigation, and Control (GNC) Flight Software (FSW) product line. The demand for increasingly more complex flight software in less time while maintaining the same level of quality has motivated us to look for better FSW development strategies. The GNC FSW product line has been planned to address the core GNC FSW functionality very similar on many recent low/near Earth missions in the last ten years. Unfortunately these missions have not accomplished significant drops in development cost since a systematic approach towards reuse has not been adopted. In addition, new demands are continually being placed upon the FSW which means the FSB must become more adept at providing GNC FSW functionality's core so it can accommodate additional requirements. These domain features together with engineering concepts are influencing the specification, description and evaluation of FSW product line. Domain engineering is the foundation for emerging product line software development approaches. A product line is 'A family of products designed to take advantage of their common aspects and predicted variabilities'. In our product line approach, domain engineering includes the engineering activities needed to produce reusable artifacts for a domain. Application engineering refers to developing an application in the domain starting from reusable artifacts. The focus of this paper is regarding the software process, lessons learned and on how the GNC FSW product line manages variability. Existing domain engineering approaches do not enforce any specific notation for domain analysis or commonality and variability analysis. Usually, natural language text is the preferred tool. The advantage is the flexibility and adapt ability of natural language. However, one has to be ready to accept also its well-known drawbacks, such as ambiguity, inconsistency, and contradictions. While most domain analysis approaches are functionally oriented, the idea of applying the object-oriented approach in domain analysis is not new. Some authors propose to use UML as the notation underlying domain analysis. Our work is based on the same idea of merging UML and domain analysis. Further, we propose a few extensions to UML in order to express variability, and we define precisely their semantics so that a tool can support them. The extensions are designed to be implemented on the API of a popular industrial CASE tool, with obvious advantages in cost and availability of tool support. The paper outlines the product line processes and identifies where variability must be addressed. Then it describes the product line products with respect to how they accommodate variability. The Celestial Body subdomain is used as a working example. Our results to date are summarized and plans for the future are described.

McComas, David↗
NASA NTRS2006

Planned Environmental Microbiology Aspects of Future Lunar and Mars Missions

With the establishment of the Constellation Program, NASA has initiated efforts designed similar to the Apollo Program to return to the moon and subsequently travel to Mars. Early lunar sorties will take 4 crewmembers to the moon for 4 to 7 days. Later missions will increase in duration up to 6 months as a lunar habitat is constructed. These missions and vehicle designs are the forerunners of further missions destined for human exploration of Mars. Throughout the planning and design process, lessons learned from the International Space Station (ISS) and past programs will be implemented toward future exploration goals. The standards and requirements for these missions will vary depending on life support systems, mission duration, crew activities, and payloads. From a microbiological perspective, preventative measures will remain the primary techniques to mitigate microbial risk. Thus, most of the effort will focus on stringent preflight monitoring requirements and engineering controls designed into the vehicle, such as HEPA air filters. Due to volume constraints in the CEV, in-flight monitoring will be limited for short-duration missions to the measurement of biocide concentration for water potability. Once long-duration habitation begins on the lunar surface, a more extensive environmental monitoring plan will be initiated. However, limited in-flight volume constraints and the inability to return samples to Earth will increase the need for crew capabilities in determining the nature of contamination problems and method of remediation. In addition, limited shelf life of current monitoring hardware consumables and limited capabilities to dispose of biohazardous trash will drive flight hardware toward non-culture based methodologies, such as hardware that rapidly distinguishes biotic versus abiotic surface contamination. As missions progress to Mars, environmental systems will depend heavily on regeneration of air and water and biological waste remediation and regeneration systems, increasing the need for environmental monitoring. Almost complete crew autonomy will be needed for assessment and remediation of contamination problems. Cabin capacity will be limited; thus, current methods of microbial monitoring will be inadequate. Future methodology must limit consumables, and these consumables must have a shelf life of over three years. In summary, missions to the moon and Mars will require a practical design that prudently uses available resources to mitigate microbial risk to the crew.

Ott, C. Mark↗
NASA NTRS2015

Reliability and Probabilistic Risk Assessment - How They Play Together

Since the Space Shuttle Challenger accident in 1986, NASA has extensively used probabilistic analysis methods to assess, understand, and communicate the risk of space launch vehicles. Probabilistic Risk Assessment (PRA), used in the nuclear industry, is one of the probabilistic analysis methods NASA utilizes to assess Loss of Mission (LOM) and Loss of Crew (LOC) risk for launch vehicles. PRA is a system scenario based risk assessment that uses a combination of fault trees, event trees, event sequence diagrams, and probability distributions to analyze the risk of a system, a process, or an activity. It is a process designed to answer three basic questions: 1) what can go wrong that would lead to loss or degraded performance (i.e., scenarios involving undesired consequences of interest), 2) how likely is it (probabilities), and 3) what is the severity of the degradation (consequences). Since the Challenger accident, PRA has been used in supporting decisions regarding safety upgrades for launch vehicles. Another area that was given a lot of emphasis at NASA after the Challenger accident is reliability engineering. Reliability engineering has been a critical design function at NASA since the early Apollo days. However, after the Challenger accident, quantitative reliability analysis and reliability predictions were given more scrutiny because of their importance in understanding failure mechanism and quantifying the probability of failure, which are key elements in resolving technical issues, performing design trades, and implementing design improvements. Although PRA and reliability are both probabilistic in nature and, in some cases, use the same tools, they are two different activities. Specifically, reliability engineering is a broad design discipline that deals with loss of function and helps understand failure mechanism and improve component and system design. PRA is a system scenario based risk assessment process intended to assess the risk scenarios that could lead to a major/top undesirable system event, and to identify those scenarios that are high-risk drivers. PRA output is critical to support risk informed decisions concerning system design. This paper describes the PRA process and the reliability engineering discipline in detail. It discusses their differences and similarities and how they work together as complementary analyses to support the design and risk assessment processes. Lessons learned, applications, and case studies in both areas are also discussed in the paper to demonstrate and explain these differences and similarities.

Safie, Fayssal↗
NASA NTRS2015

Commercial Crew Cost Estimating - A Look at Estimating Processes, Challenges and Lessons Learned

To support annual PPBE budgets and NASA HQ requests for cost information for commercial crew transportation to the International Space Station (ISS), the NASA ISS ACES team developed system development and per flight cost estimates for the potential providers for each annual PPBE submit from 2009-2014. This paper describes the cost estimating processes used, challenges and lessons learned to develop estimates for this key NASA project that diverted from the traditional procurement approach and used a new way of doing business

Battle, Rick↗
NASA NTRS2006

Notional Airspace Operations Demonstration Plan

The airspace operations demonstration (AOD) is intended to show that the Access 5 Step 1 functional requirements can be met. The demonstration will occur in two phases. The initial on-range phase will be carried out in restricted airspace to demonstrate the cooperative collision avoidance (CCA) functional requirements and to provide risk-reduction for the AOD by allowing the test team to rehearse some elements of the demonstration mission. The CCA system to be used in these flights is based on Automatic Dependent Surveillance-Broadcast (ADS-B) which is a commercially-available system by which airplanes constantly broadcast their current position and altitude to other aircraft and ground resources over a dedicated radio datalink. The final phase will occur in the national airspace (NAS) and will be the formal demonstration of the remainder of the proposed functional requirements. The general objectives of the AOD are as follows: (1) Demonstrate that the UAS can aviate in the NAS (2) Demonstrate that the UAS can navigate in the NAS (3) Demonstrate that the UAS can communicate with the NAS (4) Demonstrate that the UAS can perform selected collision avoidance functions in the NAS (5) Demonstrate that the UAS can evaluate and avoid weather conflicts in the NAS (6) Demonstrate that the UAS can provide adequate command and control in the NAS In addition to the stated objectives, there are a number of goals for the flight demonstration. The demo can be accomplished successfully without achieving these goals, but these goals are to be used as a guideline for preparing for the mission. The goals are: (1) Mission duration of at least 24 hours (2) Loiter over heavy traffic to evaluate the data block issue identified during the Access 5 Airspace Operations Simulations (3) Document the contingency management process and lessons learned (4) Document the coordination process for Ground Control Stations (GCS) handoff (5) Document lessons learned regarding the process of flying in the NAS Preliminary planning for a notional mission to achieve the objectives and goals has been prepared. The planning is intended to serve as a guide for detailed planning of the AOD.

Trongale, Nicholas A.↗
NASA NTRS2011

Space Shuttle Ascent Flight Design Process: Evolution and Lessons Learned

The Space Shuttle Ascent Flight Design team is responsible for defining a launch to orbit trajectory profile that satisfies all programmatic mission objectives and defines the ground and onboard reconfiguration requirements for this high-speed and demanding flight phase. This design, verification and reconfiguration process ensures that all applicable mission scenarios are enveloped within integrated vehicle and spacecraft certification constraints and criteria, and includes the design of the nominal ascent profile and trajectory profiles for both uphill and ground-to-ground aborts. The team also develops a wide array of associated training, avionics flight software verification, onboard crew and operations facility products. These key ground and onboard products provide the ultimate users and operators the necessary insight and situational awareness for trajectory dynamics, performance and event sequences, abort mode boundaries and moding, flight performance and impact predictions for launch vehicle stages for use in range safety, and flight software performance. These products also provide the necessary insight to or reconfiguration of communications and tracking systems, launch collision avoidance requirements, and day of launch crew targeting and onboard guidance, navigation and flight control updates that incorporate the final vehicle configuration and environment conditions for the mission. Over the course of the Space Shuttle Program, ascent trajectory design and mission planning has evolved in order to improve program flexibility and reduce cost, while maintaining outstanding data quality. Along the way, the team has implemented innovative solutions and technologies in order to overcome significant challenges. A number of these solutions may have applicability to future human spaceflight programs.

Picka, Bret A.↗
NASA NTRS1988

Lessons learned in ground processing scientific and applications payloads at Kennedy Space Center

The payload ground processing of experiments which flew on the Shuttle is examined, including studies of atmosphere and earth observation, life science, advance technology, materials science, plasma physics, astrophysics and solar physics, astronomy, navigation and communication, and fluid mechanics. The process of designing and development payloads, the integration of instruments, carrier interface verification, and late servicing at the launch pad are discussed. The problems of cost, red tape, contamination, safety, and propriety protection are considered.

Elfrey, Priscilla↗
NASA NTRS1999

Designing Specification Languages for Process Control Systems: Lessons Learned and Steps to the Future

Previously, we defined a blackbox formal system modeling language called RSML (Requirements State Machine Language). The language was developed over several years while specifying the system requirements for a collision avoidance system for commercial passenger aircraft. During the language development, we received continual feedback and evaluation by FAA employees and industry representatives, which helped us to produce a specification language that is easily learned and used by application experts. Since the completion of the PSML project, we have continued our research on specification languages. This research is part of a larger effort to investigate the more general problem of providing tools to assist in developing embedded systems. Our latest experimental toolset is called SpecTRM (Specification Tools and Requirements Methodology), and the formal specification language is SpecTRM-RL (SpecTRM Requirements Language). This paper describes what we have learned from our use of RSML and how those lessons were applied to the design of SpecTRM-RL. We discuss our goals for SpecTRM-RL and the design features that support each of these goals.

Leveson, Nancy G.↗
NASA NTRS2016

The International Space Station (ISS) Solar Alpha Rotary Joint (SARJ): Materials & Processes (M&P) Lessons Learned for a Large, Spacecraft Rotating Mechanism

The ISS utilizes two large rotating mechanisms, the SARJ, as part of the solar arrays alignment system for more efficient power generation. The SARJ is a 10.3m circumference, nitrided 15-5PH steel race ring of triangular cross-section, with 12 sets of trundle bearing assemblies transferring load across the rolling joint. The SARJ mechanism rotates continuously and slowly - once every orbit, or every 90 minutes. In 2008, the starboard SARJ suffered a lubrication failure, resulting in severe damage (spalling) of one of the race ring surfaces. Extensive effort was conducted to prevent the port SARJ from suffering the same failure, and fortunately was ultimately successful in recovering the functionality of the starboard SARJ. The M&P function was key in determining the cause of failure and the means for mechanism recovery. From a M&P lessons-learned perspective, observations are made concerning the original SARJ design parameters (boundary conditions), the perceived need for nitriding the race ring, the test conditions employed during qualification, the environmental controls used for the hardware preflight, and the lubrication robustness necessary for complex kinematic mechanisms expecting high-reliability and long-life.

Golden, Johnny L.↗
NASA NTRS2016

The International Space Station (ISS) Solar Alpha Rotary Joint (SARJ): Materials & Processes (M&P) Lessons Learned for a Large, Rotating Spacecraft Mechanism

The International Space Station (ISS) utilizes two large rotating mechanisms, the solar alpha rotary joints (SARJs), as part of the solar arrays' alignment system for more efficient power generation. Each SARJ is a 10.3m circumference, nitrided 15-5PH steel race ring of triangular cross-section, with 12 sets of trundle bearing assemblies transferring load across the rolling joint. The SARJ mechanism rotates continuously and slowly - once every orbit, or every 90 minutes. In 2007, the starboard SARJ suffered a lubrication failure, resulting in severe damage (spalling) to one of the race ring surfaces. Extensive effort was conducted to prevent the port SARJ from suffering the same failure, and fortunately that effort was ultimately successful in also recovering the functionality of the starboard SARJ. The M&P engineering function was key in determining the cause of failure and the means for mechanism recovery. From a M&P lessons-learned perspective, observations are made concerning the original SARJ design parameters (boundary conditions), the perceived need for nitriding the race ring, the test conditions employed during qualification, the environmental controls used for the hardware preflight, and the lubrication robustness necessary for complex kinematic mechanisms expecting high-reliability and long-life.

Golden, Johnny L.↗
NASA NTRSDate not supplied

Space Shuttle Cargo Integration Coupled Loads Analysis Lessons Learned

When a system experiences a loading environment characterized by rapidly varying forces, such as a rocket launch, a transient analysis is used to analyze the response of the system. The most common transient analysis methodology is the Coupled Loads Analysis (CLA). CLAs are used by the automotive and aerospace industry to analyze cars, trucks, planes, helicopters, spacecraft, etc. The Space Shuttle program used the CLA methodology to assess the compatibility of the payload with the Orbiter and the flight environment. The Space Shuttle Verification Loads Analysis (VLA) was a standardized CLA process that started between ten and thirteen months prior to launch, and included several meetings as well as analysis by both the Space Shuttle Program and the payload developers to verify that the payloads were compatible with the flight loads environment and would not interact negatively with the vehicle. Over the course of the Space Shuttle Program, many improvements were made to the process, which reduced cycle time and improved manifest flexibility. There were several issues which were never fully addressed, but workarounds were developed to keep the process flowing. The lessons learned included automation of some processes and standardization of others, early assessments, improved documentation and better coordination with all stakeholders in the process. Lessons learned also included the limitations in the current process, and what to do to avoid the same issues in the future.

Erica E. Bruno↗
NASA NTRSDate not supplied

Space Shuttle Cargo Integration Coupled Loads Analysis Lessons Learned

When a system experiences a loading environment characterized by rapidly varying forces, such as a rocket launch, a transient analysis is used to analyze the response of the system. The most common transient analysis methodology is the Coupled Loads Analysis(CLA). CLAs are used by the automotive and aerospace industry to analyze cars, trucks,planes, helicopters, spacecraft, etc. The Space Shuttle program used the CLA methodology to assess the compatibility of the payload with the Orbiter and the flight environment. The Space Shuttle Verification Loads Analysis (VLA) was a standardized CLA process that started between ten and thirteen months prior to launch, and included several meetings as well as analysis by both the Space Shuttle Program and the payload developers to verify that the payloads were compatible with the flight loads environment and would not interact negatively with the vehicle. Over the course of the Space Shuttle Program, many improvements were made to the process, which reduced cycle time and improved manifest flexibility. There were several issues which were never fully addressed, but work-arounds were developed to keep the process flowing. The lessons learned included automation of some processes and standardization of others, early assessments, improved documentation and better coordination with all stakeholders in the process. Lessons learned also included the limitations in the current process, and what to do to avoid the same issues.

ERICA E. BRUNO↗
NASA NTRS2011

Lessons Learned from Shuttle Payload Verification Loads Analysis

When a system experiences a loading environment characterized by rapidly varying forces, such as a rocket launch, a transient analysis is used to analyze the response of the system. The most common transient analysis methodology is the Coupled Loads Analysis (CLA). CLAs are used by the automotive and aerospace industry to analyze cars, trucks, planes, helicopters, spacecraft, etc. The Space Shuttle program also uses the CLA methodology to assess the compatibility of the payload with the Orbiter and the flight environment. The Space Shuttle Verification Loads Analysis (VLA) was a standardized process that started between ten and thirteen months prior to launch, and included several meetings as well as analysis by both the Shuttle Program and the payload developers. Over the course of the Space Shuttle Program, many improvements were made to the process which helped to reduce cycle time and improve manifest flexibility. There were also several issues which were never properly addressed, but a work-around would be developed to keep the process flowing. The lessons learned included automation of some processes and standardization of others, early assessments, improved documentation and better coordination with all stakeholders in the process. Lessons learned also included the limitations in the current process, and what needs to be planned for in the future to avoid the same issues.

Bruno, Erica↗
NASA NTRS2012

Assuring that Lessons Learned Critical to Mission Success Get Used

NASA has an established process for documenting and disseminating lessons learned from spaceflight missions and related activities. However, independent assessments of the NASA lessons learned process conducted in 2002, 2003, and 2011 have concluded that NASA programs and projects are failing to heed and apply these lessons learned. JPL recently completed implementation of a three-pronged approach to assure that NASA lessons learned get used by JPL spaceflight projects.

Oberhettinger, David↗
NASA NTRS2005

Let's Roll! Rolling Out or Deploying SEPG Assets

The topics covered in this slide presentation are: the general approach to software quality improvement (SQI) at Jet Propulsion Institute, the SQI deployment process, and lessons learned in regard to SQI. The Software Engineering Process Group (SEPG) is the group charged with SQI. The initial focus of the Software Quality Improvement (SQI) Project is on mission-critical software for flight projects, their spacecraft and instrument systems, and their ground systems.

process improvements↗