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 199 records · Page 11
All sourcesNASA NTRSDOE OSTI
NASA NTRS2012

Model-Based Systems Engineering Approach to Managing Mass Margin

When designing a flight system from concept through implementation, one of the fundamental systems engineering tasks ismanaging the mass margin and a mass equipment list (MEL) of the flight system. While generating a MEL and computing a mass margin is conceptually a trivial task, maintaining consistent and correct MELs and mass margins can be challenging due to the current practices of maintaining duplicate information in various forms, such as diagrams and tables, and in various media, such as files and emails. We have overcome this challenge through a model-based systems engineering (MBSE) approach within which we allow only a single-source-of-truth. In this paper we describe the modeling patternsused to capture the single-source-of-truth and the views that have been developed for the Europa Habitability Mission (EHM) project, a mission concept study, at the Jet Propulsion Laboratory (JPL).

cloud comu↗
NASA NTRS2011

A History of Space Shuttle Main Engine (SSME) Redline Limits Management

The Space Shuttle Main Engine (SSME) has several "redlines", which are operational limits designated to preclude a catastrophic shutdown of the SSME. The Space Shuttle Orbiter utilizes a combination of hardware and software to enable or disable the automated redline shutdown capability. The Space Shuttle is launched with the automated SSME redline limits enabled, but there are many scenarios which may result in the manual disabling of the software by the onboard crew. The operational philosophy for manually enabling and disabling the redline limits software has evolved continuously throughout the history of the Space Shuttle Program, due to events such as SSME hardware changes and updates to Space Shuttle contingency abort software. In this paper, the evolution of SSME redline limits management will be fully reviewed, including the operational scenarios which call for manual intervention, and the events that triggered changes to the philosophy. Following this review, improvements to the management of redline limits for future spacecraft will be proposed.

Arnold, Thomas M.↗
NASA NTRS2006

Knowledge management in the engineering design environment

The Aerospace and Defense industry is experiencing an increasing loss of knowledge through workforce reductions associated with business consolidation and retirement of senior personnel. Significant effort is being placed on process definition as part of ISO certification and, more recently, CMMI certification. The process knowledge in these efforts represents the simplest of engineering knowledge and many organizations are trying to get senior engineers to write more significant guidelines, best practices and design manuals. A new generation of design software, known as Product Lifecycle Management systems, has many mechanisms for capturing and deploying a wider variety of engineering knowledge than simple process definitions. These hold the promise of significant improvements through reuse of prior designs, codification of practices in workflows, and placement of detailed how-tos at the point of application.

designs↗
NASA NTRS1994

Reusable Rocket Engine Turbopump Health Management System

A health monitoring expert system software architecture has been developed to support condition-based health monitoring of rocket engines. Its first application is in the diagnosis decisions relating to the health of the high pressure oxidizer turbopump (HPOTP) of Space Shuttle Main Engine (SSME). The post test diagnostic system runs off-line, using as input the data recorded from hundreds of sensors, each running typically at rates of 25, 50, or .1 Hz. The system is invoked after a test has been completed, and produces an analysis and an organized graphical presentation of the data with important effects highlighted. The overall expert system architecture has been developed and documented so that expert modules analyzing other line replaceable units may easily be added. The architecture emphasizes modularity, reusability, and open system interfaces so that it may be used to analyze other engines as well.

Surko, Pamela↗
NASA NTRS2005

Hybrid Power Management

