SEARCH · Engineering Papers

Results for “risk management flight projects”

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.

SourceResearch connectionFrom yearThrough year

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 127 records · Page 7

All sources NASA NTRS DOE OSTI

NASA NTRS2015

Internal NASA Study: NASAs Protoflight Research Initiative

The NASA Protoflight Research Initiative is an internal NASA study conducted within the Office of the Chief Engineer to better understand the use of Protoflight within NASA. Extensive literature reviews and interviews with key NASA members with experience in both robotic and human spaceflight missions has resulted in three main conclusions and two observations. The first conclusion is that NASA's Protoflight method is not considered to be "prescriptive." The current policies and guidance allows each Program/Project to tailor the Protoflight approach to better meet their needs, goals and objectives. Second, Risk Management plays a key role in implementation of the Protoflight approach. Any deviations from full qualification will be based on the level of acceptable risk with guidance found in NPR 8705.4. Finally, over the past decade (2004 - 2014) only 6% of NASA's Protoflight missions and 6% of NASA's Full qualification missions experienced a publicly disclosed mission failure. In other words, the data indicates that the Protoflight approach, in and of it itself, does not increase the mission risk of in-flight failure. The first observation is that it would be beneficial to document the decision making process on the implementation and use of Protoflight. The second observation is that If a Project/Program chooses to use the Protoflight approach with relevant heritage, it is extremely important that the Program/Project Manager ensures that the current project's requirements falls within the heritage design, component, instrument and/or subsystem's requirements for both the planned and operational use, and that the documentation of the relevant heritage is comprehensive, sufficient and the decision well documented. To further benefit/inform this study, a recommendation to perform a deep dive into 30 missions with accessible data on their testing/verification methodology and decision process to research the differences between Protoflight and Full Qualification missions' Design Requirements and Verification & Validation (V&V) (without any impact or special request directly to the project).

Protoflight↗

NASA NTRS2017

Medical Data Architecture Project Status

The Medical Data Architecture (MDA) project supports the Exploration Medical Capability (ExMC) risk to minimize or reduce the risk of adverse health outcomes and decrements in performance due to in-flight medical capabilities on human exploration missions. To mitigate this risk, the ExMC MDA project addresses the technical limitations identified in ExMC Gap Med 07: We do not have the capability to comprehensively process medically-relevant information to support medical operations during exploration missions. This gap identifies that the current International Space Station (ISS) medical data management includes a combination of data collection and distribution methods that are minimally integrated with on-board medical devices and systems. Furthermore, there are variety of data sources and methods of data collection. For an exploration mission, the seamless management of such data will enable an increasingly autonomous crew than the current ISS paradigm. The MDA will develop capabilities that support automated data collection, and the necessary functionality and challenges in executing a self-contained medical system that approaches crew health care delivery without assistance from ground support. To attain this goal, the first year of the MDA project focused on reducing technical risk, developing documentation and instituting iterative development processes that established the basis for the first version of MDA software (or Test Bed 1). Test Bed 1 is based on a nominal operations scenario authored by the ExMC Element Scientist. This narrative was decomposed into a Concept of Operations that formed the basis for Test Bed 1 requirements. These requirements were successfully vetted through the MDA Test Bed 1 System Requirements Review, which permitted the MDA project to begin software code development and component integration. This paper highlights the MDA objectives, development processes, and accomplishments, and identifies the fiscal year 2017 milestones and deliverables in the upcoming year.

Data management↗

NASA NTRS2017

Medical Data Architecture Project Status

