SEARCH · Engineering Papers
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.
Cyber supply chain risk management (C-SCRM) programs must consider operations that depend on the lifecycles of digital components such as hardware, firmware, software, and services. We integrate academic literature, historical incidents, and existing standards to identify obstacles faced by C-SCRM programs.
Following the loss of the first X-43 during launch, the mishap investigation board indicated the Fin Actuator System (FAS) needed to have a larger torque margin. To supply this added torque, a second actuator was added. The consequences of what seemed to be a simple modification would trouble the X-43 program. Because of the second actuator, a new computer board was required. This proved to be subject to electronic noise. This resulted in the actuator latch up in ground tests of the FAS for the second launch. Such a latch up would cause the Pegasus booster to fail, as the FAS was a single string system. The problem was corrected and the second flight was successful. The same modifications were added to the FAS for flight three. When the FAS underwent ground tests, it also latched up. The failure indicated that each computer board had a different tolerance to electronic noise. The problem with the FAS was corrected. Subsequently, another failure occurred, raising questions about the design, and the probability of failure for the X-43 Mach 10 flight. This was not simply a technical issue, but illuminated the difficulties facing both managers and engineers in assessing risk, design requirements, and probabilities in cutting edge aerospace projects.
Over the past decades, the global marine energy industry has suffered a number of serious technological and commercial setbacks. To help reduce the risks of industry failures and advance the development of new technologies, the U.S. Department of Energy (DOE) and the National Renewable Energy Laboratory (NREL) developed a Marine Energy Risk Management Framework in 2015, with this revision published in 2024. This risk management framework shall be utilized on all DOE Water Power Technologies Office (WPTO) projects that require system testing in the open water. By addressing uncertainties, the Marine Energy Risk Management Framework increases the likelihood of successful development of marine energy converter technology. It covers projects of any technology readiness level technology performance level (TPL) and all risk types (e.g. technological risk, regulatory risk, commercial risk) over the development cycle. This risk framework is not a substitute for other risk management procedures that may be required for marine operations, such as installations at sea, hoisting and rigging, safe diver operations, and other safety requirements. This risk framework is intended to meet DOE's risk management expectations for marine energy technology research and development efforts from WPTO. It also provides an overview of other relevant risk management tools and documentation.
This report has been developed by the National Aeronautics and Space Administration (NASA) Human Exploration and Operations Mission Directorate (HEOMD) Risk Management team in close coordination with the Engineering Directorate at LaRC. This document provides a point-in-time, cumulative, summary of actionable key lessons learned derived from the design project. Lessons learned invariably address challenges and risks and the way in which these areas have been addressed. Accordingly the risk management thread is woven throughout the document.
Evolving Project Integration, Innovation, and Collaboration (EPIIC) is a vision defined to transform the way projects manage information to support real-time decisions, capture best practices and lessons learned, perform assessments, and manage risk across a portfolio of projects. The foundational project management needs for data and information will be revolutionized through innovations on how we manage and access that data, implement configuration control, and certify compliance. The embedded intelligence of new interactive data interfaces integrate technical and programmatic data such that near real time analytics can be accomplished to more efficiently and accurately complete systems engineering and project management tasks. The system-wide data analytics that are integrated into customized data interfaces allows the growing team of engineers and managers required to develop and implement major NASA missions the ability to access authoritative source(s) of system information while greatly reducing the labor required to complete system assessments. This would allow, for example, much of what is accomplished in a scheduled design review to take place as needed, between any team members, at any time. An intelligent data interface that rigorously integrates systems engineering and project management information in near real time can provide substantially greater insight for systems engineers, project managers, and the large diverse teams required to complete a complex project. System engineers, programmatic personnel (those who focus on cost, schedule, and risk), the technical engineering disciplines, and project management can realize immediate benefit from the shared vision described herein. Implementation of the vision also enables significant improvements in the performance of the engineered system being developed.
Risk management strategies have become a recent important research topic to many aerospace organizations as they prepare to develop the revolutionary complex space systems of the future. Future multi-disciplinary complex space systems will make it absolutely essential for organizations to practice a rigorous, comprehensive risk management process, emphasizing thorough systems engineering principles to succeed. Project managers must possess strong leadership skills to direct high quality, cross-disciplinary teams for successfully developing revolutionary space systems that are ever increasing in complexity. Proactive efforts to reduce or eliminate risk throughout a project's lifecycle ideally must be practiced by all technical members in the organization. This paper discusses some of the risk management perspectives that were collected from senior managers and project managers of aerospace and aeronautical organizations by the use of interviews and surveys. Some of the programmatic risks which drive the success or failure of projects are revealed. Key findings lead to a number of insights for organizations to consider for proactively approaching the risks which face current and future complex space systems projects.
There are several engineering disciplines, such as reliability, supportability, quality assurance, human factors, risk management, safety, etc. Safety is an extremely important engineering specialty within NASA, and the consequence involving a loss of crew is considered a catastrophic event. Safety is not difficult to achieve when properly integrated at the beginning of each space systems project/start of mission planning. The key is to ensure proper handling of safety verification throughout each flight/mission phase. Today, Safety and Mission Assurance (S&MA) operations engineers continue to conduct these flight product reviews across all open flight products. As such, these reviews help ensure that each mission is accomplished with safety requirements along with controls heavily embedded in applicable flight products. Most importantly, the S&MA operations engineers are required to look for important design and operations controls so that safety is strictly adhered to as well as reflected in the final flight product.
Once a "Troubled Project" threatened with cancellation, the Stratospheric Observatory for Infrared Astronomy (SOFIA) Program has overcome many difficult challenges and recently achieved its first light images. To achieve success, SOFIA had to overcome significant deficiencies in fundamental Systems Engineering identified during a major Program restructuring. This presentation will summarize the lessons learn in Systems Engineering on the SOFIA Program. After the Program was reformulated, an initial assessment of Systems Engineering established the scope of the problem and helped to set a list of priorities that needed to be work. A revised Systems Engineering Management Plan (SEMP) was written to address the new Program structure and requirements established in the approved NPR7123.1A. An important result of the "Technical Planning" effort was the decision by the Program and Technical Leadership team to re-phasing the lifecycle into increments. The reformed SOFIA Program Office had to quickly develop and establish several new System Engineering core processes including; Requirements Management, Risk Management, Configuration Management and Data Management. Implementing these processes had to consider the physical and cultural diversity of the SOFIA Program team which includes two Projects spanning two NASA Centers, a major German partnership, and sub-contractors located across the United States and Europe. The SOFIA Program experience represents a creative approach to doing "System Engineering in the middle" while a Program is well established. Many challenges were identified and overcome. The SOFIA example demonstrates it is never too late to benefit from fixing deficiencies in the System Engineering processes.
Root Source Analysis (RoSA) is a systems engineering methodology that has been developed at NASA over the past five years. It is designed to reduce costs, schedule, and technical risks by systematically examining critical assumptions and the state of the knowledge needed to bring to fruition the products that satisfy mission-driven requirements, as defined for each element of the Work (or Product) Breakdown Structure (WBS or PBS). This methodology is sometimes referred to as the ValuStream method, as inherent in the process is the linking and prioritizing of uncertainties arising from knowledge shortfalls directly to the customer's mission driven requirements. RoSA and ValuStream are synonymous terms. RoSA is not simply an alternate or improved method for identifying risks. It represents a paradigm shift. The emphasis is placed on identifying very specific knowledge shortfalls and assumptions that are the root sources of the risk (the why), rather than on assessing the WBS product(s) themselves (the what). In so doing RoSA looks forward to anticipate, identify, and prioritize knowledge shortfalls and assumptions that are likely to create significant uncertainties/ risks (as compared to Root Cause Analysis, which is most often used to look back to discover what was not known, or was assumed, that caused the failure). Experience indicates that RoSA, with its primary focus on assumptions and the state of the underlying knowledge needed to define, design, build, verify, and operate the products, can identify critical risks that historically have been missed by the usual approaches (i.e., design review process and classical risk identification methods). Further, the methodology answers four critical questions for decision makers and risk managers: 1. What s been included? 2. What's been left out? 3. How has it been validated? 4. Has the real source of the uncertainty/ risk been identified, i.e., is the perceived problem the real problem? Users of the RoSA methodology have characterized it as a true bottoms up risk assessment.
Understanding and accounting for uncertainty in risk analysis is a critical step in the management and communication of risk in engineered systems. The component and system-level analysis to determine the probability of a negative outcome and its consequence is often quantified by a point estimate. Many Program and Enterprise decisions involving technical concerns and issues rely on reliability engineering activities to produce quantified risk analysis to inform the decision making process. At NASA, it is common to use a Probabilistic Risk Analysis (PRA) to inform the overall risk to Loss of Mission or Loss of Crew that involves integration across all spacecraft subsystem fault trees to produce an overall probability of mission failure. The point estimate is an estimate of this overall probability and is an immediate result of a fault tree model. It is the result of a model where the probability of each event is taken to be equal to its mean. The value provides an approximation of the overall mean without running any uncertainty calculations (e.g., no sampling). Using only the point estimate can lead to a false sense of precision and the point estimate may not match the resulting mean when uncertainty is taken into consideration. This paper will explore five conditions that can cause the PRA model mean to diverge from the point estimate and will provide engineers and managers insight into the importance of understanding uncertainty in the elements of PRA models.
A methodology is presented for integrating the systems-engineering management recommendation of prototyping into the traditional project-management process for developing large-scale systems. The suggested methodology begins with the identification of life-cycle risk areas, outlines the structure and conduct of the prototyping process, and defines the composition of the prototyping team. The methodology includes a step-by-step procedure for creating, executing, and documenting a prototyping test plan to evaluate design alternatives. It is argued that managers who adopt this methodology and apply it rigorously will increase the likelihood that the systems they build will be operationally effective and will be accepted by the intended users.
Over the past two decades, risk management and risk analysis have emerged throughout the business community in the United States (US) as prominent planning and development strategies used to mitigate risk of failure and ensure a high return on investment (ROI) for business endeavors (financial and otherwise). They are generic tools that can be applied to any business regardless of the sector (i.e., government, university, private) and have been used by the Federal government in the form of institutional practices aimed at maximizing the probability of success in business activities. One US Federal agency that incorporates risk management and analysis techniques into business and/or engineering activities is the National Aeronautics and Space Administration (NASA). The present work is a discussion on mission, spacecraft and instrument design (as well as technology development) and the role of risk management, analysis and mitigation as a fundamental tool in the design process.
Long-duration (seasonal) storage of natural gas (NG), which primarily consists of methane (CH 4 ), has been practiced for more than a hundred years at underground gas storage (UGS) facilities that use depleted hydrocarbon reservoirs, saline aquifers, and salt caverns. To enable hydrogen (H 2 ) to be used as a long-duration, energy-storage medium, similar facilities are envisioned for underground H 2 storage (UHS) of either H 2 or H 2 /NG mixtures. Experience with UGS can be used to guide recommended practices for developing and operating UHS facilities in porous reservoirs. The most important factors (formation/fluid properties and engineering choices) that influence the performance of UHS reservoirs have been identified and quantified in previous studies. These factors and choices influence phenomena that determine the sweep efficiency of the stored working gas. These phenomena include viscous fingering, hysteretic capillary trapping, and gravity override of the working gas, as well as the upconing of nonproductive fluid that determine the sweep efficiency of the stored working gas. This report describes initial recommended-practices and a project-development workflow for UHS facilities that utilize porous reservoirs, based on the current state-of-knowledge about H 2 behavior in the subsurface. The workflow sequentially addresses all aspects of UHS project development, including the identification of H 2 sources and users, site ranking and down-selection, geologic and reservoir-engineering characterization, reservoir design, testing, risk management, commissioning, operations, and monitoring for a UHS facility. The goal is to enable UHS facilities to be developed in an efficient and timely manner, while carefully managing project risks. This workflow is similar to that which has been developed for UGS facilities (see Figure 1 of API, 2022), with the addition of tasks and subtasks specific to H 2 and UHS. The project-development workflow is broken down into three major stages: (1) define the H 2 use case; (2) rank, down-select, and characterize potential, candidate UHS sites; and (3) reservoir design, integrity testing, risk assessment, commissioning, operations, and monitoring for selected UHS sites. Each major stage is further broken down into tasks and subtasks, which are described at a high level. This report also provides more detailed descriptions of all tasks and subtasks that involve reservoir analysis and testing.
Within the broad aerospace community the importance of identifying, documenting and widely sharing lessons learned during system development, flight test, operational or research programs/projects is broadly acknowledged. Documenting and sharing lessons learned helps managers and engineers to minimize project risk and improve performance of their systems. Often significant lessons learned on a project fail to get captured even though they are well known 'tribal knowledge' amongst the project team members. The physical act of actually writing down and documenting these lessons learned for the next generation of NASA GN&C engineers fails to happen on some projects for various reasons. In this paper we will first review the importance of capturing lessons learned and then will discuss reasons why some lessons are not documented. A simple proven approach called 'Pause and Learn' will be highlighted as a proven low-impact method of organizational learning that could foster the timely capture of critical lessons learned. Lastly some examples of 'lost' GN&C lessons learned from the aeronautics, spacecraft and launch vehicle domains are briefly highlighted. In the context of this paper 'lost' refers to lessons that have not achieved broad visibility within the NASA-wide GN&C CoP because they are either undocumented, masked or poorly documented in the NASA Lessons Learned Information System (LLIS).
- The Human System Risk Board (HSRB) is responsible for the management of a portfolio of 30 human system risks that NASA tracks and configuration manages to mitigate for future crewed exploration missions. - The HSRB has been exploring the concept of causal diagrams (in the form of Directed Acyclic Graphs or DAGs) as an approach to creating knowledge graphs for each risk to enable shared mental models of causal flow from spaceflight hazards to mission outcomes among HSRB Stakeholders. - These diagrams are intended to improve insight and communication of risk across the myriad subject matter experts and management interested in human system risk reduction. This includes program managers, systems engineers, and operators in addition to the Human Health and Performance Directorate. - The DAG project was intended to create the foundation for composition of the 30 baselined DAGs into a single risk network and software is being developed in parallel to enable this forward work.
A discussion of Systems Engineering principles as related to failure prevention methodologies and technologies. The presentation outlines requirements development, design reviews, verification and validation, and finally risk management prectices.
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.