Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “Process design and operation”

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 109 records · Page 6
All sourcesNASA NTRSDOE OSTI
NASA NTRSDate not supplied

Relative Motion for Short-Term Loitering in the Gateway NRHO

Numerous vehicles will visit Gateway throughout the expected mission lifetime, and much like Gateway, these vehicles will operate in a Near Rectilinear Halo Orbit (NRHO). Short-term loitering strategies are explored for these vehicles. The objective of this analysis is to illuminate concepts that enable safe loitering, while considering the operational limitations to the design process. To highlight relative motion, a linear sensitivity analysis is applied. The linear approach offers an initial guess strategy for generating loiter architectures in the high-fidelity gravity model. Methods of constructing transfers between loitering regimes are explored.

Stephen T Scheuerle↗
NASA NTRS1973

Report to the administrator by the NASA Aerospace Safety Advisory Panel on the Skylab program. Volume 1: Summary report

Contractor and NASA technical management for the development and manufacture of the Skylab modules is reviewed with emphasis on the following management controls: configuration and interface management; vendor control; and quality control of workmanship. A review of the modified two-stage Saturn V launch vehicle which focused on modifications to accommodate the Skylab payload; resolution of prior flight anomalies; and changes in personnel and management systems is presented along with an evaluation of the possible age-life and storage problems for the Saturn 1-B launch vehicle. The NASA program management's visibility and control of contractor operations, systems engineering and integration, the review process for the evaluation of design and flight hardware, and the planning process for mission operations are investigated. It is concluded that the technical management system for development and fabrication of the modules, spacecraft, and launch vehicles, the process of design and hardware acceptance reviews, and the risk assessment activities are satisfactory. It is indicated that checkout activity, integrated testing, and preparations for and execution of mission operation require management attention.

Source record↗
NASA NTRS1992

Metals production

Existing procedures for design of electrochemical plants can be used for design of lunar processes taking into consideration the differences in environmental conditions. These differences include: 1/6 Earth gravity, high vacuum, solar electrical and heat source, space radiation heat sink, long days and nights, and different availability and economics of materials, energy, and labor. Techniques have already been developed for operation of relatively small scale hydrogen-oxygen fuel cell systems used in the U.S. lunar landing program. Design and operation of lunar aqueous electrolytic process plants appears to be within the state-of-the-art. Finding or developing compatible materials for construction and designing of fused-magma metal winning cells will present a real engineering challenge.

Beck, Theodore S.↗
NASA NTRS2005

Range Process Simulation Tool

Range Process Simulation Tool (RPST) is a computer program that assists managers in rapidly predicting and quantitatively assessing the operational effects of proposed technological additions to, and/or upgrades of, complex facilities and engineering systems such as the Eastern Test Range. Originally designed for application to space transportation systems, RPST is also suitable for assessing effects of proposed changes in industrial facilities and large organizations. RPST follows a model-based approach that includes finite-capacity schedule analysis and discrete-event process simulation. A component-based, scalable, open architecture makes RPST easily and rapidly tailorable for diverse applications. Specific RPST functions include: (1) definition of analysis objectives and performance metrics; (2) selection of process templates from a processtemplate library; (3) configuration of process models for detailed simulation and schedule analysis; (4) design of operations- analysis experiments; (5) schedule and simulation-based process analysis; and (6) optimization of performance by use of genetic algorithms and simulated annealing. The main benefits afforded by RPST are provision of information that can be used to reduce costs of operation and maintenance, and the capability for affordable, accurate, and reliable prediction and exploration of the consequences of many alternative proposed decisions.

Phillips, Dave↗
NASA NTRS2002

QMI: Rising to the Space Station Design Challenge

The Quench Module Insert (QMI) materials processing furnace is being designed to operate for 8000 hours over four years on the International Space Station (ISS) as part of the first Materials Science Research Rack (MSRR-1) of the Materials Science Research Facility (MSRF). The Bridgman-type furnace is being built for the directional solidification processing of metals and alloys in the microgravity environment of space. Most notably it will be used for processing aluminum and related alloys. Designing for the space station environment presents intriguing design challenges in the form of a ten-year life requirement coupled with both limited opportunities for maintenance and resource constraints in the form of limited power and space. The long life requirement has driven the design of several features in the furnace, including the design of the heater core, the selection and placement of the thermocouples, overall performance monitoring, and the design of the chill block. The power and space limitations have been addressed through a compact furnace design using efficient vacuum insulation. Details on these design features, as well as development test performance results to date, are presented.

Carswell, W. E.↗
NASA NTRS1991

Space system production cost benefits from contemporary philosophies in management and manufacturing