An engineering discipline denoted as hybrid power management (HPM) has emerged from continuing efforts to increase energy efficiency and reliability of hybrid power systems. HPM is oriented toward integration of diverse electric energy-generating, energy-storing, and energy-consuming devices in optimal configurations for both terrestrial and outer-space applications. The basic concepts of HPM are potentially applicable at power levels ranging from nanowatts to megawatts. Potential applications include terrestrial power-generation, terrestrial transportation, biotechnology, and outer-space power systems. Instances of this discipline at prior stages of development were reported (though not explicitly labeled as HPM) in three prior NASA Tech Briefs articles: "Ultracapacitors Store Energy in a Hybrid Electric Vehicle"(LEW-16876), Vol. 24, No. 4 (April 2000), page 63; "Photovoltaic Power Station With Ultracapacitors for Storage" (LEW-17177), Vol. 27, No. 8 (August 2003), page 38; and "Flasher Powered by Photovoltaic Cells and Ultracapacitors" (LEW-17246), Vol. 24, No. 10 (October 2003), page 37. As the titles of the cited articles indicate, the use of ultracapacitors as energy-storage devices lies at the heart of HPM. An ultracapacitor is an electrochemical energy-storage device, but unlike in a conventional rechargeable electrochemical cell or battery, chemical reactions do not take place during operation. Instead, energy is stored electrostatically at an electrode/electrolyte interface. The capacitance per unit volume of an ultracapacitor is much greater than that of a conventional capacitor because its electrodes have much greater surface area per unit volume and the separation between the electrodes is much smaller. Power-control circuits for ultracapacitors can be simpler than those for batteries, for two reasons: (1) Because of the absence of chemical reactions, charge and discharge currents can be greater than those in batteries, limited only by the electrical resistances of conductors; and (2) whereas the charge level of a battery depends on voltage, temperature, age, and load condition, the charge level of an ultracapacitor, like that of a conventional capacitor, depends only on voltage.

Eichenberg, Dennis↗
NASA NTRS1993

Repository-Based Software Engineering Program: Working Program Management Plan

Repository-Based Software Engineering Program (RBSE) is a National Aeronautics and Space Administration (NASA) sponsored program dedicated to introducing and supporting common, effective approaches to software engineering practices. The process of conceiving, designing, building, and maintaining software systems by using existing software assets that are stored in a specialized operational reuse library or repository, accessible to system designers, is the foundation of the program. In addition to operating a software repository, RBSE promotes (1) software engineering technology transfer, (2) academic and instructional support of reuse programs, (3) the use of common software engineering standards and practices, (4) software reuse technology research, and (5) interoperability between reuse libraries. This Program Management Plan (PMP) is intended to communicate program goals and objectives, describe major work areas, and define a management report and control process. This process will assist the Program Manager, University of Houston at Clear Lake (UHCL) in tracking work progress and describing major program activities to NASA management. The goal of this PMP is to make managing the RBSE program a relatively easy process that improves the work of all team members. The PMP describes work areas addressed and work efforts being accomplished by the program; however, it is not intended as a complete description of the program. Its focus is on providing management tools and management processes for monitoring, evaluating, and administering the program; and it includes schedules for charting milestones and deliveries of program products. The PMP was developed by soliciting and obtaining guidance from appropriate program participants, analyzing program management guidance, and reviewing related program management documents.

Source record↗
NASA NTRS1993

Software Engineering Guidebook

The Software Engineering Guidebook describes SEPG (Software Engineering Process Group) supported processes and techniques for engineering quality software in NASA environments. Three process models are supported: structured, object-oriented, and evolutionary rapid-prototyping. The guidebook covers software life-cycles, engineering, assurance, and configuration management. The guidebook is written for managers and engineers who manage, develop, enhance, and/or maintain software under the Computer Software Services Contract.

Connell, John↗
NASA NTRS1993

Spacecraft systems engineering: An introduction to the process at GSFC

