Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “Engineering management”

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

Explanation Constraint Programming for Model-based Diagnosis of Engineered Systems

We can expect to see an increase in the deployment of unmanned air and land vehicles for autonomous exploration of space. In order to maintain autonomous control of such systems, it is essential to track the current state of the system. When the system includes safety-critical components, failures or faults in the system must be diagnosed as quickly as possible, and their effects compensated for so that control and safety are maintained under a variety of fault conditions. The Livingstone fault diagnosis and recovery kernel and its temporal extension L2 are examples of model-based reasoning engines for health management. Livingstone has been shown to be effective, it is in demand, and it is being further developed. It was part of the successful Remote Agent demonstration on Deep Space One in 1999. It has been and is being utilized by several projects involving groups from various NASA centers, including the In Situ Propellant Production (ISPP) simulation at Kennedy Space Center, the X-34 and X-37 experimental reusable launch vehicle missions, Techsat-21, and advanced life support projects. Model-based and consistency-based diagnostic systems like Livingstone work only with discrete and finite domain models. When quantitative and continuous behaviors are involved, these are abstracted to discrete form using some mapping. This mapping from the quantitative domain to the qualitative domain is sometimes very involved and requires the design of highly sophisticated and complex monitors. We propose a diagnostic methodology that deals directly with quantitative models and behaviors, thereby mitigating the need for these sophisticated mappings. Our work brings together ideas from model-based diagnosis systems like Livingstone and concurrent constraint programming concepts. The system uses explanations derived from the propagation of quantitative constraints to generate conflicts. Fast conflict generation algorithms are used to generate and maintain multiple candidates whose consistency can be tracked across multiple time steps.

Narasimhan, Sriram↗
NASA NTRS1998

Aerospace Power Systems Design and Analysis (APSDA) Tool

