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 73 records · Page 4
All sourcesNASA NTRSDOE OSTI
NASA NTRS2000

Advanced Engine Health Management Applications of the SSME Real-Time Vibration Monitoring System

The Real Time Vibration Monitoring System (RTVMS) is a 32-channel high speed vibration data acquisition and processing system developed at Marshall Space Flight Center (MSFC). It Delivers sample rates as high as 51,200 samples/second per channel and performs Fast Fourier Transform (FFT) processing via on-board digital signal processing (DSP) chips in a real-time format. Advanced engine health assessment is achieved by utilizing the vibration spectra to provide accurate sensor validation and enhanced engine vibration redlines. Discrete spectral signatures (such as synchronous) that are indicators of imminent failure can be assessed and utilized to mitigate catastrophic engine failures- a first in rocket engine health assessment. This paper is presented in viewgraph form.

Fiorucci, Tony R.↗
NASA NTRS1991

Concepts, requirements, and design approaches for building successful planning and scheduling systems

Traditional practice of systems engineering management assumes requirements can be precisely determined and unambiguously defined prior to system design and implementation; practice further assumes requirements are held static during implementation. Human-computer decision support systems for service planning and scheduling applications do not conform well to these assumptions. Adaptation to the traditional practice of systems engineering management are required. Basic technology exists to support these adaptations. Additional innovations must be encouraged and nutured. Continued partnership between the programmatic and technical perspective assures proper balance of the impossible with the possible. Past problems have the following origins: not recognizing the unusual and perverse nature of the requirements for planning and scheduling; not recognizing the best starting point assumptions for the design; not understanding the type of system that being built; and not understanding the design consequences of the operations concept selected.

Hornstein, Rhoda Shaller↗
NASA NTRS1990

Space Station Freedom - Configuration management approach to supporting concurrent engineering and total quality management

Some experiences of NASA configuration management in providing concurrent engineering support to the Space Station Freedom program for the achievement of life cycle benefits and total quality are discussed. Three change decision experiences involving tracing requirements and automated information systems of the electrical power system are described. The potential benefits of concurrent engineering and total quality management include improved operational effectiveness, reduced logistics and support requirements, prevention of schedule slippages, and life cycle cost savings. It is shown how configuration management can influence the benefits attained through disciplined approaches and innovations that compel consideration of all the technical elements of engineering and quality factors that apply to the program development, transition to operations and in operations. Configuration management experiences involving the Space Station program's tiered management structure, the work package contractors, international partners, and the participating NASA centers are discussed.

Gavert, Raymond B.↗
NASA NTRS1972

Transformation of scientists and engineers into managers

The purposes of this research were to determine the principal problems and obstacles faced by specialists during the transition period when they are becoming managers, and to discover ways by which their difficulties might be avoided or overcome. It was found that senior management officials are unaware--or tend to ignore the importance--of the transition process and its problems, that little attention has been given to developing management training to overcome transition problems, and that much of the training which is offered is largely irrelevant to these problems.

Bayton, J. A.↗
NASA NTRS2007

Fundamental Technology Development for Gas-Turbine Engine Health Management

Integrated vehicle health management technologies promise to dramatically improve the safety of commercial aircraft by reducing system and component failures as causal and contributing factors in aircraft accidents. To realize this promise, fundamental technology development is needed to produce reliable health management components. These components include diagnostic and prognostic algorithms, physics-based and data-driven lifing and failure models, sensors, and a sensor infrastructure including wireless communications, power scavenging, and electronics. In addition, system assessment methods are needed to effectively prioritize development efforts. Development work is needed throughout the vehicle, but particular challenges are presented by the hot, rotating environment of the propulsion system. This presentation describes current work in the field of health management technologies for propulsion systems for commercial aviation.

Mercer, Carolyn R.↗
NASA NTRS2019

A Meteoroid Handbook for Aerospace Engineers and Managers

At the beginning of the Space Age, spacecraft designers and mission planners were very concerned about meteoroids. They envisioned vehicles being ripped to pieces by streams of fast-moving space rocks, a notion promoted by the science fiction novels and movies of the time. The reality is, of course, different—the meteoroid streams that produce meteor showers are not dense by laypeople’s standards, having spatial densities of just a handful of particles per cubic kilometer, even during meteor outbursts. The ever-present, diffuse, sporadic background, which produces observed meteor rates of only 5 to 8 meteors per hour, makes up 90% of the meteoroid risk to spacecraft that spend at least a year in low Earth orbit (LEO), whereas the visually spectacular but short-lived meteor showers make up the other 10%. Still, meteoroids do pose a significant risk to spacecraft. At Earth, they can travel 12 to 72 km/s. These high speeds cause even small meteoroids to carry enormous kinetic energy, making them capable of doing serious damage to spacecraft. For example, a 1-mm-diameter meteoroid moving at 25 km/s can inflict the same damage as a bullet fired from a 0.357 Magnum pistol. An exterior wire can be severed by a 0.1-mm (100 mm) particle, a spacesuit can be penetrated by a 0.5-mm meteoroid, and an unshielded pressure wall (like the cabin of the Space Shuttle) can be perforated by centimeter-sized particles. Along with mechanical damage, meteoroids can also cause other types of spacecraft anomalies. Meteoroids can transfer their momentum to the spacecraft, which can destroy or damage equipment such as shunt resistors and charge-coupled device (CCD) detectors with a clear view of space. Meteoroid impacts can also generate plasma. The impact vaporizes material, producing a crater and an expanding plasma, which can in turn provide a conductive path for any charge accumulated on the spacecraft. This effect is thought to be responsible for the demise of a satellite in one case: the OLYMPUS communications satellite was sent tumbling out of control during the 1993 Perseid outburst, and a Perseid meteoroid strike has been posited as a possible cause (McDonnell et al. 1993; Caswell et al. 1995). Other researchers have suggested that very fast meteoroids could produce a small electromagnetic pulse capable of disrupting spacecraft function (Close et al. 2010).