The cost of manufacturing space system hardware has always been expensive. The Engineering Cost Group of the Program Planning office at Marshall is attempting to account for cost savings that result from new technologies in manufacturing and management. The objective is to identify and define contemporary philosophies in manufacturing and management. The seven broad categories that make up the areas where technological advances can assist in reducing space system costs are illustrated. Included within these broad categories is a list of the processes or techniques that specifically provide the cost savings within todays design, test, production and operations environments. The processes and techniques listed achieve savings in the following manner: increased productivity; reduced down time; reduced scrap; reduced rework; reduced man hours; and reduced material costs. In addition, it should be noted that cost savings from production and processing improvements effect 20 to 40 pct. of production costs whereas savings from management improvements effects 60 to 80 of production cost. This is important because most efforts in reducing costs are spent trying to reduce cost in the production.

Rosmait, Russell L.↗
NASA NTRSDate not supplied

The Spacecraft Mass Balance as a Diagnostic Tool for Cabin Air Quality

The spacecraft-level mass balance is a powerful tool for diagnosing and decoupling factors influencing cabin air quality, especially with respect to trace contaminant propagation. Successful implementation of this approach relies upon accurate and temporally relevant air quality measurements, which are often challenging to attain for emerging trace contaminants. In addition to the proper interpretation of air quality data trends, a thorough understanding of subsystem-level mass transfer is required to characterize process performance. For many Environmental Control and Life Support System processes, subsystem mass transfer may be predicted based on physicochemical properties and classic unit operation design approaches. Gaps in understanding of process performance should be supplemented with thorough ground testing. A high confidence in the fidelity of one of these two aspects, air quality data or process performance, may help offset uncertainties in the other. At minimum, thresholding assumptions and numerical methods can be imposed to constrain unknown parameters within the physical envelope of the situation at hand. Finally, the complexity of cabin-wide integrated mass balances may be reduced by implementing a phenomenological approach towards subsystem discretization.

Cabin Air-quality↗
NASA NTRS1994

A software architecture for automating operations processes

The Operations Engineering Lab (OEL) at JPL has developed a software architecture based on an integrated toolkit approach for simplifying and automating mission operations tasks. The toolkit approach is based on building adaptable, reusable graphical tools that are integrated through a combination of libraries, scripts, and system-level user interface shells. The graphical interface shells are designed to integrate and visually guide a user through the complex steps in an operations process. They provide a user with an integrated system-level picture of an overall process, defining the required inputs and possible output through interactive on-screen graphics. The OEL has developed the software for building these process-oriented graphical user interface (GUI) shells. The OEL Shell development system (OEL Shell) is an extension of JPL's Widget Creation Library (WCL). The OEL Shell system can be used to easily build user interfaces for running complex processes, applications with extensive command-line interfaces, and tool-integration tasks. The interface shells display a logical process flow using arrows and box graphics. They also allow a user to select which output products are desired and which input sources are needed, eliminating the need to know which program and its associated command-line parameters must be executed in each case. The shells have also proved valuable for use as operations training tools because of the OEL Shell hypertext help environment. The OEL toolkit approach is guided by several principles, including the use of ASCII text file interfaces with a multimission format, Perl scripts for mission-specific adaptation code, and programs that include a simple command-line interface for batch mode processing. Projects can adapt the interface shells by simple changes to the resources configuration file. This approach has allowed the development of sophisticated, automated software systems that are easy, cheap, and fast to build. This paper will discuss our toolkit approach and the OEL Shell interface builder in the context of a real operations process example. The paper will discuss the design and implementation of a Ulysses toolkit for generating the mission sequence of events. The Sequence of Events Generation (SEG) system provides an adaptable multimission toolkit for producing a time-ordered listing and timeline display of spacecraft commands, state changes, and required ground activities.

Miller, Kevin J.↗
NASA NTRS2011

Asynchronous Message Service Reference Implementation

This software provides a library of middleware functions with a simple application programming interface, enabling implementation of distributed applications in conformance with the CCSDS AMS (Consultative Committee for Space Data Systems Asynchronous Message Service) specification. The AMS service, and its protocols, implement an architectural concept under which the modules of mission systems may be designed as if they were to operate in isolation, each one producing and consuming mission information without explicit awareness of which other modules are currently operating. Communication relationships among such modules are self-configuring; this tends to minimize complexity in the development and operations of modular data systems. A system built on this model is a society of generally autonomous, inter-operating modules that may fluctuate freely over time in response to changing mission objectives, modules functional upgrades, and recovery from individual module failure. The purpose of AMS, then, is to reduce mission cost and risk by providing standard, reusable infrastructure for the exchange of information among data system modules in a manner that is simple to use, highly automated, flexible, robust, scalable, and efficient. The implementation is designed to spawn multiple threads of AMS functionality under the control of an AMS application program. These threads enable all members of an AMS-based, distributed application to discover one another in real time, subscribe to messages on specific topics, and to publish messages on specific topics. The query/reply (client/server) communication model is also supported. Message exchange is optionally subject to encryption (to support confidentiality) and authorization. Fault tolerance measures in the discovery protocol minimize the likelihood of overall application failure due to any single operational error anywhere in the system. The multi-threaded design simplifies processing while enabling application nodes to operate at high speeds; linked lists protected by mutex semaphores and condition variables are used for efficient, inter-thread communication. Applications may use a variety of transport protocols underlying AMS itself, including TCP (Transmission Control Protocol), UDP (User Datagram Protocol), and message queues.

