Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “Process engineering”

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 1,657 records · Page 92
All sourcesNASA NTRSDOE OSTI
NASA NTRS2006

Application of State Analysis and Goal-Based Operations to a MER Mission Scenario

State Analysis is a model-based systems engineering methodology employing a rigorous discovery process which articulates operations concepts and operability needs as an integrated part of system design. The process produces requirements on system and software design in the form of explicit models which describe the behavior of states and the relationships among them. By applying State Analysis to an actual MER flight mission scenario, this study addresses the specific real world challenges of complex space operations and explores technologies that can be brought to bear on future missions. The paper describes the tools currently used on a daily basis for MER operations planning and provides an in-depth description of the planning process, in the context of a Martian day's worth of rover engineering activities, resource modeling, flight rules, science observations, and more. It then describes how State Analysis allows for the specification of a corresponding goal-based sequence that accomplishes the same objectives, with several important additional benefits.

mission planning↗
NASA NTRS2007

Progress in Technology Validation of the Next Ion Propulsion System

The NASA's Evolutionary Xenon Thruster (NEXT) ion propulsion system has been in advanced technology development under the NASA In-Space Propulsion Technology project. The highest fidelity hardware planned has now been completed by the government/industry team, including a flight prototype model (PM) thruster, an engineering model (EM) power processing unit, EM propellant management assemblies, a breadboard gimbal, and control unit simulators. Subsystem and system level technology validation testing is in progress. To achieve the objective Technology Readiness Level 6, environmental testing is being conducted to qualification levels in ground facilities simulating the space environment. Additional tests have been conducted to characterize the performance range and life capability of the NEXT thruster. This paper presents the status and results of technology validation testing accomplished to date, the validated subsystem and system capabilities, and the plans for completion of this phase of NEXT development.

Benson, Scott W.↗
NASA NTRS2008

Technology Readiness of the NEXT Ion Propulsion System

The NASA's Evolutionary Xenon Thruster (NEXT) ion propulsion system has been in advanced technology development under the NASA In-Space Propulsion Technology project. The highest fidelity hardware planned has now been completed by the government/industry team, including: a flight prototype model (PM) thruster, an engineering model (EM) power processing unit, EM propellant management assemblies, a breadboard gimbal, and control unit simulators. Subsystem and system level technology validation testing is in progress. To achieve the objective Technology Readiness Level 6, environmental testing is being conducted to qualification levels in ground facilities simulating the space environment. Additional tests have been conducted to characterize the performance range and life capability of the NEXT thruster. This paper presents the status and results of technology validation testing accomplished to date, the validated subsystem and system capabilities, and the plans for completion of this phase of NEXT development. The next round of competed planetary science mission announcements of opportunity, and directed mission decisions, are anticipated to occur in 2008 and 2009. Progress to date, and the success of on-going technology validation, indicate that the NEXT ion propulsion system will be a primary candidate for mission consideration in these upcoming opportunities.

Benson, Scott W.↗
NASA NTRS2008

Intelligent Integrated Health Management for a System of Systems