The conceptual design of space and/or planetary electrical power systems has required considerable effort. Traditionally, in the early stages of the design cycle (conceptual design), the researchers have had to thoroughly study and analyze tradeoffs between system components, hardware architectures, and operating parameters (such as frequencies) to optimize system mass, efficiency, reliability, and cost. This process could take anywhere from several months to several years (as for the former Space Station Freedom), depending on the scale of the system. Although there are many sophisticated commercial software design tools for personal computers (PC's), none of them can support or provide total system design. To meet this need, researchers at the NASA Lewis Research Center cooperated with Professor George Kusic from the University of Pittsburgh to develop a new tool to help project managers and design engineers choose the best system parameters as quickly as possible in the early design stages (in days instead of months). It is called the Aerospace Power Systems Design and Analysis (APSDA) Tool. By using this tool, users can obtain desirable system design and operating parameters such as system weight, electrical distribution efficiency, bus power, and electrical load schedule. With APSDA, a large-scale specific power system was designed in a matter of days. It is an excellent tool to help designers make tradeoffs between system components, hardware architectures, and operation parameters in the early stages of the design cycle. user interface. It operates on any PC running the MS-DOS (Microsoft Corp.) operating system, version 5.0 or later. A color monitor (EGA or VGA) and two-button mouse are required. The APSDA tool was presented at the 30th Intersociety Energy Conversion Engineering Conference (IECEC) and is being beta tested at several NASA centers. Beta test packages are available for evaluation by contacting the author.

Truong, Long V.↗
NASA NTRS2005

Simulant Materials of Lunar Dust: Requirements and feasibility

As NASA turns its exploration ambitions towards the Moon once again, the research and development of new technologies for lunar operations face the challenge of meeting the milestones of a fast-pace schedule, reminiscent of the 1960 s Apollo program. While the lunar samples returned by the Apollo and Luna missions have revealed much about the Moon, these priceless materials exist in too scarce quantities to be used for technology development and testing. The need for mineral materials chosen to simulate the characteristics of lunar regoliths is a pressing issue that must be addressed today through the collaboration of scientists, engineers and program managers. While the larger size fraction of the lunar regolith has been reproduced in several simulants in the past, little attention has been paid to the fines fraction, commonly refered to as lunar dust. As reported by McKay, this fraction of the lunar regolith below 20 microns can represent upto 30% by mass of the total regolith mass. The issue of reproducing the properties of these fines for research and technology development purposes was addressed by the recently held Workshop on Lunar Regolith Simulant Materials at Marshall Space Flight Center. Preliminary conclusions from the workshop and con- side-rations concerning the feasibility of producing such materials will be presented here.

Sibille, L.↗
NASA NTRS2005

STS-114: Discovery Mission Status Briefing

Paul Hill, STS-114 Lead Shuttle Flight Director and Wayne Hale, Space Shuttle Deputy Program Director is shown during this mission status briefing. Hill talks about the first 24 hours of the Space Shuttle Discovery in orbit. He expresses that he has acquired data from the launch through imagery and hand held photographs of the external tank. Hale answers questions from the news media about how the engineers may be managing this data and if there is an overwhelming amount of data. Live downlink television pictures from the end-effectors camera on the Robotic Arm as it has completed its reberthing of the Orbiter Boom Sensor System (OBSS) are shown.

Source record↗
NASA NTRS2006

An Integrated Approach to Exploration Launch Office Requirements Development

The proposed paper will focus on the Project Management and Systems Engineering approach utilized to develop a set of both integrated and cohesive requirements for the Exploration Launch Office, within the Constellation Program. A summary of the programmatic drivers which influenced the approach along with details of the resulting implementation will be discussed as well as metrics evaluating the efficiency and accuracy of the various requirements development activities. Requirements development activities will focus on the procedures utilized to ensure that technical content was valid and mature in preparation for the Crew Launch Vehicle and Constellation System s Requirements Reviews. This discussion will begin at initial requirements development during the Exploration Systems Architecture Study and progress through formal development of the program structure. Specific emphasis will be given to development and validation of the requirements. This discussion will focus on approaches to garner the appropriate requirement owners (or customers), project infrastructure utilized to emphasize proper integration, and finally the procedure to technically mature, verify and validate the requirements. Examples of requirements being implemented on the Launch Vehicle (systems, interfaces, test & verification) will be utilized to demonstrate the various processes and also provide a top level understanding of the launch vehicle(s) performance goals. Details may also be provided on the approaches for verification, which range from typical aerospace hardware development (qualification/acceptance) through flight certification (flight test, etc.). The primary intent of this paper is to provide a demonstrated procedure for the development of a mature, effective, integrated set of requirements on a complex system, which also has the added intricacies of both heritage and new hardware development integration. Ancillary focus of the paper will include discussion of Test and Verification approaches along with top level systems/elements performance capabilities.

Holladay, Jon B.↗
NASA NTRS2007

Guide for Oxygen Compatibility Assessments on Oxygen Components and Systems

Understanding and preventing fire hazards is necessary when designing, maintaining, and operating oxygen systems. Ignition risks can be minimized by controlling heat sources and using materials that will not ignite or will not support burning in the end-use environment. Because certain materials are more susceptible to ignition in oxygen-enriched environments, a compatibility assessment should be performed before the component is introduced into an oxygen system. This document provides an overview of oxygen fire hazards and procedures that are consistent with the latest versions of American Society for Testing and Materials (ASTM) Standards G63 (1999) and G94 (2005) to address fire hazards associated with oxygen systems. This document supersedes the previous edition, NASA Technical Memorandum 104823, Guide for Oxygen Hazards Analyses on Components and Systems (1996). The step-by-step oxygen compatibility assessment method described herein (see Section 4) enables oxygen-system designers, system engineers, and facility managers to determine areas of concern with respect to oxygen compatibility and, ultimately, prevent damage to a system or injury to personnel.

Rosales, Keisa R.↗
NASA NTRS2010

Risk-Informed Decision Making: Application to Technology Development Alternative Selection

NASA NPR 8000.4A, Agency Risk Management Procedural Requirements, defines risk management in terms of two complementary processes: Risk-informed Decision Making (RIDM) and Continuous Risk Management (CRM). The RIDM process is used to inform decision making by emphasizing proper use of risk analysis to make decisions that impact all mission execution domains (e.g., safety, technical, cost, and schedule) for program/projects and mission support organizations. The RIDM process supports the selection of an alternative prior to program commitment. The CRM process is used to manage risk associated with the implementation of the selected alternative. The two processes work together to foster proactive risk management at NASA. The Office of Safety and Mission Assurance at NASA Headquarters has developed a technical handbook to provide guidance for implementing the RIDM process in the context of NASA risk management and systems engineering. This paper summarizes the key concepts and procedures of the RIDM process as presented in the handbook, and also illustrates how the RIDM process can be applied to the selection of technology investments as NASA's new technology development programs are initiated.

Dezfuli, Homayoon↗
NASA NTRS2010

Exploration Life Support Critical Questions for Future Human Space Missions

Exploration Life Support (ELS) is a current project under NASA's Exploration Systems Mission Directorate. The ELS Project plans, coordinates and implements the development of advanced life support technologies for human exploration missions in space. Recent work has focused on closed loop atmosphere and water systems for long duration missions, including habitats and pressurized rovers. But, what are the critical questions facing life support system developers for these and other future human missions? This paper explores those questions and how progress in the development of ELS technologies can help answer them. The ELS Project includes the following Elements: Atmosphere Revitalization Systems, Water Recovery Systems, Waste Management Systems, Habitation Engineering, Systems Integration, Modeling and Analysis, and Validation and Testing, which includes the Sub-Elements Flight Experiments and Integrated Testing. Systems engineering analysis by ELS seeks to optimize overall mission architectures by considering all the internal and external interfaces of the life support system and the potential for reduction or reuse of commodities. In particular, various sources and sinks of water and oxygen are considered along with the implications on loop closure and the resulting launch mass requirements. Systems analysis will be validated through the data gathered from integrated testing, which will demonstrate the interfaces of a closed loop life support system. By applying a systematic process for defining, sorting and answering critical life support questions, the ELS project is preparing for a variety of future human space missions

Kwert, Michael K.↗
NASA NTRS2010

Verification and Implementation of Operations Safety Controls for Flight Missions

Approximately eleven years ago, the International Space Station launched the first module from Russia, the Functional Cargo Block (FGB). Safety and Mission Assurance (S&MA) Operations (Ops) Engineers played an integral part in that endeavor by executing strict flight product verification as well as continued staffing of S&MA's console in the Mission Evaluation Room (MER) for that flight mission. How were these engineers able to conduct such a complicated task? They conducted it based on product verification that consisted of ensuring that safety requirements were adequately contained in all flight products that affected crew safety. S&MA Ops engineers apply both systems engineering and project management principles in order to gain a appropriate level of technical knowledge necessary to perform thorough reviews which cover the subsystem(s) affected. They also ensured that mission priorities were carried out with a great detail and success.

Jones, Cheryl L.↗
NASA NTRS2010

Feasibility Study of Commercial Markets for New Sample Acquisition Devices

The NASA Exploration Systems Mission Directorate (ESMD) and Penn State technology commercialization project was designed to assist in the maturation of a NASA SBIR Phase III technology. The project was funded by NASA's ESMD Education group with oversight from the Surface Systems Office at NASA Kennedy Space Center in the Engineering Directorate. Two Penn State engineering student interns managed the project with support from Honeybee Robotics and NASA Kennedy Space Center. The objective was to find an opportunity to integrate SBIR-developed Regolith Extractor and Sampling Technology as the payload for the future Lunar Lander or Rover missions. The team was able to identify two potential Google Lunar X Prize organizations with considerable interest in utilizing regolith acquisition and transfer technology.

Brady, Collin↗
NASA NTRS2010

From Research to Flight: Thinking About Implementation While Performing Fundamental Research

This slide presentation calls for a strategy to implement new technologies. Such a strategy would allow advanced space transportation technologies to mature for exploration beyond Earth orbit. It discusses the difference between technology push versus technology pull. It also reviews the three basic technology readiness levels (TRL). The presentation traces examples of technology development to flight application: the Space Shuttle Main Engine Advanced Health Management System, the Friction Stir Welding technology the (auto-adjustable pin tool). A couple of technologies currently not in flight, but are being reviewed for potential use are: cryogenic fluid management (CFM), and solar sail propulsion. There is also an attempt to explain why new technologies are so difficult to field.

Johnson, Les↗
NASA NTRS2013

Development of Hybrid Product Breakdown Structure for NASA Ground Systems

The Product Breakdown Structure is traditionally a method of identification of the products of a project in a tree structure. It is a tool used to assess, plan, document, and display the equipment requirements for a project. It is part of a product based planning technique, and attempts to break down all components of a project in as much detail as possible, so that nothing is overlooked. The PBS for ground systems at the Kennedy Space Center is being developed to encompass the traditional requirements including the alignment of facility, systems, and components to the organizational hierarchy. The Ground Operations Product Breakdown Structure is a hybrid in nature in that some aspects of a work breakdown structure will be incorporated and merged with the Architecture Concept of Operations, Master Subsystem List, customer interface, and assigned management responsibility. The Ground Operations Product Breakdown Structure needs to be able to identify the flexibility of support differing customers (internal and external) usage of ground support equipment within the Kennedy Space Center launch and processing complex. The development of the Product Breakdown Structure is an iterative activity Initially documenting the organization hierarchy structure and relationships. The Product Breakdown Structure identifies the linkage between the customer program requirements, allocation of system resources, development of design goals, and identification logistics products. As the Product Breakdown Structure progresses the incorporation of the results of requirement planning for the customer occurs identifying facility needs and systems. The mature Product Breakdown Structure is baselined with a hierarchical drawing, the Product Breakdown Structure database, and an associated document identifying the verification of the data through the life cycle of the program/product line. This paper will document, demonstrate, and identify key aspects of the life cycle of a Hybrid Product Breakdown Structure. The purpose is to show how a project management and system engineering approach can be utilized for providing flexible customer service in an evolving manned space flight launch processing environment.

Monaghan, Mark W.↗
NASA NTRS2007

Software Safety Risk in Legacy Safety-Critical Computer Systems

Safety Standards contain technical and process-oriented safety requirements. Technical requirements are those such as "must work" and "must not work" functions in the system. Process-Oriented requirements are software engineering and safety management process requirements. Address the system perspective and some cover just software in the system > NASA-STD-8719.13B Software Safety Standard is the current standard of interest. NASA programs/projects will have their own set of safety requirements derived from the standard. Safety Cases: a) Documented demonstration that a system complies with the specified safety requirements. b) Evidence is gathered on the integrity of the system and put forward as an argued case. [Gardener (ed.)] c) Problems occur when trying to meet safety standards, and thus make retrospective safety cases, in legacy safety-critical computer systems.