Burleigh, Scott C.↗
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 NTRS1994

Concurrent engineering: Spacecraft and mission operations system design

Despite our awareness of the mission design process, spacecraft historically have been designed and developed by one team and then turned over as a system to the Mission Operations organization to operate on-orbit. By applying concurrent engineering techniques and envisioning operability as an essential characteristic of spacecraft design, tradeoffs can be made in the overall mission design to minimize mission lifetime cost. Lessons learned from previous spacecraft missions will be described, as well as the implementation of concurrent mission operations and spacecraft engineering for the Near Earth Asteroid Rendezvous (NEAR) program.

Landshof, J. A.↗
NASA NTRS2006

Cassini distributed instrument operations – what we’ve learned since Saturn orbit insertion

The Cassini mission to Saturn is complex with 12 science teams conducting distributed operations across the United States and Europe. Each Team includes scientists from around the world who actively participate in operations, including observation design, instrument commanding, downlink processing, and archiving. This represents a change in how JPL complex deep-space missions have been operated. Since Saturn Orbit Insertion (SOI), the Cassini Project has spent 17 months conducting science operations and has gained realworld experience that has tested the assumptions and rationale for this approach. We have learned that many of the expected benefits have been realized, but there were numerous unexpected challenges as well. This paper will discuss the lessons learned from the Cassini Tour experience to date. It will revisit the assumptions and rationale behind the distributed instrument operations design and will describe the results, good and bad, of implementing this method of operations. We will describe how Instrument Teams are structured, their roles and responsibilities, what challenges they faced going into orbital operations (the “tour”) and what creative solutions were proposed when funding limitations and schedule milestones prevented optimum solutions. We will also discuss the problems that have been encountered both on the ground and with the instruments, how these problems and anomalies were overcome, and what was learned along the way about the characteristics of distributed instrument operations.

Woncik, Pam↗
NASA NTRS2006

Cassini Distributed Instrument Operations: What We've Learned Since Saturn Orbit Insertion

The Cassini mission to Saturn is complex with 12 science teams conducting distributed operations across the United States and Europe. Each Team includes scientists from around the world who actively participate in operations, including observation design, instrument commanding, downlink processing, and archiving. This represents a change in how JPL complex deep-space missions have been operated. Since Saturn Orbit Insertion (SOI), the Cassini Project has spent 17 months conducting science operations and has gained real-world experience that has tested the assumptions and rationale for this approach. We have learned that many of the expected benefits have been realized, but there were numerous unexpected challenges as well. This paper will discuss the lessons learned from the Cassini Tour experience to date. It will revisit the assumptions and rationale behind the distributed instrument operations design and will describe the results, good and bad, of implementing this method of operations. We will describe how Instrument Teams are structured, their roles and responsibilities, what challenges they faced going into orbital operations (the 'tour') and what creative solutions were proposed when funding limitations and schedule milestones prevented optimum solutions. We will also discuss the problems that have been encountered both on the ground and with the instruments, how these problems and anomalies were overcome, and what was learned along the way about the characteristics of distributed instrument operations.

Cassini↗
NASA NTRS2005

Development of the Architectural Simulation Model for Future Launch Systems and its Application to an Existing Launch Fleet