An intelligent integrated health management system (IIHMS) incorporates major improvements over prior such systems. The particular IIHMS is implemented for any system defined as a hierarchical distributed network of intelligent elements (HDNIE), comprising primarily: (1) an architecture (Figure 1), (2) intelligent elements, (3) a conceptual framework and taxonomy (Figure 2), and (4) and ontology that defines standards and protocols. Some definitions of terms are prerequisite to a further brief description of this innovation: A system-of-systems (SoS) is an engineering system that comprises multiple subsystems (e.g., a system of multiple possibly interacting flow subsystems that include pumps, valves, tanks, ducts, sensors, and the like); 'Intelligent' is used here in the sense of artificial intelligence. An intelligent element may be physical or virtual, it is network enabled, and it is able to manage data, information, and knowledge (DIaK) focused on determining its condition in the context of the entire SoS; As used here, 'health' signifies the functionality and/or structural integrity of an engineering system, subsystem, or process (leading to determination of the health of components); 'Process' can signify either a physical process in the usual sense of the word or an element into which functionally related sensors are grouped; 'Element' can signify a component (e.g., an actuator, a valve), a process, a controller, an actuator, a subsystem, or a system; The term Integrated System Health Management (ISHM) is used to describe a capability that focuses on determining the condition (health) of every element in a complex system (detect anomalies, diagnose causes, prognosis of future anomalies), and provide data, information, and knowledge (DIaK) not just data to control systems for safe and effective operation. A major novel aspect of the present development is the concept of intelligent integration. The purpose of intelligent integration, as defined and implemented in the present IIHMS, is to enable automated analysis of physical phenomena in imitation of human reasoning, including the use of qualitative methods. Intelligent integration is said to occur in a system in which all elements are intelligent and can acquire, maintain, and share knowledge and information. In the HDNIE of the present IIHMS, an SoS is represented as being operationally organized in a hierarchical-distributed format. The elements of the SoS are considered to be intelligent in that they determine their own conditions within an integrated scheme that involves consideration of data, information, knowledge bases, and methods that reside in all elements of the system. The conceptual framework of the HDNIE and the methodologies of implementing it enable the flow of information and knowledge among the elements so as to make possible the determination of the condition of each element. The necessary information and knowledge is made available to each affected element at the desired time, satisfying a need to prevent information overload while providing context-sensitive information at the proper level of detail. Provision of high-quality data is a central goal in designing this or any IIHMS. In pursuit of this goal, functionally related sensors are logically assigned to groups denoted processes. An aggregate of processes is considered to form a system. Alternatively or in addition to what has been said thus far, the HDNIE of this IIHMS can be regarded as consisting of a framework containing object models that encapsulate all elements of the system, their individual and relational knowledge bases, generic methods and procedures based on models of the applicable physics, and communication processes (Figure 2). The framework enables implementation of a paradigm inspired by how expert operators monitor the health of systems with the help of (1) DIaK from various sources, (2) software tools that assist in rapid visualization of the condition of the system, (3) analical software tools that assist in reasoning about the condition, (4) sharing of information via network communication hardware and software, and (5) software tools that aid in making decisions to remedy unacceptable conditions or improve performance.

Smith, Harvey↗
NASA NTRS2008

NASA Ares I Crew Launch Vehicle Upper Stage Overview

By incorporating rigorous engineering practices, innovative manufacturing processes and test techniques, a unique multi-center government/contractor partnership, and a clean-sheet design developed around the primary requirements for the International Space Station (ISS) and Lunar missions, the Upper Stage Element of NASA's Crew Launch Vehicle (CLV), the "Ares I," is a vital part of the Constellation Program's transportation system.

Davusm Daniel J.↗
NASA NTRS2008

NASA Ares I Crew Launch Vehicle Upper Stage Overview

By incorporating rigorous engineering practices, innovative manufacturing processes and test techniques, a unique multi-center government/contractor partnership, and a clean-sheet design developed around the primary requirements for the International Space Station (ISS) and Lunar missions, the Upper Stage Element of NASA's Crew Launch Vehicle (CLV), the "Ares I," is a vital part of the Constellation Program's transportation system. Constellation's exploration missions will include Ares I and Ares V launch vehicles required to place crew and cargo in low-Earth orbit (LEO), crew and cargo transportation systems required for human space travel, and transportation systems and scientific equipment required for human exploration of the Moon and Mars. Early Ares I configurations will support ISS re-supply missions. A self-supporting cylindrical structure, the Ares I Upper Stage will be approximately 84' long and 18' in diameter. The Upper Stage Element is being designed for increased supportability and increased reliability to meet human-rating requirements imposed by NASA standards. The design also incorporates state-of-the-art materials, hardware, design, and integrated logistics planning, thus facilitating a supportable, reliable, and operable system. With NASA retiring the Space Shuttle fleet in 2010, the success of the Ares I Project is essential to America's continued leadership in space. The first Ares I test flight, called Ares I-X, is scheduled for 2009. Subsequent test flights will continue thereafter, with the first crewed flight of the Crew Exploration Vehicle (CEV), "Orion," planned for no later than 2015. Crew transportation to the ISS will follow within the same decade, and the first Lunar excursion is scheduled for the 2020 timeframe.

McArthur, J. Craig↗
NASA NTRS2008

NASA Ares I Crew Launch Vehicle Upper Stage Overview