Hill, Janice L.↗
NASA NTRS2013

Development of Hybrid Product Breakdown Structure for NASA Ground Systems

The Product Breakdown Structure is traditionally a method of identification of the products of a project in a tree structure. It is a tool used to assess, plan, document, and display the equipment requirements for a project. It is part of a product based planning technique, and attempts to break down all components of a project in as much detail as possible, so that nothing is overlooked. The PBS for ground systems at the Kennedy Space Center is being developed to encompass the traditional requirements including the alignment of facility, systems, and components to the organizational hierarchy. The Ground Operations Product Breakdown Structure is a hybrid in nature in that some aspects of a work breakdown structure will be incorporated and merged with the Architecture Concept of Operations, Master Subsystem List, customer interface, and assigned management responsibility. The Ground Operations Product Breakdown Structure needs to be able to identify the flexibility of support differing customers (internal and external) usage of ground support equipment within the Kennedy Space Center launch and processing complex. The development of the Product Breakdown Structure is an iterative activity Initially documenting the organization hierarchy structure and relationships. The Product Breakdown Structure identifies the linkage between the customer program requirements, allocation of system resources, development of design goals, and identification logistics products. As the Product Breakdown Structure progresses the incorporation of the results of requirement planning for the customer occurs identifying facility needs and systems. The mature Product Breakdown Structure is baselined with a hierarchical drawing, the Product Breakdown Structure database, and an associated document identifying the verification of the data through the life cycle of the program/product line. This paper will document, demonstrate, and identify key aspects of the life cycle of a Hybrid Product Breakdown Structure. The purpose is to show how a project management and system engineering approach can be utilized for providing flexible customer service in an evolving manned space flight launch processing environment.