The main objective in systems engineering is to devise a coherent total system design capable of achieving the stated requirements. Requirements should be rigid. However, they should be continuously challenged, rechallenged and/or validated. The systems engineer must specify every requirement in order to design, document, implement and conduct the mission. Each and every requirement must be logically considered, traceable and evaluated through various analysis and trade studies in a total systems design. Margins must be determined to be realistic as well as adequate. The systems engineer must also continuously close the loop and verify system performance against the requirements. The fundamental role of the systems engineer, however, is to engineer, not manage. Yet, in large, complex missions, where more than one systems engineer is required, someone needs to manage the systems engineers, and we call them 'systems managers.' Systems engineering management is an overview function which plans, guides, monitors and controls the technical execution of a project as implemented by the systems engineers. As the project moves on through Phases A and B into Phase C/D, the systems engineering tasks become a small portion of the total effort. The systems management role increases since discipline subsystem engineers are conducting analyses and reviewing test data for final review and acceptance by the systems managers.

Fragomeni, Tony↗
NASA NTRS2004

Concurrent Engineering for the Management of Research and Development

The Management of Research and Development (R&D) is facing the challenges of reducing time from R&D to customer, reducing the cost of R&D, having higher accountability for results (improved quality), and increasing focus on customers. Concurrent engineering (CE) has shown great success in the automotive and technology industries resulting in significant decreases in cycle time, reduction of total cost, and increases in quality and reliability. This philosophy of concurrency can have similar implications or benefits for the management of R&D organizations. Since most studies on the application of CE have been performed in manufacturing environments, research into the benefits of CE into other environments is needed. This paper presents research conducted at the NASA Glenn Research Center (GRC) investigating the application of CE in the management of an R&D organization. In particular the paper emphasizes possible barriers and enhancers that this environment presents to the successful implementation of CE. Preliminary results and recommendations are based on a series of interviews and subsequent surveys, from which data has been gathered and analyzed as part of the GRC's Continuous Improvement Process.

DelRosario, Ruben↗
NASA NTRS1990

Concurrent engineering design and management knowledge capture

The topics are presented in viewgraph form and include the following: real-time management, personnel management, project management, conceptual design and decision making; the SITRF design problem; and the electronic-design notebook.

Source record↗
NASA NTRS1994

Software engineering and data management for automated payload experiment tool

The Microgravity Projects Office identified a need to develop a software package that will lead experiment developers through the development planning process, obtain necessary information, establish an electronic data exchange avenue, and allow easier manipulation/reformatting of the collected information. An MS-DOS compatible software package called the Automated Payload Experiment Tool (APET) has been developed and delivered. The objective of this task is to expand on the results of the APET work previously performed by UAH and provide versions of the software in a Macintosh and Windows compatible format.

Maddux, Gary A.↗
NASA NTRS1994

Software engineering and data management for automated payload experiment tool

The Microgravity Projects Office identified a need to develop a software package that will lead experiment developers through the development planning process, obtain necessary information, establish an electronic data exchange avenue, and allow easier manipulation/reformatting of the collected information. An MS-DOS compatible software package called the Automated Payload Experiment Tool (APET) has been developed and delivered. The objective of this task is to expand on the results of the APET work previously performed by University of Alabama in Huntsville (UAH) and provide versions of the software in a Macintosh and Windows compatible format. Appendix 1 science requirements document (SRD) Users Manual is attached.

Maddux, Gary A.↗
NASA NTRS2008

Development of a NASA Integrated Technical Workforce Career Development Model Entitled Requisite Occupation Competencies and Knowledge -- the ROCK

This paper shares the findings of NASA's Integrated Learning and Development Program (ILDP) in its effort to reinvigorate the HANDS-ON practice of space systems engineering and project/program management through focused coursework, training opportunities, on-the job learning and special assignments. Prior to March 2005, NASA responsibility for technical workforce development (the program/project manager, systems engineering, discipline engineering, discipline engineering and associated communities) was executed by two parallel organizations. In March 2005 these organizations merged. The resulting program-ILDP-was chartered to implement an integrated competency-based development model capable of enhancing NASA's technical workforce performance as they face the complex challenges of Earth science, space science, aeronautics and human spaceflight missions. Results developed in collaboration with NASA Field Centers are reported on. This work led to definition of the agency's first integrated technical workforce development model known as the Requisite Occupation Competence and Knowledge (the ROCK). Critical processes and products are presented including: 'validation' techniques to guide model development, the Design-A-CUrriculuM (DACUM) process, and creation of the agency's first systems engineering body-of-knowledge. Findings were validated via nine focus groups from industry and government, validated with over 17 space-related organizations, at an estimated cost exceeding $300,000 (US). Masters-level programs and training programs have evolved to address the needs of these practitioner communities based upon these results. The ROCK reintroduced rigor and depth to the practitioner's development in these critical disciplines enabling their ability to take mission concepts from imagination to reality.