By incorporating rigorous engineering practices, innovative manufacturing processes and test techniques, a unique multi-center government/contractor partnership, and a clean-sheet design developed around the primary requirements for the International Space Station (ISS) and Lunar missions, the Upper Stage Element of NASA's Crew Launch Vehicle (CLV), the "Ares I," is a vital part of the Constellation Program's transportation system. Constellation's exploration missions will include Ares I and Ares V launch vehicles required to place crew and cargo in low-Earth orbit (LEO), crew and cargo transportation systems required for human space travel, and transportation systems and scientific equipment required for human exploration of the Moon and Mars. Early Ares I configurations will support ISS re-supply missions. A self-supporting cylindrical structure, the Ares I Upper Stage will be approximately 84' long and 18' in diameter. The Upper Stage Element is being designed for increased supportability and increased reliability to meet human-rating requirements imposed by NASA standards. The design also incorporates state-of-the-art materials, hardware, design, and integrated logistics planning, thus facilitating a supportable, reliable, and operable system. With NASA retiring the Space Shuttle fleet in 2010, the success of the Ares I Project is essential to America's continued leadership in space. The first Ares I test flight, called Ares 1-X, is scheduled for 2009. Subsequent test flights will continue thereafter, with the first crewed flight of the Crew Exploration Vehicle (CEV), "Orion," planned for no later than 2015. Crew transportation to the ISS will follow within the same decade, and the first Lunar excursion is scheduled for the 2020 timeframe.

Davis, Daniel J.↗
NASA NTRS2008

NASA Ares I Crew Launch Vehicle Upper State Overview

By incorporating rigorous engineering practices, innovative manufacturing processes and test techniques, a unique multi-center government/contractor partnership, and a clean-sheet design developed around the primary requirements for the International Space Station (ISS) and Lunar missions, the Upper Stage Element of NASA s Crew Launch Vehicle (CLV), the "Ares I," is a vital part of the Constellation Program s transportation system.

Davis, Daniel J.↗
NASA NTRS2008

Solid-State High-Temperature Power Cells

All-solid-state electrochemical power cells have been fabricated and tested in a continuing effort to develop batteries for instruments for use in environments as hot as 500 C. Batteries of this type are needed for exploration of Venus, and could be used on Earth for such applications as measuring physical and chemical conditions in geothermal and oil wells, processing furnaces, and combustion engines. In the state-of-the-art predecessors of the present solid-state power cells, fully packaged molten eutectic salts are used as electrolytes. The molten-salt-based cells can be susceptible to significant amounts of self-discharge and corrosion when used for extended times at elevated temperatures. In contrast, all-solid-state cells such as the present ones are expected to be capable of operating for many days at temperatures up to 500 C, without significant self-discharge. The solid-state cell described here includes a cathode made of FeS2, an electrolyte consisting of a crystalline solid solution of equimolar amounts of Li3PO4 and Li4SiO4, and an anode made of an alloy of Li and Si (see figure). The starting material for making the solid electrolyte is a stoichiometric mixture of Li3PO4, SiO2, and Li3CO2. This mixture is ball-milled, then calcined for two hours at a temperature of 1,100 C, then placed in a die atop the cathode material. Next, the layers in the die are squeezed together at a pressure between 60 and 120 MPa for one hour at a temperature of 600 C to form a unitary structure comprising the solid electrolyte and cathode bonded together. Finally, the lithium-alloy anode is pressure-bonded to the solid electrolyte layer, using an intermediate layer of pure lithium. In one test of a cell of this type, a discharge rate of about 1 mA per gram of cathode material was sustained for 72 hours at a temperature of about 460 C. This is about three times the discharge rate required to support some of the longer duration Venus-exploration mission scenarios.

Whitacre, Jay↗
NASA NTRS2007

Thermal Design Validation of the Mars Scout Phoenix Payload

This slide presentation reviews the validation of the thermal design for the Mars Scout Phoenix Payload. It includes a description of the Phoenix Mission, the science objectives, the timeline, and the flight system and payloads that were on the lander. The initial responsibility for the development and validation the thermal design was with the developers. This process lacked overall system engineering, there was a difference of thermal expertise, and the number of institutions involved complicated the interactions. The revised approach for payload thermal design validation is described.

thermal design validation↗
NASA NTRS2010

Asteroidal Differentiation - The Record in Meteorites