A significant portion of lifecycle costs for launch vehicles are generated during the operations phase. Research indicates that operations costs can account for a large percentage of the total life-cycle costs of reusable space transportation systems. These costs are largely determined by decisions made early during conceptual design. Therefore, operational considerations are an important part of vehicle design and concept analysis process that needs to be modeled and studied early in the design phase. However, this is a difficult and challenging task due to uncertainties of operations definitions, the dynamic and combinatorial nature of the processes, and lack of analytical models and the scarcity of historical data during the conceptual design phase. Ultimately, NASA would like to know the best mix of launch vehicle concepts that would meet the missions launch dates at the minimum cost. To answer this question, we first need to develop a model to estimate the total cost, including the operational cost, to accomplish this set of missions. In this project, we have developed and implemented a discrete-event simulation model using ARENA (a simulation modeling environment) to determine this cost assessment. Discrete-event simulation is widely used in modeling complex systems, including transportation systems, due to its flexibility, and ability to capture the dynamics of the system. The simulation model accepts manifest inputs including the set of missions that need to be accomplished over a period of time, the clients (e.g., NASA or DoD) who wish to transport the payload to space, the payload weights, and their destinations (e.g., International Space Station, LEO, or GEO). A user of the simulation model can define an architecture of reusable or expendable launch vehicles to achieve these missions. Launch vehicles may belong to different families where each family may have it own set of resources, processing times, and cost factors. The goal is to capture the required resource levels of the major launch elements and their required facilities. The model s output can show whether or not a certain architecture of vehicles can meet the launch dates, and if not, how much the delay cost would be. It will also produce aggregate figures of missions cost based on element procurement cost, processing cost, cargo integration cost, delay cost, and mission support cost. One of the most useful features of this model is that it is stochastic where it accepts statistical distributions to represent the processing times mimicking the stochastic nature of real systems.

Rabadi, Ghaith↗
NASA NTRS1990

Vehicle processing operations database

The Vehicle Processing Operations Data base (VPOD) has been designed and constructed to enable the collection and preliminary analysis of data relative to the processing of planetary exploration vehicles in low Earth orbit. VPOD has the capability to hierarchically store the events, assemblies, and equipment data needed for performing vehicle processing analysis, to whatever level of detail available. This permits some analysis to be performed even during the very early phases of vehicle and mission design. As more data about the events, assemblies, or equipment become available, the analysis can then be refined using the increased level of detail. VPOD output is based on a mission defined by selecting from the VPOD Events data base the events that are required to perform the desired tasks. The outputs available include total crew time, crew skill requirements, equipment needed, assemblies worked per event, to any available level of detail. The VPOD design is structured to interface with an operations simulation capability which is currently in the requirements definition phase. The simulator will use information from the VPOD to perform operations analysis for missions being conducted in low Earth orbit. VPOD information, along with information from the science missions operations data base and a Space Station configuration data base, will be used by the simulator to provide a capability to study total system operations and resources requirements.

Ganoe, George G.↗
NASA NTRS2006

From Prime to Extended Mission: Evolution of the MER Tactical Uplink Process

To support a 90-day surface mission for two robotic rovers, the Mars Exploration Rover mission designed and implemented an intensive tactical operations process, enabling daily commanding of each rover. Using a combination of new processes, custom software tools, a Mars-time staffing schedule, and seven-day-a-week operations, the MER team was able to compress the traditional weeks-long command-turnaround for a deep space robotic mission to about 18 hours. However, the pace of this process was never intended to be continued indefinitely. Even before the end of the three-month prime mission, MER operations began evolving towards greater sustainability. A combination of continued software tool development, increasing team experience, and availability of reusable sequences first reduced the mean process duration to approximately 11 hours. The number of workshifts required to perform the process dropped, and the team returned to a modified 'Earth-time' schedule. Additional process and tool adaptation eventually provided the option of planning multiple Martian days of activity within a single workshift, making 5-day-a-week operations possible. The vast majority of the science team returned to their home institutions, continuing to participate fully in the tactical operations process remotely. MER has continued to operate for over two Earth-years as many of its key personnel have moved on to other projects, the operations team and budget have shrunk, and the rovers have begun to exhibit symptoms of aging.

mission operations↗
NASA NTRS2006

From Prime to Extended Mission: Evolution of the MER Tactical Uplink Process

To support a 90-day surface mission for two robotic rovers, the Mars Exploration Rover mission designed and implemented an intensive tactical operations process, enabling daily commanding of each rover. Using a combination of new processes, custom software tools, a Mars-time staffing schedule, and seven-day-a-week operations, the MER team was able to compress the traditional weeks-long command-turnaround for a deep space robotic mission to about 18 hours. However, there was never an intention of maintaining the pace of this process indefinitely. Even before the end of the three-month prime mission, MER operations began evolving towards greater sustainability. A combination of continued software tool development, increasing team experience, and availability of reusable sequences first reduced the mean process duration to approximately 11 hours. The number of workshifts required to perform the process dropped, and the team returned to a modified 'Earth-time' schedule. Additional process and tool adaptation eventually provided the option of planning multiple Martian days of activity within a single workshift, making 5- day-a-week operations possible. The vast majority of the science team returned to their home institutions, continuing to participate fully in the tactical operations process remotely. MER has continued to operate for over two Earth-years as many of its key personnel have moved on to other projects, the operations team and budget have shrunk, and the rovers have begun to exhibit symptoms of aging.

Mars exploration↗