Menrad, Robert J.↗
NASA NTRS2011

IT Project Management and Systems Engineering Internship

In the summer of 2009 I had the privilege of participating in the NASA INSPIRE program and during the summer of 2010 I was hired by ASRC Aerospace, a NASA contractor on the USTDC contract, as an Engineering Aide. These experiences combined inspired me to pursue a career in engineering and a goal to work as a NASA engineer and astronaut.

Cardamone, Lauren↗
NASA NTRS2011

NASA Planning for Orion Multi-Purpose Crew Vehicle Ground Operations

The NASA Orion Ground Processing Team was originally formed by the Kennedy Space Center (KSC) Constellation (Cx) Project Office's Orion Division to define, refine and mature pre-launch and post-landing ground operations for the Orion human spacecraft. The multidisciplined KSC Orion team consisted of KSC civil servant, SAIC, Productivity Apex, Inc. and Boeing-CAPPS engineers, project managers and safety engineers, as well as engineers from Constellation's Orion Project and Lockheed Martin Orion Prime contractor. The team evaluated the Orion design configurations as the spacecraft concept matured between Systems Design Review (SDR), Systems Requirement Review (SRR) and Preliminary Design Review (PDR). The team functionally decomposed prelaunch and post-landing steps at three levels' of detail, or tiers, beginning with functional flow block diagrams (FFBDs). The third tier FFBDs were used to build logic networks and nominal timelines. Orion ground support equipment (GSE) was identified and mapped to each step. This information was subsequently used in developing lower level operations steps in a Ground Operations Planning Document PDR product. Subject matter experts for each spacecraft and GSE subsystem were used to define 5th - 95th percentile processing times for each FFBD step, using the Delphi Method. Discrete event simulations used this information and the logic network to provide processing timeline confidence intervals for launch rate assessments. The team also used the capabilities of the KSC Visualization Lab, the FFBDs and knowledge of the spacecraft, GSE and facilities to build visualizations of Orion pre-launch and postlanding processing at KSC. Visualizations were a powerful tool for communicating planned operations within the KSC community (i.e., Ground Systems design team), and externally to the Orion Project, Lockheed Martin spacecraft designers and other Constellation Program stakeholders during the SRR to PDR timeframe. Other operations planning tools included Kaizen/Lean events, mockups and human factors analysis. The majority of products developed by this team are applicable as KSC prepares 21st Century Ground Systems for the Orion Multi-Purpose Crew Vehicle and Space Launch System.

Letchworth, Gary↗
NASA NTRS2013

Goal-Function Tree Modeling for Systems Engineering and Fault Management

This paper describes a new representation that enables rigorous definition and decomposition of both nominal and off-nominal system goals and functions: the Goal-Function Tree (GFT). GFTs extend the concept and process of functional decomposition, utilizing state variables as a key mechanism to ensure physical and logical consistency and completeness of the decomposition of goals (requirements) and functions, and enabling full and complete traceabilitiy to the design. The GFT also provides for means to define and represent off-nominal goals and functions that are activated when the system's nominal goals are not met. The physical accuracy of the GFT, and its ability to represent both nominal and off-nominal goals enable the GFT to be used for various analyses of the system, including assessments of the completeness and traceability of system goals and functions, the coverage of fault management failure detections, and definition of system failure scenarios.

Johnson, Stephen B.↗