Early in solar system history, an intense energy source modified the small rocky bodies that had accreted from nebular condensates. The consensus view is that this energy source was the decay of short-lived 26Al, perhaps with a contribution from short-lived 60Fe. Differentiated meteorites and primitive achondrites preserve records of the states of asteroids as differentiation was ending. Reading these records provides clues to the nature of the energy source and the mechanisms of differentiation. I will examine the records from the acapulcoite-lordanite clan, ureilites, main-group pallasites, magmatic iron meteorite groups, brachinites and howardite-eucrite-diogenite (HED) clan meteorites. The acapulcoite-lodranite clan and the ureilites contain evidence that their parent asteroids reached temperatures where basaltic melts were produced. The mineralogies of lodranites and ureilites are dominantly olivine and low-Ca pyroxene, and these meteorites are highly depleted in incompatible lithophile elements. The acapulcoite-lodranite and ureilite parent bodies were heated to the point where on the order of 20-30% melting had taken place, but there is no evidence for more extensive melting. Assuming a 26Al energy source, the implication is that transport of the Al-rich basalt out of the mantle outpaced radiogenic heating, and thus shut down further differentiation. Main-group pallasites, magmatic iron meteorites and HED clan meteorites, on the other hand, provide evidence for total or near total melting of asteroids. The silicate phase of pallasites is magnesian olivine; their minor and trace element contents suggest that they are refractory melting residues. The degree of melting was high, perhaps on the order of 80%. The compositions of the most Ir-rich magmatic irons suggest near total melting of the metallic phase, and thus high degrees of melting on their parent asteroids. The compositions of basaltic eucrites are most consistent with them being residues from the crystallization of a largely molten asteroid. For these meteorite groups, the rate of heating outpaced the rate at which the melt could be extracted from the interiors, again, assuming 26Al was the energy source. The nature of the heat engine and asteroidal differentiation processes will be discussed as they can be inferred from the petrology and composition of achondrites, irons and stony irons.

Mittlefehldt, David W.↗
NASA NTRS2010

Affordability Engineering: Bridging the Gap Between Design and Cost

Affordability is a commonly used term that takes on numerous meanings depending on the context used. Within conceptual design of complex systems, the term generally implies comparisons between expected costs and expected resources. This characterization is largely correct, but does not convey the many nuances and considerations that are frequently misunderstood and underappreciated. In the most fundamental sense, affordability and cost directly relate to engineering and programmatic decisions made throughout development programs. Systems engineering texts point out that there is a temporal aspect to this relationship, for decisions made earlier in a program dictate design implications much more so than those made during latter phases. This paper explores affordability engineering and its many sub-disciplines by discussing how it can be considered an additional engineering discipline to be balanced throughout the systems engineering and systems analysis processes. Example methods of multidisciplinary design analysis with affordability as a key driver will be discussed, as will example methods of data visualization, probabilistic analysis, and other ways of relating design decisions to affordability results.

Reeves, J. D.↗
NASA NTRS2005

Using Laser-Induced Incandescence To Measure Soot in Exhaust

An instrumentation system exploits laser-induced incandescence (LII) to measure the concentration of soot particles in an exhaust stream from an engine, furnace, or industrial process that burns hydrocarbon fuel. In comparison with LII soot-concentration-measuring systems, this system is more complex and more capable.

Bachalo, William D.↗
NASA NTRS2011

Checking Flight Rules with TraceContract: Application of a Scala DSL for Trace Analysis

Typically during the design and development of a NASA space mission, rules and constraints are identified to help reduce reasons for failure during operations. These flight rules are usually captured in a set of indexed tables, containing rule descriptions, rationales for the rules, and other information. Flight rules can be part of manual operations procedures carried out by humans. However, they can also be automated, and either implemented as on-board monitors, or as ground based monitors that are part of a ground data system. In the case of automated flight rules, one considerable expense to be addressed for any mission is the extensive process by which system engineers express flight rules in prose, software developers translate these requirements into code, and then both experts verify that the resulting application is correct. This paper explores the potential benefits of using an internal Scala DSL for general trace analysis, named TRACECONTRACT, to write executable specifications of flight rules. TRACECONTRACT can generally be applied to analysis of for example log files or for monitoring executing systems online.

temporal logic↗
NASA NTRS2014

Autonomous Real Time Requirements Tracing

