Results for “Engineering management” — Page 19

NASA NTRSDate not supplied

Flexible Data Fusion for Air Quality Estimation and Forecasting in Google Earth Engine to support Global Health Management Needs

The assessment and forecasting of air quality around the world at high spatial and temporal resolution can be enhanced by integrating data from multiple sources including models, satellites, regulatory monitors, and low-cost sensors. Such integration is subject to numerous technical challenges, however, including heterogeneous data resolution and formatting, different levels of data availability and reliability, and computational and capacity challenges to developing data fusion tools and platforms. This presentation will provide an overview of a NASA-funded effort to develop a data fusion system within the Google Earth Engine platform which integrates these air quality data sources to produce comprehensive assessments and forecasts of key air pollutants at sub-daily and sub-city scales. The system is being developed in collaboration with city- and regional-level air quality managers and will provide them with information to the assess and anticipate the health impacts of poor air quality, track local changes in air quality due to ongoing transportation and land use changes, and identify potential gaps in their current air quality monitoring strategies. The presentation will report advances achieved through the project, including bringing local air quality monitoring data into Google Earth Engine, quantifying uncertainties in air quality estimates and forecasts, and tailored communications tools providing integration into end-user processes to meet their needs.

Nathan R. Pavlovic↗

NASA NTRS1985

IPAD: Integrated Programs for Aerospace-vehicle Design

Early work was performed to apply data base technology in support of the management of engineering data in the design and manufacturing environments. The principal objective of the IPAD project is to develop a computer software system for use in the design of aerospace vehicles. Two prototype systems are created for this purpose. Relational Information Manager (RIM) is a successful commercial product. The IPAD Information Processor (IPIP), a much more sophisticated system, is still under development.

Miller, R. E., Jr.↗

NASA NTRS1991

Results of prototype software development for automation of shuttle proximity operations

A Rendezvous Expert System (REX) was implemented on a Symbolics 3650 processor and integrated with the 6 DOF, high fidelity Systems Engineering Simulator (SES) at the NASA Johnson Space Center in Houston, Texas. The project goals were to automate the terminal phase of a shuttle rendezvous, normally flown manually by the crew, and proceed automatically to docking with the Space Station Freedom (SSF). The project goals were successfully demonstrated to various flight crew members, managers, and engineers in the technical community at JSC. The project was funded by NASA's Office of Space Flight, Advanced Program Development Division. Because of the complexity of the task, the REX development was divided into two distinct efforts. One to handle the guidance and control function using perfect navigation data, and another to provide the required visuals for the system management functions needed to give visibility to the crew members of the progress being made towards docking the shuttle with the LVLH stabilized SSF.

Hiers, Harry K.↗

NASA NTRS2024

Planetary Science Training for Artemis Missions

Planetary geology training for Artemis crews and mission support teams is well underway. We recently reported on the development of our geology/planetary science training flow, and the cross-agency coordination efforts necessary for implementing the training [1, 2]. We discussed our progressive geology training program that starts with incoming astronaut classes, offers opportunities to maintain the geology proficiency between flight assignments, and trains the broader Artemis engineering-operations management community in geology and basic field methods [3, 4]. In this abstract, we outline and discuss our 2023 accomplishments and near-term plans for continued development of lunar science classroom content, field training objectives, and the delivery of geology training to astronauts and the Artemis mission engineers.

Artemis↗

NASA NTRS2024

Integrated Systems Engineering, Safety, Reliability and Risk Management – Minimizing Black Swan Events

This paper examines key barriers that can possibly inhibit safe and reliable mission execution and, in the worst case, result in loss of human life due to many unknown contributory factors that can lead to Black Swan events. Some of the representative contributory factors include decision errors, overconfidence and a host of common causes including cultural and human factors. Decisions are always easy to criticize in hindsight when more information is available after a major accident. Depending on the type and complexity of the project and/or mission, the catastrophic risks of drifting into failure can be alleviated by implementing uniquely and strategically tailored Integrated-System-of-Systems, dynamic, risk-informed decision management processes. This paper presents some of the lessons learned from James Webb Space Telescope (JWST), NASA’s Human Space Flight program, and industry that provide motivation to organizations working on mega-complex missions to prudently accomplish targeted mission success. These lessons are important for future human Lunar, Mars and Beyond missions planned to be pursued by NASA through a public-private partnership using nimble but effective safety-conscious, proven sound engineering practices including implementation of integrated risk mitigation practices.

SLS↗