Monaghan, Mark W.↗
NASA NTRS2013

Implementation of a Goal-Based Systems Engineering Process Using the Systems Modeling Language (SysML)

This paper describes the core framework used to implement a Goal-Function Tree (GFT) based systems engineering process using the Systems Modeling Language. It defines a set of principles built upon by the theoretical approach described in the InfoTech 2013 ISHM paper titled "Goal-Function Tree Modeling for Systems Engineering and Fault Management" presented by Dr. Stephen B. Johnson. Using the SysML language, the principles in this paper describe the expansion of the SysML language as a baseline in order to: hierarchically describe a system, describe that system functionally within success space, and allocate detection mechanisms to success functions for system protection.

Breckenridge, Jonathan T.↗
NASA NTRS2010

A Discussion of the Software Quality Assurance Role

The basic idea underlying this paper is that the conventional understanding of the role of a Software Quality Assurance (SQA) engineer is unduly limited. This is because few have asked who the customers of a SQA engineer are. Once you do this, you can better define what tasks a SQA engineer should perform, as well as identify the knowledge and skills that such a person should have. The consequence of doing this is that a SQA engineer can provide greater value to his or her customers. It is the position of this paper that a SQA engineer providing significant value to his or her customers must not only assume the role of an auditor, but also that of a software and systems engineer. This is because software engineers and their managers particularly value contributions that directly impact products and their development. These ideas are summarized as lessons learned, based on my experience at Jet Propulsion Laboratory (JPL).

experience↗