Moorhead, A.↗
NASA NTRSDate not supplied

Lessons Learned With Risk Management: A Systems Engineer’s Perspective

Risk management is a communications device that, when executed as an essential task, enables systems engineering to effectively balance risk across the project. Developing and baselining risks is an essential continuous task to ensure top project concerns both from bottom up and top down are being mitigated. Risk management provides the opportunity to avoid the consequence of the risk when mitigation steps start early enough. Just discussing risk with all the project flight elements during development, even if no risks are open, provides an excellent communication opportunity between systems engineering and those elements, ensuring concerns and worries have a platform for discussion. A well-managed risk identification process will identify concerns that are serious but not being clearly communicated, and it will enable mitigation of those potential problems before they cause a failure. Effective risk management requires considerable time and effort, but that effort will save time and money across the development. Risk management must be frequent enough to be useful and in depth enough to bring out emerging issues. It also requires a trusting relationship between the lead systems engineer and element and/or subsystem leads. The discussions need to be with the right number of individuals (typically a handful) and the right duration in time (typically an hour a month). Outside of these risk working groups, there is a formal management process to input, status, and disposition risks, and a monthly Risk Management Board meeting where key project stakeholders are informed. This paper provides good guidance on effective risk management from a systems engineering perspective and provides project lessons learned from the NASA spaceflight missions NICER, Landsat 9, LRO, and OSIRIS-REx to demonstrate the effectiveness of risk management.

Lessons Learned↗
NASA NTRSDate not supplied

Lessons Learned With Risk Management: A Systems Engineer's Perspective

Risk management is a communications device that, when executed as an essential task, enables systems engineering to effectively balance risk across the project. Developing and baselining risks is an essential continuous task to ensure top project concerns both from bottom up and top down are being mitigated. Risk management provides the opportunity to avoid the consequence of the risk when mitigation steps start early enough. Just discussing risk with all the project flight elements during development, even if no risks are open, provides an excellent communication opportunity between systems engineering and those elements, ensuring concerns and worries have a platform for discussion. A well-managed risk identification process will identify concerns that are serious but not being clearly communicated, and it will enable mitigation of those potential problems before they cause a failure. Effective risk management requires considerable time and effort, but that effort will save time and money across the development. Risk management must be frequent enough to be useful and in depth enough to bring out emerging issues. It also requires a trusting relationship between the lead systems engineer and element and/or subsystem leads. The discussions need to be with the right number of individuals (typically a handful) and the right duration in time (typically an hour a month). Outside of these risk working groups, there is a formal management process to input, status, and disposition risks, and a monthly Risk Management Board meeting where key project stakeholders are informed. This paper provides good guidance on effective risk management from a systems engineering perspective and provides project lessons learned from the NASA spaceflight missions NICER, Landsat 9, LRO, and OSIRIS-REx to demonstrate the effectiveness of risk management.

Lessons Learned↗
NASA NTRS1974

Apollo experience report: Data management for postflight engineering evaluation

The Apollo management of data for postflight engineering evaluation is described. The sources of Apollo telemetry data, the control of data processing by a single data team, the data techniques used to assist in evaluation of the large quantity of data, and the operation of the data team before the mission and during the evaluation phase are described. The techniques used to ensure the output of valid data and to determine areas in which data were of questionable quality are also included.

Foster, G. B., Jr.↗
NASA NTRS2005

A Management Model for International Participation in Space Exploration Missions

This paper proposes an engineering management model for NASA's future space exploration missions based on past experiences working with the International Partners of the International Space Station. The authors have over 25 years of combined experience working with the European Space Agency, Japan Aerospace Exploration Agency, Canadian Space Agency, Italian Space Agency, Russian Space Agency, and their respective contractors in the design, manufacturing, verification, and integration of their elements electric power system into the United States on-orbit segment. The perspective presented is one from a specific sub-system integration role and is offered so that the lessons learned from solving issues of technical and cultural nature may be taken into account during the formulation of international partnerships. Descriptions of the types of unique problems encountered relative to interactions between international partnerships are reviewed. Solutions to the problems are offered, taking into consideration the technical implications. Through the process of investigating each solution, the important and significant issues associated with working with international engineers and managers are outlined. Potential solutions are then characterized by proposing a set of specific methodologies to jointly develop spacecraft configurations that benefits all international participants, maximizes mission success and vehicle interoperability while minimizing cost.

George, Patrick J.↗
NASA NTRS1991

NASA software documentation standard software engineering program

The NASA Software Documentation Standard (hereinafter referred to as Standard) can be applied to the documentation of all NASA software. This Standard is limited to documentation format and content requirements. It does not mandate specific management, engineering, or assurance standards or techniques. This Standard defines the format and content of documentation for software acquisition, development, and sustaining engineering. Format requirements address where information shall be recorded and content requirements address what information shall be recorded. This Standard provides a framework to allow consistency of documentation across NASA and visibility into the completeness of project documentation. This basic framework consists of four major sections (or volumes). The Management Plan contains all planning and business aspects of a software project, including engineering and assurance planning. The Product Specification contains all technical engineering information, including software requirements and design. The Assurance and Test Procedures contains all technical assurance information, including Test, Quality Assurance (QA), and Verification and Validation (V&V). The Management, Engineering, and Assurance Reports is the library and/or listing of all project reports.

Source record↗