One of the more challenging aspects of software development is the ability to verify and validate the functional software requirements dictated by the Software Requirements Specification (SRS) and the Software Detail Design (SDD). Insuring the software has achieved the intended requirements is the responsibility of the Software Quality team and the Software Test team. The utilization of Timeliner-TLX(sup TM) Auto- Procedures for relocating ground operations positions to ISS automated on-board operations has begun the transition that would be required for manned deep space missions with minimal crew requirements. This transition also moves the auto-procedures from the procedure realm into the flight software arena and as such the operational requirements and testing will be more structured and rigorous. The autoprocedures would be required to meet NASA software standards as specified in the Software Safety Standard (NASASTD- 8719), the Software Engineering Requirements (NPR 7150), the Software Assurance Standard (NASA-STD-8739) and also the Human Rating Requirements (NPR-8705). The Autonomous Fluid Transfer System (AFTS) test-bed utilizes the Timeliner-TLX(sup TM) Language for development of autonomous command and control software. The Timeliner-TLX(sup TM) system has the unique feature of providing the current line of the statement in execution during real-time execution of the software. The feature of execution line number internal reporting unlocks the capability of monitoring the execution autonomously by use of a companion Timeliner-TLX(sup TM) sequence as the line number reporting is embedded inside the Timeliner-TLX(sup TM) execution engine. This negates I/O processing of this type data as the line number status of executing sequences is built-in as a function reference. This paper will outline the design and capabilities of the AFTS Autonomous Requirements Tracker, which traces and logs SRS requirements as they are being met during real-time execution of the targeted system. It is envisioned that real time requirements tracing will greatly assist the movement of autoprocedures to flight software enhancing the software assurance of auto-procedures and also their acceptance as reliable commanders.

Plattsmier, George↗
NASA NTRS2014

Autonomous Real Time Requirements Tracing

One of the more challenging aspects of software development is the ability to verify and validate the functional software requirements dictated by the Software Requirements Specification (SRS) and the Software Detail Design (SDD). Insuring the software has achieved the intended requirements is the responsibility of the Software Quality team and the Software Test team. The utilization of Timeliner-TLX(sup TM) Auto-Procedures for relocating ground operations positions to ISS automated on-board operations has begun the transition that would be required for manned deep space missions with minimal crew requirements. This transition also moves the auto-procedures from the procedure realm into the flight software arena and as such the operational requirements and testing will be more structured and rigorous. The autoprocedures would be required to meet NASA software standards as specified in the Software Safety Standard (NASASTD- 8719), the Software Engineering Requirements (NPR 7150), the Software Assurance Standard (NASA-STD-8739) and also the Human Rating Requirements (NPR-8705). The Autonomous Fluid Transfer System (AFTS) test-bed utilizes the Timeliner-TLX(sup TM) Language for development of autonomous command and control software. The Timeliner- TLX(sup TM) system has the unique feature of providing the current line of the statement in execution during real-time execution of the software. The feature of execution line number internal reporting unlocks the capability of monitoring the execution autonomously by use of a companion Timeliner-TLX(sup TM) sequence as the line number reporting is embedded inside the Timeliner-TLX(sup TM) execution engine. This negates I/O processing of this type data as the line number status of executing sequences is built-in as a function reference. This paper will outline the design and capabilities of the AFTS Autonomous Requirements Tracker, which traces and logs SRS requirements as they are being met during real-time execution of the targeted system. It is envisioned that real time requirements tracing will greatly assist the movement of autoprocedures to flight software enhancing the software assurance of auto-procedures and also their acceptance as reliable commanders

Plattsmier, George I.↗
NASA NTRS2015

Design Process of Flight Vehicle Structures for a Common Bulkhead and an MPCV Spacecraft Adapter

Design and manufacturing space flight vehicle structures is a skillset that has grown considerably at NASA during that last several years. Beginning with the Ares program and followed by the Space Launch System (SLS); in‐house designs were produced for both the Upper Stage and the SLS Multipurpose crew vehicle (MPCV) spacecraft adapter. Specifically, critical design review (CDR) level analysis and flight production drawing were produced for the above mentioned hardware. In particular, the experience of this in‐house design work led to increased manufacturing infrastructure for both Marshal Space Flight Center (MSFC) and Michoud Assembly Facility (MAF), improved skillsets in both analysis and design, and hands on experience in building and testing (MSA) full scale hardware. The hardware design and development processes from initiation to CDR and finally flight; resulted in many challenges and experiences that produced valuable lessons. This paper builds on these experiences of NASA in recent years on designing and fabricating flight hardware and examines the design/development processes used, as well as the challenges and lessons learned, i.e. from the initial design, loads estimation and mass constraints to structural optimization/affordability to release of production drawing to hardware manufacturing. While there are many documented design processes which a design engineer can follow, these unique experiences can offer insight into designing hardware in current program environments and present solutions to many of the challenges experienced by the engineering team.

Aggarwal, Pravin↗