The Medical Data Architecture (MDA) project supports the Exploration Medical Capability (ExMC) risk to minimize or reduce the risk of adverse health outcomes and decrements in performance due to in-flight medical capabilities on human exploration missions. To mitigate this risk, the ExMC MDA project addresses the technical limitations identified in ExMC Gap Med 07: We do not have the capability to comprehensively process medically-relevant information to support medical operations during exploration missions. This gap identifies that the current International Space Station (ISS) medical data management includes a combination of data collection and distribution methods that are minimally integrated with on-board medical devices and systems. Furthermore, there are variety of data sources and methods of data collection. For an exploration mission, the seamless management of such data will enable an increasingly autonomous crew than the current ISS paradigm. The MDA will develop capabilities that support automated data collection, and the necessary functionality and challenges in executing a self-contained medical system that approaches crew health care delivery without assistance from ground support.To attain this goal, the first year of the MDA project focused on reducing technical risk, developing documentation and instituting iterative development processes that established the basis for the first version of MDA software (or Test Bed 1). Test Bed 1 is based on a nominal operations scenario authored by the ExMC Element Scientist. This narrative was decomposed into a Concept of Operations that formed the basis for Test Bed 1 requirements. These requirements were successfully vetted through the MDA Test Bed 1 System Requirements Review, which permitted the MDA project to begin software code development and component integration. This paper highlights the MDA objectives, development processes, and accomplishments, and identifies the fiscal year 2017 milestones and deliverables in the upcoming year.

Exploration medical system↗

NASA NTRS2011

Amine Swingbed Payload Project Management

The International Space Station (ISS) has been designed as a laboratory for demonstrating technologies in a microgravity environment, benefitting exploration programs by reducing the overall risk of implementing such technologies in new spacecraft. At the beginning of fiscal year 2010, the ISS program manager requested that the amine-based, pressure-swing carbon dioxide and humidity absorption technology (designed by Hamilton Sundstrand, baselined for the ORION Multi-Purpose Crew Vehicle, and tested at the Johnson Space Center in relevant environments, including with humans, since 2005) be developed into a payload for ISS Utilization. In addition to evaluating the amine technology in a flight environment before the first launch of the ORION vehicle, the ISS program wanted to determine the capability of the amine technology to remove carbon dioxide from the ISS cabin environment at the metabolic rate of the full 6-person crew. Because the amine technology vents the absorbed carbon dioxide and water vapor to space vacuum (open loop), additional hardware needed to be developed to minimize the amount of air and water resources lost overboard. Additionally, the payload system would be launched on two separate Space Shuttle flights, with the heart of the payload the swingbed unit itself launching a full year before the remainder of the payload. This paper discusses the project management and challenges of developing the amine swingbed payload in order to accomplish the technology objectives of both the open-loop ORION application as well as the closed-loop ISS application.

Hayley, Elizabeth↗

NASA NTRS2013

Amine Swingbed Payload Project Management

The International Space Station (ISS) has been designed as a laboratory for demonstrating technologies in a microgravity environment, benefitting exploration programs by reducing the overall risk of implementing such technologies in new spacecraft. At the beginning of fiscal year 2010, the ISS program manager requested that the amine-based, pressure-swing carbon dioxide and humidity absorption technology (designed by Hamilton Sundstrand, baselined for the Orion Multi-Purpose Crew Vehicle, and tested at the Johnson Space Center in relevant environments, including with humans, since 2005) be developed into a payload for ISS Utilization. In addition to evaluating the amine technology in a flight environment before the first launch of the Orion vehicle, the ISS program wanted to determine the capability of the amine technology to remove carbon dioxide from the ISS cabin environment at the metabolic rate of the full 6 ]person crew. Because the amine technology vents the absorbed carbon dioxide and water vapor to space vacuum (open loop), additional hardware needed to be developed to minimize the amount of air and water resources lost overboard. Additionally, the payload system would be launched on two separate Space Shuttle flights, with the heart of the payload-the swingbed unit itself-launching a full year before the remainder of the payload. This paper discusses the project management and challenges of developing the amine swingbed payload in order to accomplish the technology objectives of both the open -loop Orion application as well as the closed-loop ISS application.

Walsch, Mary↗

NASA NTRS2006

Zero to Integration in Eight Months, the Dawn Ground Data System Engineering Challange