NASA NTRS1992

Reliability evaluation methodology for NASA applications

Liquid rocket engine technology has been characterized by the development of complex systems containing large number of subsystems, components, and parts. The trend to even larger and more complex system is continuing. The liquid rocket engineers have been focusing mainly on performance driven designs to increase payload delivery of a launch vehicle for a given mission. In otherwords, although the failure of a single inexpensive part or component may cause the failure of the system, reliability in general has not been considered as one of the system parameters like cost or performance. Up till now, quantification of reliability has not been a consideration during system design and development in the liquid rocket industry. Engineers and managers have long been aware of the fact that the reliability of the system increases during development, but no serious attempts have been made to quantify reliability. As a result, a method to quantify reliability during design and development is needed. This includes application of probabilistic models which utilize both engineering analysis and test data. Classical methods require the use of operating data for reliability demonstration. In contrast, the method described in this paper is based on similarity, analysis, and testing combined with Bayesian statistical analysis.

Taneja, Vidya S.↗

NASA NTRS2008

Space Transportation System Availability Requirement and Its Influencing Attributes Relationships

It is important that engineering and management accept the need for an availability requirement that is derived with its influencing attributes. It is the intent of this paper to provide the visibility of relationships of these major attribute drivers (variables) to each other and the resultant system inherent availability. Also important to provide bounds of the variables providing engineering the insight required to control the system's engineering solution, e.g., these influencing attributes become design requirements also. These variables will drive the need to provide integration of similar discipline functions or technology selection to allow control of the total parts count. The relationship of selecting a reliability requirement will place a constraint on parts count to achieve a given availability requirement or if allowed to increase the parts count will drive the system reliability requirement higher. They also provide the understanding for the relationship of mean repair time (or mean down time) to maintainability, e.g., accessibility for repair, and both the mean time between failure, e.g., reliability of hardware and availability. The concerns and importance of achieving a strong availability requirement is driven by the need for affordability, the choice of using the two launch solution for the single space application, or the need to control the spare parts count needed to support the long stay in either orbit or on the surface of the moon. Understanding the requirements before starting the architectural design concept will avoid considerable time and money required to iterate the design to meet the redesign and assessment process required to achieve the results required of the customer's space transportation system. In fact the impact to the schedule to being able to deliver the system that meets the customer's needs, goals, and objectives may cause the customer to compromise his desired operational goal and objectives resulting in considerable increased life cycle cost of the fielded space transportation system.

Rhodes, Russell E.↗

NASA NTRS2008

Space Transportation System Availability Requirements and Its Influencing Attributes Relationships

It is important that engineering and management accept the need for an availability requirement that is derived with its influencing attributes. It is the intent of this paper to provide the visibility of relationships of these major attribute drivers (variables) to each other and the resultant system inherent availability. Also important to provide bounds of the variables providing engineering the insight required to control the system's engineering solution, e.g., these influencing attributes become design requirements also. These variables will drive the need to provide integration of similar discipline functions or technology selection to allow control of the total parts count. The relationship of selecting a reliability requirement will place a constraint on parts count to achieve a given availability requirement or if allowed to increase the parts count will drive the system reliability requirement higher. They also provide the understanding for the relationship of mean repair time (or mean down time) to maintainability, e.g., accessibility for repair, and both the mean time between failure, e.g., reliability of hardware and availability. The concerns and importance of achieving a strong availability requirement is driven by the need for affordability, the choice of using the two launch solution for the single space application, or the need to control the spare parts count needed to support the long stay in either orbit or on the surface of the moon. Understanding the requirements before starting the architectural design concept will avoid considerable time and money required to iterate the design to meet the redesign and assessment process required to achieve the results required of the customer's space transportation system. In fact the impact to the schedule to being able to deliver the system that meets the customer's needs, goals, and objectives may cause the customer to compromise his desired operational goal and objectives resulting in considerable increased life cycle cost of the fielded space transportation system.

Rhodes, Russell E.↗

NASA NTRS2008

Space Transportation System Availability Requirement and Its Influencing Attributes Relationships