The Dawn Project has presented the Ground Data System (GDS) with technical challenges driven by cost and schedule constraints commonly associated with National Aeronautics and Space Administration (NASA) Discovery Projects. The Dawn mission consists of a new and exciting Deep Space partnership among: the Jet Propulsion Laboratory (JPL), responsible for project management and flight operations; Orbital Sciences Corporation (OSC), spacecraft builder and responsible for flight system test and integration; and the University of California, at Los Angeles (UCLA), responsible for science planning and operations. As a cost-capped mission, one of Dawn s implementation strategies is to leverage from both flight and ground heritage. OSC's ground data system is used for flight system test and integration as part of the flight heritage strategy. Mission operations, however, are to be conducted with JPL s ground system. The system engineering challenge of dealing with two heterogeneous ground systems emerged immediately. During the first technical interchange meeting between the JPL s GDS Team and OSC's Flight Software Team, August 2003, the need to integrate the ground system with the flight software was brought to the table. This need was driven by the project s commitment to enable instrument engineering model integration in a spacecraft simulator environment, for both demonstration and risk mitigation purposes, by April 2004. This paper will describe the system engineering approach that was undertaken by JPL's GDS Team in order to meet the technical challenge within a non-negotiable eight-month schedule. Key to the success was adherence to an overall systems engineering process and fundamental systems engineering practices: decomposition of the project request into manageable requirements; definition of a structured yet flexible development process; integration of multiple ground disciplines and experts into a focused team effort; in-process risk management; and aggregation of the intermediate products to an integrated final product. In addition, this paper will highlight the role of lessons learned from the integration experience. The lessons learned from an early GDS deployment have served as the foundation for the design and implementation of the Dawn Ground Data System.

systems engineering↗

NASA NTRS1993

Analyzing human errors in flight mission operations

A long-term program is in progress at JPL to reduce cost and risk of flight mission operations through a defect prevention/error management program. The main thrust of this program is to create an environment in which the performance of the total system, both the human operator and the computer system, is optimized. To this end, 1580 Incident Surprise Anomaly reports (ISA's) from 1977-1991 were analyzed from the Voyager and Magellan projects. A Pareto analysis revealed that 38 percent of the errors were classified as human errors. A preliminary cluster analysis based on the Magellan human errors (204 ISA's) is presented here. The resulting clusters described the underlying relationships among the ISA's. Initial models of human error in flight mission operations are presented. Next, the Voyager ISA's will be scored and included in the analysis. Eventually, these relationships will be used to derive a theoretically motivated and empirically validated model of human error in flight mission operations. Ultimately, this analysis will be used to make continuous process improvements continuous process improvements to end-user applications and training requirements. This Total Quality Management approach will enable the management and prevention of errors in the future.

Bruno, Kristin J.↗

NASA NTRSDate not supplied

X-57 Static Structural Requirements and Airworthiness Approach

The National Aeronautics and Space Administration (NASA) Armstrong Flight Research Center (AFRC) (Edwards, California, U.S.A.) has been flying various types of aircraft, including experimental ones requiring structural modifications. Many of these aircraft aren’t typically certified by the Federal Aviation Administration (FAA) or the Department of Defense (DoD), but NASA can provide its own airworthiness certification utilizing a riskbased approach. The AFRC has established review processes and procedures to identify hazards, manage risks associated with flight programs, ensure safe flight operations, and satisfy programmatic requirements. The Aerostructures Branch at AFRC developed guidelines for the structural safety of flight, covering experimental aircraft, new components, payloads, and modifications. These guidelines detail structural design, analysis, instrumentation, ground testing, and flight-test operational aspects. The guidelines are followed for defining the airworthiness plan throughout the life cycle of a project. The guidelines can be tailored to the risk posture of each individual project. This paper documents the details of the structural airworthiness plan for the X-57 aircraft, including existing, modified, and newly developed structures. Additionally, it covers the design requirements and load cases specific to the X-57 aircraft.

Wesley W. Li↗

NASA NTRS2011

NASA Applications and Lessons Learned in Reliability Engineering