It is important that engineering and management accept the need for an availability requirement that is derived with its influencing attributes. It is the intent of this paper to provide the visibility of relationships of these major attribute drivers (variables) to each other and the resultant system inherent availability. Also important to provide bounds of the variables providing engineering the insight required to control the system's engineering solution, e.g., these influencing attributes become design requirements also. These variables will drive the need to provide integration of similar discipline functions or technology selection to allow control of the total parts count. The relationship of selecting a reliability requirement will place a constraint on parts count to achieve a given availability requirement or if allowed to increase the parts count will drive the system reliability requirement higher. They also provide the understanding for the relationship of mean repair time (or mean down time) to maintainability, e.g., accessibility for repair, and both the mean time between failure, e.g., reliability of hardware and availability. The concerns and importance of achieving a strong availability requirement is driven by the need for affordability, the choice of using the two launch solution for the single space application, or the need to control the spare parts count needed to support the long stay in either orbit or on the surface of the moon. Understanding the requirements before starting the architectural design concept will avoid considerable time and money required to iterate the design to meet the redesign and assessment process required to achieve the results required of the customer's space transportation system. In fact the impact to the schedule to being able to deliver the system that meets the customer's needs, goals, and objectives may cause the customer to compromise his desired operational goal and objectives resulting in considerable increased life cycle cost of the fielded space transportation system.

reliability↗

NASA NTRS2017

How Engineers Negotiate Domain Boundaries in a Complex, Interdisciplinary Engineering Project

Engineering educators have an essential role in preparing engineers to work in a complex, interdisciplinary workforce. While much engineering education focuses on teaching students to develop disciplinary expertise in specific engineering domains, there is a strong need to teach engineers about the knowledge that they develop or use in their work (Bucciarelli 1994, Allenby Sarewitz, 2011; Frodeman, 2013). The purpose of this research is to gain a better understanding of the knowledge systems of practicing engineers through observations of their practices such that the insights learned can guide future education efforts. Using an example from a complex and interdisciplinary engineering project, this paper presents a case study overviewing the types of epistemological (or knowledge-acquiring or using) complexities that engineers navigate. Specifically, we looked at a discussion of the thermal design of a CubeSat that occurred during an engineering review at NASA. We analyzed the review using a framework that we call 'peak events', or pointed discussions between reviewers, project engineers, and managers. We examined the dialog within peak events to identify the ways that knowledge was brought to bear, highlighting discussions of uncertainty and the boundaries of knowledge claims. We focus on one example discussion surrounding the thermal design of the CubeSat, which provides a particularly thorough example of a knowledge system since the engineers present explained, justified, negotiated, and defended knowledge within a social setting. Engineering students do not get much practice or instruction in explicitly negotiating knowledge systems and epistemic standards in this way. We highlight issues that should matter to engineering educators, such as the need to discuss what level of uncertainty is sufficient and the need to negotiate boundaries of system responsibility. Although this analysis is limited to a single discussion or 'peak event', our case shows that this type of discussion can occur in engineering and suggests that it could be important for future engineering education research.

ethnography↗

NASA NTRS1986

Cost Risk Analysis Based on Perception of the Engineering Process

In most cost estimating applications at the NASA Langley Research Center (LaRC), it is desirable to present predicted cost as a range of possible costs rather than a single predicted cost. A cost risk analysis generates a range of cost for a project and assigns a probability level to each cost value in the range. Constructing a cost risk curve requires a good estimate of the expected cost of a project. It must also include a good estimate of expected variance of the cost. Many cost risk analyses are based upon an expert's knowledge of the cost of similar projects in the past. In a common scenario, a manager or engineer, asked to estimate the cost of a project in his area of expertise, will gather historical cost data from a similar completed project. The cost of the completed project is adjusted using the perceived technical and economic differences between the two projects. This allows errors from at least three sources. The historical cost data may be in error by some unknown amount. The managers' evaluation of the new project and its similarity to the old project may be in error. The factors used to adjust the cost of the old project may not correctly reflect the differences. Some risk analyses are based on untested hypotheses about the form of the statistical distribution that underlies the distribution of possible cost. The usual problem is not just to come up with an estimate of the cost of a project, but to predict the range of values into which the cost may fall and with what level of confidence the prediction is made. Risk analysis techniques that assume the shape of the underlying cost distribution and derive the risk curve from a single estimate plus and minus some amount usually fail to take into account the actual magnitude of the uncertainty in cost due to technical factors in the project itself. This paper addresses a cost risk method that is based on parametric estimates of the technical factors involved in the project being costed. The engineering process parameters are elicited from the engineer/expert on the project and are based on that expert's technical knowledge. These are converted by a parametric cost model into a cost estimate. The method discussed makes no assumptions about the distribution underlying the distribution of possible costs, and is not tied to the analysis of previous projects, except through the expert calibrations performed by the parametric cost analyst.