Since the Shuttle Challenger accident in 1986, communities across NASA have been developing and extensively using quantitative reliability and risk assessment methods in their decision making process. This paper discusses several reliability engineering applications that NASA has used over the year to support the design, development, and operation of critical space flight hardware. Specifically, the paper discusses several reliability engineering applications used by NASA in areas such as risk management, inspection policies, components upgrades, reliability growth, integrated failure analysis, and physics based probabilistic engineering analysis. In each of these areas, the paper provides a brief discussion of a case study to demonstrate the value added and the criticality of reliability engineering in supporting NASA project and program decisions to fly safely. Examples of these case studies discussed are reliability based life limit extension of Shuttle Space Main Engine (SSME) hardware, Reliability based inspection policies for Auxiliary Power Unit (APU) turbine disc, probabilistic structural engineering analysis for reliability prediction of the SSME alternate turbo-pump development, impact of ET foam reliability on the Space Shuttle System risk, and reliability based Space Shuttle upgrade for safety. Special attention is given in this paper to the physics based probabilistic engineering analysis applications and their critical role in evaluating the reliability of NASA development hardware including their potential use in a research and technology development environment.

Safie, Fayssal M.↗

NASA NTRS2016

Leadership Development Program Final Project

TOSC is NASA's prime contractor tasked to successfully assemble, test, and launch the EM1 spacecraft. TOSC success is highly dependent on design products from the other NASA Programs manufacturing and delivering the flight hardware; Space Launch System(SLS) and Multi-Purpose Crew Vehicle(MPCV). Design products directly feed into TOSC's: Procedures, Personnel training, Hardware assembly, Software development, Integrated vehicle test and checkout, Launch. TOSC senior management recognized a significant schedule risk as these products are still being developed by the other two (2) programs; SVE and ACE positions were created.

Design products required for Engineering↗

NASA NTRS1991

Lessons learned from Space Shuttle flight software and Mission Control software

The techniques utilized by NASA to manage risk in the development and operations of flight software and Mission Control Center software for the Space Shuttle are reviewed. Particular attention is given to independent software in the backup flight system, structured requirements and design techniques, multiple levels of testing in development and production, independent testing following production, and independence of development and production, and the Mission Control Center model for Real Time Data System project.

Muratore, John F.↗

NASA NTRS2011

Testing Strategies and Methodologies for the Max Launch Abort System

The National Aeronautics and Space Administration (NASA) Engineering and Safety Center (NESC) was tasked to develop an alternate, tower-less launch abort system (LAS) as risk mitigation for the Orion Project. The successful pad abort flight demonstration test in July 2009 of the "Max" launch abort system (MLAS) provided data critical to the design of future LASs, while demonstrating the Agency s ability to rapidly design, build and fly full-scale hardware at minimal cost in a "virtual" work environment. Limited funding and an aggressive schedule presented a challenge for testing of the complex MLAS system. The successful pad abort flight demonstration test was attributed to the project s systems engineering and integration process, which included: a concise definition of, and an adherence to, flight test objectives; a solid operational concept; well defined performance requirements, and a test program tailored to reducing the highest flight test risks. The testing ranged from wind tunnel validation of computational fluid dynamic simulations to component ground tests of the highest risk subsystems. This paper provides an overview of the testing/risk management approach and methodologies used to understand and reduce the areas of highest risk - resulting in a successful flight demonstration test.

Schaible, Dawn M.↗

NASA NTRSDate not supplied

Building Supply Chain Visibility for Risk Management: Illuminating the COVID-19 Pandemic Impact Upon NASA Suppliers

NASA mission projects rely upon global supply chains subject to an array of risks that threaten to disrupt or deny the timely, affordable provision of products and services as required for mission success. Visibility into these supply chains is key to the management of risks, such as those stemming from the coronavirus pandemic and its associated effects upon suppliers. Accordingly, the Supplier Research and Analysis (SRA) Program within Goddard Space Flight Center’s Safety and Mission Assurance (SMA) Directorate produced the COVID-19 pandemic/NASA suppliers dashboard as part of the NASA Meta Information System. The dashboard provides visibility and situational awareness to aid risk assessment, planning and decision-making over the course of the pandemic recovery phase. The approach of integrating data and information into visual dashboard displays has also been employed by the SRA Program to focus on specific risks pertaining to foreign-based suppliers. This webinar is presented by the NASA Office of SMA and its Supply Chain Risk Management Program, in collaboration with the NASA Safety Center and Goddard’s SMA Directorate.