Dean, Edwin B.↗

NASA NTRS2014

Inverted Outflow Ground Testing of Cryogenic Propellant Liquid Acquisition Devices

NASA is currently developing propulsion system concepts for human exploration. These propulsion concepts will require the vapor free acquisition and delivery of the cryogenic propellants stored in the propulsion tanks during periods of microgravity to the exploration vehicles engines. Propellant management devices (PMD's), such as screen channel capillary liquid acquisition devices (LAD's), vanes and sponges have been used for earth storable propellants in the Space Shuttle Orbiter and other spacecraft propulsion systems, but only very limited propellant management capability currently exists for cryogenic propellants. NASA is developing PMD technology as a part of their cryogenic fluid management (CFM) project. System concept studies have looked at the key factors that dictate the size and shape of PMD devices and established screen channel LADs as an important component of PMD design. Modeling validated by normal gravity experiments is examining the behavior of the flow in the LAD channel assemblies (as opposed to only prior testing of screen samples) at the flow rates representative of actual engine service (similar in size to current launch vehicle upper stage engines). Recently testing of rectangular LAD channels has included inverted outflow in liquid oxygen and liquid hydrogen. This paper will report the results of liquid oxygen testing compare and contrast them with the recently published hydrogen results; and identify the sensitivity of these results to flow rate and tank internal pressure.

Microgravity↗

NASA NTRS2014

Inverted Outflow Ground Testing of Cryogenic Propellant Liquid Acquisition Devices

NASA is currently developing propulsion system concepts for human exploration. These propulsion concepts will require the vapor free acquisition and delivery of the cryogenic propellants stored in the propulsion tanks during periods of microgravity to the exploration vehicles engines. Propellant management devices (PMDs), such as screen channel capillary liquid acquisition devices (LADs), vanes and sponges have been used for earth storable propellants in the Space Shuttle Orbiter and other spacecraft propulsion systems, but only very limited propellant management capability currently exists for cryogenic propellants. NASA is developing PMD technology as a part of their cryogenic fluid management (CFM) project. System concept studies have looked at the key factors that dictate the size and shape of PMD devices and established screen channel LADs as an important component of PMD design. Modeling validated by normal gravity experiments is examining the behavior of the flow in the LAD channel assemblies (as opposed to only prior testing of screen samples) at the flow rates representative of actual engine service (similar in size to current launch vehicle upper stage engines). Recently testing of rectangular LAD channels has included inverted outflow in liquid oxygen and liquid hydrogen. This paper will report the results of liquid oxygen testing compare and contrast them with the recently published hydrogen results; and identify the sensitivity these results to flow rate and tank internal pressure.

Liquid Oxygen↗

NASA NTRS2005

Performance Evaluation of a Data Validation System

Online data validation is a performance-enhancing component of modern control and health management systems. It is essential that performance of the data validation system be verified prior to its use in a control and health management system. A new Data Qualification and Validation (DQV) Test-bed application was developed to provide a systematic test environment for this performance verification. The DQV Test-bed was used to evaluate a model-based data validation package known as the Data Quality Validation Studio (DQVS). DQVS was employed as the primary data validation component of a rocket engine health management (EHM) system developed under NASA's NGLT (Next Generation Launch Technology) program. In this paper, the DQVS and DQV Test-bed software applications are described, and the DQV Test-bed verification procedure for this EHM system application is presented. Test-bed results are summarized and implications for EHM system performance improvements are discussed.

Wong, Edmond↗

NASA NTRS2004

Strategy Developed for Selecting Optimal Sensors for Monitoring Engine Health

Sensor indications during rocket engine operation are the primary means of assessing engine performance and health. Effective selection and location of sensors in the operating engine environment enables accurate real-time condition monitoring and rapid engine controller response to mitigate critical fault conditions. These capabilities are crucial to ensure crew safety and mission success. Effective sensor selection also facilitates postflight condition assessment, which contributes to efficient engine maintenance and reduced operating costs. Under the Next Generation Launch Technology program, the NASA Glenn Research Center, in partnership with Rocketdyne Propulsion and Power, has developed a model-based procedure for systematically selecting an optimal sensor suite for assessing rocket engine system health. This optimization process is termed the systematic sensor selection strategy. Engine health management (EHM) systems generally employ multiple diagnostic procedures including data validation, anomaly detection, fault-isolation, and information fusion. The effectiveness of each diagnostic component is affected by the quality, availability, and compatibility of sensor data. Therefore systematic sensor selection is an enabling technology for EHM. Information in three categories is required by the systematic sensor selection strategy. The first category consists of targeted engine fault information; including the description and estimated risk-reduction factor for each identified fault. Risk-reduction factors are used to define and rank the potential merit of timely fault diagnoses. The second category is composed of candidate sensor information; including type, location, and estimated variance in normal operation. The final category includes the definition of fault scenarios characteristic of each targeted engine fault. These scenarios are defined in terms of engine model hardware parameters. Values of these parameters define engine simulations that generate expected sensor values for targeted fault scenarios. Taken together, this information provides an efficient condensation of the engineering experience and engine flow physics needed for sensor selection. The systematic sensor selection strategy is composed of three primary algorithms. The core of the selection process is a genetic algorithm that iteratively improves a defined quality measure of selected sensor suites. A merit algorithm is employed to compute the quality measure for each test sensor suite presented by the selection process. The quality measure is based on the fidelity of fault detection and the level of fault source discrimination provided by the test sensor suite. An inverse engine model, whose function is to derive hardware performance parameters from sensor data, is an integral part of the merit algorithm. The final component is a statistical evaluation algorithm that characterizes the impact of interference effects, such as control-induced sensor variation and sensor noise, on the probability of fault detection and isolation for optimal and near-optimal sensor suites.

Source record↗

NASA NTRS2013

Assessment Environment for Complex Systems Software Guide

This Software Guide (SG) describes the software developed to test the Assessment Environment for Complex Systems (AECS) by the West Virginia High Technology Consortium (WVHTC) Foundation's Mission Systems Group (MSG) for the National Aeronautics and Space Administration (NASA) Aeronautics Research Mission Directorate (ARMD). This software is referred to as the AECS Test Project throughout the remainder of this document. AECS provides a framework for developing, simulating, testing, and analyzing modern avionics systems within an Integrated Modular Avionics (IMA) architecture. The purpose of the AECS Test Project is twofold. First, it provides a means to test the AECS hardware and system developed by MSG. Second, it provides an example project upon which future AECS research may be based. This Software Guide fully describes building, installing, and executing the AECS Test Project as well as its architecture and design. The design of the AECS hardware is described in the AECS Hardware Guide. Instructions on how to configure, build and use the AECS are described in the User's Guide. Sample AECS software, developed by the WVHTC Foundation, is presented in the AECS Software Guide. The AECS Hardware Guide, AECS User's Guide, and AECS Software Guide are authored by MSG. The requirements set forth for AECS are presented in the Statement of Work for the Assessment Environment for Complex Systems authored by NASA Dryden Flight Research Center (DFRC). The intended audience for this document includes software engineers, hardware engineers, project managers, and quality assurance personnel from WVHTC Foundation (the suppliers of the software), NASA (the customer), and future researchers (users of the software). Readers are assumed to have general knowledge in the field of real-time, embedded computer software development.

tests↗

NASA NTRS1982

An automated data management/analysis system for space shuttle orbiter tiles

An engineering data management system was combined with a nonlinear stress analysis program to provide a capability for analyzing a large number of tiles on the space shuttle orbiter. Tile geometry data and all data necessary of define the tile loads environment accessed automatically as needed for the analysis of a particular tile or a set of tiles. User documentation provided includes: (1) description of computer programs and data files contained in the system; (2) definitions of all engineering data stored in the data base; (3) characteristics of the tile anaytical model; (4) instructions for preparation of user input; and (5) a sample problem to illustrate use of the system. Description of data, computer programs, and analytical models of the tile are sufficiently detailed to guide extension of the system to include additional zones of tiles and/or additional types of analyses

Giles, G. L.↗

NASA NTRS1979

Engineering risk reduction in satellite programs

Methods developed in planning and executing system safety engineering programs for Lockheed satellite integration contracts are presented. These procedures establish the applicable safety design criteria, document design compliance and assess the residual risks where non-compliant design is proposed, and provide for hazard analysis of system level test, handling and launch preparations. Operations hazard analysis identifies product protection and product liability hazards prior to the preparation of operational procedures and provides safety requirements for inclusion in them. The method developed for documenting all residual hazards for the attention of program management assures an acceptable minimum level of risk prior to program deployment. The results are significant for persons responsible for managing or engineering the deployment and production of complex high cost equipment under current product liability law and cost/time constraints, have a responsibility to minimize the possibility of an accident, and should have documentation to provide a defense in a product liability suit.

Dean, E. S., Jr.↗