supplier research and analysis, supply chain risk ↗

NASA NTRS2020

IV&V Assurance Case Design for Artemis II

As human-rated missions like those in NASA’s Artemis program continue to grow in both size and complexity, and the role of software in achieving mission objectives expands dramatically, NASA’s Independent Verification and Validation (IV&V) Teams face evolving challenges in assuring the safety and performance of the safety- and mission-critical embedded software that is essential to landing astronauts on the surface of the Moon by 2024. Key among these challenges is IV&V’s desire to present a cohesive, integrated assurance statement to its stakeholders that encapsulates and summarizes our assurance positions across the integrated Artemis systems and their combined role in support of a safe and successful flight. In order to meet this challenge, the IV&V Teams have begun a transition to using formal assurance case concepts and documentation in the Goal Structuring Notation (GSN) to build an argument in support of software assurance. IV&V recognizes significant benefits to the logical argumentation structure provided by assurance cases and GSN over our current practices for documenting and managing assurance claims. In order to reap these benefits, IV&V is integrating the use of assurance case concepts with our paradigm of follow-the-risk capability based assurance. Because of this, assurance cases created and used by IV&V are distinct from the sort of assurance case created by a development project or embedded software assurance organization. IV&V’s assurance cases depend much less upon standards and regulations, and more on evidence captured by IV&V regarding the environment, requirements, design, and implementation. IV&V constructs an independent network of claims based on an independent decomposition of arguments. Based upon the risk posture of these claims and their associated software and software artifacts, IV&V then develops and executes engineering analyses and testing, which provide evidence to either support or refute the claim. This emerging risk-informed assurance case methodology is being put into practice as IV&V plans for support of the Artemis II mission, the first flight of the Orion capsule and Space Launch System with astronauts on board.

Gerek Whitman↗

NASA NTRS2020

IV&V Assurance Case Design for Artemis II

As human-rated missions like those in NASA's Artemis program continue to grow in both size and complexity, and the role of software in achieving mission objectives expands dramatically, NASA's Independent Verification and Validation (IV&V) Teams face evolving challenges in assuring the safety and performance of the safety- and mission-critical embedded software that is essential to landing astronauts on the surface of the Moon by 2024. Key among these challenges is IV&V's desire to present a cohesive, integrated assurance statement to its stakeholders that encapsulates and summarizes our assurance positions across the integrated Artemis systems and their combined role in support of a safe and successful flight. In order to meet this challenge, the IV&V Teams have begun a transition to using formal assurance case concepts and documentation in the Goal Structuring Notation (GSN) to build an argument in support of software assurance. IV&V recognizes significant benefits to the logical argumentation structure provided by assurance cases and GSN over our current practices for documenting and managing assurance claims. In order to reap these benefits, IV&V is integrating the use of assurance case concepts with our paradigm of follow-the-risk capability based assurance. Because of this, assurance cases created and used by IV&V are distinct from the sort of assurance case created by a development project or embedded software assurance organization. IV&V's assurance cases depend much less upon standards and regulations, and more on evidence captured by IV&V regarding the environment, requirements, design, and implementation. IV&V constructs an independent network of claims based on an independent decomposition of arguments. Based upon the risk posture of these claims and their associated software and software artifacts, IV&V then develops and executes engineering analyses and testing, which provide evidence to either support or refute the claim. This emerging risk-informed assurance case methodology is being put into practice as IV&V plans for support of the Artemis II mission, the first flight of the Orion capsule and Space Launch System with astronauts on board.

Whitman, Gerek↗

NASA NTRS2005

Artificial Gravity Research Project

Protecting the health, safety, and performance of exploration-class mission crews against the physiological deconditioning resulting from long-term weightlessness during transit and long-term hypogravity during surface operations will require effective, multi-system countermeasures. Artificial gravity (AG), which would replace terrestrial gravity with inertial forces generated by rotating the transit vehicle or by a human centrifuge device within the transit vehicle or surface habitat, has long been considered a potential solution. However, despite its attractiveness as an efficient, multi-system countermeasure and its potential for improving the environment and simplifying operational activities (e.g., WCS, galley, etc.), much still needs to be learned regarding the human response to rotating environments before AG can be successfully implemented. This paper will describe our approach for developing and implementing a rigorous AG Research Project to address the key biomedical research questions that must be answered before developing effective AG countermeasure implementation strategies for exploration-class missions. The AG Research Project will be performed at JSC, ARC, extramural academic and government research venues, and international partner facilities maintained by DLR and IMBP. The Project includes three major ground-based human research subprojects that will lead to flight testing of intermittent short-radius AG in ISS crewmembers after 201 0, continuous long-radius AG in CEV crews transiting to and from the Moon, and intermittent short-radius AG plus exercise in lunar habitats. These human ground-based subprojects include: 1) a directed, managed international short-radius project to investigate the multi-system effectiveness of intermittent AG in human subjects deconditioned by bed rest, 2) a directed, managed long-radius project to investigate the capacity of humans to live and work for extended periods in rotating environments, and 3) a focused, investigator-initiated project to investigate system-specific adaptation to and from rotating environments. The AG Research Project also includes two major animal research subprojects: 1) a directed, managed ground-based subproject using rodents and, possibly, sub-human primates, to address mechanistic issues that cannot be studied in humans, to rapidly develop higher sample numbers than can be achieved in the human subprojects, and to establish feasible parameter operating bands to reduce the breadth of the human subprojects, and 2) a flight subproject using rodents to estimate the physiological effects of long term exposure to hypogravity and to investigate the effects of contamination by terrestrial gravity in estimating AG effectiveness. The animal flight subproject would be performed aboard ISS using the CAM module in approximately the 2008-201 1 timeframe. The paper will first present an overview of the key biomedical research questions to be answered. It will then describe the overall approaches to be utilized in developing and implementing the AG Research Project, including definition of the intended scientific research, management and development approaches, identification of roles and responsibilities, risk management, and definition of project deliverables. The primary focus of the paper will be on the first of the three ground-based human research subprojects, since it is the only one currently in development and is scheduled to start active subject investigations in April of 2005.

Kamman, Michelle R.↗

NASA NTRS2006

Observations, Ideas, and Opinions: Systems Engineering and Integration for Return to Flight

This presentation addresses project management and systems engineering and integration challenges for return to flight, focusing on the Thermal Protection System Tile Repair Project (TRP). The program documentation philosophy, communication with program requirements flow and philosophy and planned deliverables and documentation are outlined. The development of TRP 'use-as-is' analytical tools is also highlighted and emphasis is placed on the use flight history to assess pre-flight and real-time risk. Additionally, an overview is provided of the repair procedure, including an outline of the logistics deployment chart.

Gafka, George K.↗

NASA NTRS2011

Safety-Critical Partitioned Software Architecture: A Partitioned Software Architecture for Robotic

The flight software on virtually every mission currently managed by JPL has several major flaws that make it vulnerable to potentially fatal software defects. Many of these problems can be addressed by recently developed partitioned operating systems (OS). JPL has avoided adopting a partitioned operating system on its flight missions, primarily because doing so would require significant changes in flight software design, and the risks associated with changes of that magnitude cannot be accepted by an active flight project. The choice of a partitioned OS can have a dramatic effect on the overall system and software architecture, allowing for realization of benefits far beyond the concerns typically associated with the choice of OS. Specifically, we believe that a partitioned operating system, when coupled with an appropriate architecture, can provide a strong infrastructure for developing systems for which reusability, modifiability, testability, and reliability are essential qualities. By adopting a partitioned OS, projects can gain benefits throughout the entire development lifecycle, from requirements and design, all the way to implementation, testing, and operations.

(Avionics Application Standard Software Interface ↗