Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “lifecycle”

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

Towards a systems approach to risk considerations for concurrent design

This paper describes the new process used by the Project Design Center at NASA's Jet Propulsion Laboratory for the identification, assessment and communication of risk elements throughout the lifecycle of a mission design. This process includes a software tool, 'RAP' that collects and communicates risk information between the various designers and a 'risk expert' who mediates this process. The establishment of this process is an attempt towards the systematic consideration of risk in the design decision making process. Using this process, we are able to better keep track of the risks associated with the design decisions. Furthermore, it helps us develop better risk profiles for the studies under consideration. We aim to refine and expand the current process to enable more thorough risk analysis capabilities in the future.

concurrent design↗
NASA NTRS2003

Micro - helm - a mission operation visualization system

Micro-Helm is a PC based mission visualization system that can be employed for comprehensive monitoring of mission system states during operation. Micro-Helm was designed as a cost-effective system solution that can be adapted to multiple missions in various mission lifecycle phases. It has been successfully applied to DS1 mission during its entire operation phases and Mars Odyssey mission during its launch and orbit-insertion phase, providing scenario design and validation.

Micro-Helm↗
NASA NTRS2005

Failure Assessment

Three questions to which software developers want accurate, precise answers are "How can the software system fail?", "mat bad things will happen if the software fails?t', and "How many failures will the software experience?". Numerous techniques have been devised to answer these questions; three of the best known are: 1) Software Fault Tree Analysis (SFTA) 2) Software Failure Modes, Effects, and Criticality Analysis (SFMECA 3) Software Fault/Failure Modeling. SFTA and SFMECA have been successfully used to analyze the flight software for a number of robotic planetary exploration missions, including Galileo, Cassini, and Deep Space 1. Given the increasing interest in reusing software components from mission to mission, one of us has developed techniques for reusing the corresponding portions of the SFTA and SFMECA, reducing the effort required to conduct these analyses. SFTA has also been shown to be effective in analyzing the security aspects of software systems; intrusion mechanisms and effects can easily be modeled using these techniques. The Bi- Directional Safety Analysis (BDSA) method combines a forward search (similar to SFMECA) from potential failure modes to their effects, with a backward search (similar to SFTA) from feasible hazards to the contributing causes of each hazard. BDSA offers an efficient way to identify latent failures. Recent work has extended BDSA to product-line applications such as flight-instrumentation displays and developed tool support for the reuse of the failure-analysis artifacts within a product line. BDSA has also been streamlined to support those projects having tight cost and/or schedule constraints for their failure analysis efforts. We discuss lessons learned from practice, describe available tools, and identi@ some future directions for the topic. A substantial amount of research has been devoted to estimating the number of failures that a software system will experience during test and operations, as well as the number of faults that have been inserted into that system during its development. One of us has found that the amount of structural change to a system during its development is strongly related to the number of faults inserted into it. Using techniques requiring no additional effort on the part of the development organization, the required measurements of structural evolution can be easily obtained from a development effort's configuration management system and readily transformed into an estimate of fault content. So far, structure-fault relationships have been identified for source code; current work seeks to examine artifacts available earlier in the lifecycle to determine if similar relationships between structure and fault content can be found. In particular, relationships between requirements change requests and the number of faults inserted into the implemented system would provide a significant improvement in our ability to control software quality during the early development phases.

fault tree↗
NASA NTRS2006

Mission Control Technologies: A New Way of Designing and Evolving Mission Systems

Current mission operations systems are built as a collection of monolithic software applications. Each application serves the needs of a specific user base associated with a discipline or functional role. Built to accomplish specific tasks, each application embodies specialized functional knowledge and has its own data storage, data models, programmatic interfaces, user interfaces, and customized business logic. In effect, each application creates its own walled-off environment. While individual applications are sometimes reused across multiple missions, it is expensive and time consuming to maintain these systems, and both costly and risky to upgrade them in the light of new requirements or modify them for new purposes. It is even more expensive to achieve new integrated activities across a set of monolithic applications. These problems impact the lifecycle cost (especially design, development, testing, training, maintenance, and integration) of each new mission operations system. They also inhibit system innovation and evolution. This in turn hinders NASA's ability to adopt new operations paradigms, including increasingly automated space systems, such as autonomous rovers, autonomous onboard crew systems, and integrated control of human and robotic missions. Hence, in order to achieve NASA's vision affordably and reliably, we need to consider and mature new ways to build mission control systems that overcome the problems inherent in systems of monolithic applications. The keys to the solution are modularity and interoperability. Modularity will increase extensibility (evolution), reusability, and maintainability. Interoperability will enable composition of larger systems out of smaller parts, and enable the construction of new integrated activities that tie together, at a deep level, the capabilities of many of the components. Modularity and interoperability together contribute to flexibility. The Mission Control Technologies (MCT) Project, a collaboration of multiple NASA Centers, led by NASA Ames Research Center, is building a framework to enable software to be assembled from flexible collections of components and services.

Trimble, Jay↗
NASA NTRS2006

Integrated Human-Robotic Missions to the Moon and Mars: Mission Operations Design Implications

For most of the history of space exploration, human and robotic programs have been independent, and have responded to distinct requirements. The NASA Vision for Space Exploration calls for the return of humans to the Moon, and the eventual human exploration of Mars; the complexity of this range of missions will require an unprecedented use of automation and robotics in support of human crews. The challenges of human Mars missions, including roundtrip communications time delays of 6 to 40 minutes, interplanetary transit times of many months, and the need to manage lifecycle costs, will require the evolution of a new mission operations paradigm far less dependent on real-time monitoring and response by an Earthbound operations team. Robotic systems and automation will augment human capability, increase human safety by providing means to perform many tasks without requiring immediate human presence, and enable the transfer of traditional mission control tasks from the ground to crews. Developing and validating the new paradigm and its associated infrastructure may place requirements on operations design for nearer-term lunar missions. The authors, representing both the human and robotic mission operations communities, assess human lunar and Mars mission challenges, and consider how human-robot operations may be integrated to enable efficient joint operations, with the eventual emergence of a unified exploration operations culture.

Korth, David↗
NASA NTRS2006

Building Operations Efficiencies into NASA's Crew Launch Vehicle Design

The U.S. Vision for Space Exploration guides NASA's challenging missions of technological innovation and scientific investigation. With the Agency's commitment to complete the International Space Station (ISS) and to retire the Space Shuttle by 2010, the NASA Administrator commissioned the Exploration Systems Architecture Study (ESAS) in mid 2005 to analyze options for a safer, simpler, more cost efficient launch system that could deliver timely human-rated space transportation capabilities. NASA's finite resources yield discoveries with infinite possibilities. As the Agency begins the process of replacing the Shuttle with new launch vehicles destined for missions beyond low-Earth orbit to the Moon and Mars, NASA is designing the follow-on crew and cargo systems for maximum operational efficiencies. This mandate is imperative to reduce the $4.5 billion NASA spends on space transportation each year. This paper gives top-level details of how the follow-on Crew Launch Vehicle (CLV) is being designed for reduced lifecycle costs as a primary catalyst for the expansion of future frontiers.

Dumbacher, Daniel L.↗
NASA NTRS2006

NASA Software Estimating Tool (N-SET)

The goals of this project are to: Develop an early lifecycle software cost estimation tool leveraging existing data and capabilities Collect additional software data from: a) Jet Propulsion Laboratory; b) Goddard Space Flight Center; and c) Marshall Space Flight Center. Analyze, normalize, evaluate, stratify, and validate data. Create a calibrated, validated, and documented tool initially using available data and subsequently using newly collected data.

cost estimating tools↗
NASA NTRS2006

Deep Impact Sequence Planning Using Multi-Mission Adaptable Planning Tools With Integrated Spacecraft Models

The Deep Impact mission was ambitious and challenging. JPL's well proven, easily adaptable multi-mission sequence planning tools combined with integrated spacecraft subsystem models enabled a small operations team to develop, validate, and execute extremely complex sequence-based activities within very short development times. This paper focuses on the core planning tool used in the mission, APGEN. It shows how the multi-mission design and adaptability of APGEN made it possible to model spacecraft subsystems as well as ground assets throughout the lifecycle of the Deep Impact project, starting with models of initial, high-level mission objectives, and culminating in detailed predictions of spacecraft behavior during mission-critical activities.

Deep Impact Mission↗
NASA NTRS2007

Managing Space Technology Development at NASA

NASA uses a structured process for managing projects that develop advanced space technologies and transition them into the designs of flight systems. The four-part process consists of formulation, approval, implementation, and transition. In the formulation phase, technology needs are derived from mission concept studies, various technical approaches for meeting the technology needs are identified, technical performance goals called Key Performance Parameters (KPPs) are established, and a project plan is developed. Prior to project approval, an Independent Formulation Review is conducted to ensure that the project objectives are aligned with the mission needs, and that the project is well planned to meet the objectives. In the implementation phase, the technology development project matures the technology, and progress towards the KPPs is evaluated in periodic status reviews. Technology Readiness Levels (TRLs) are used throughout the project lifecycle to assess the progress of technology maturation. In the transition phase, technologies that are successful in achieving the required level of maturity are transitioned to a customer for further development, are used in system designs, or are thoroughly documented for resumption of development at a later date. The customer or end-user of the technology is involved in all phases of the technology development process.

Moore, Christopher L.↗
NASA NTRS2007

Human Factors in the Design of the Crew Exploration Vehicle (CEV)

NASA s Space Exploration vision for humans to venture to the moon and beyond provides interesting human factors opportunities and challenges. The Human Engineering group at NASA has been involved in the initial phases of development of the Crew Exploration Vehicle (CEV), Orion. Getting involved at the ground level, Human Factors engineers are beginning to influence design; this involvement is expected to continue throughout the development lifecycle. The information presented here describes what has been done to date, what is currently going on, and what is expected in the future. During Phase 1, prior to the contract award to Lockheed Martin, the Human Engineering group was involved in generating requirements, conducting preliminary task analyses based on interviews with subject matter experts in all vehicle systems areas, and developing preliminary concepts of operations based on the task analysis results. In addition, some early evaluations to look at CEV net habitable volume were also conducted. The program is currently in Phase 2, which is broken down into design cycles, including System Readiness Review, Preliminary Design Review, and Critical Design Review. Currently, there are ongoing Human Engineering Technical Interchange Meetings being held with both NASA and Lockheed Martin in order to establish processes, desired products, and schedules. Multiple design trades and quick-look evaluations (e.g. display device layout and external window size) are also in progress. Future Human Engineering activities include requirement verification assessments and crew/stakeholder evaluations of increasing fidelity. During actual flights of the CEV, the Human Engineering group is expected to be involved in in-situ testing and lessons learned reporting, in order to benefit human space flight beyond the initial CEV program.

Whitmore, Mihriban↗
NASA NTRS2006

Fusing Quantitative Requirements Analysis with Model-based Systems Engineering

A vision is presented for fusing quantitative requirements analysis with model-based systems engineering. This vision draws upon and combines emergent themes in the engineering milieu. "Requirements engineering" provides means to explicitly represent requirements (both functional and non-functional) as constraints and preferences on acceptable solutions, and emphasizes early-lifecycle review, analysis and verification of design and development plans. "Design by shopping" emphasizes revealing the space of options available from which to choose (without presuming that all selection criteria have previously been elicited), and provides means to make understandable the range of choices and their ramifications. "Model-based engineering" emphasizes the goal of utilizing a formal representation of all aspects of system design, from development through operations, and provides powerful tool suites that support the practical application of these principles. A first step prototype towards this vision is described, embodying the key capabilities. Illustrations, implications, further challenges and opportunities are outlined.

optimization↗
NASA NTRS2007

Observations on Cost Modeling and Performance Measurement of Long Term Archives

This paper describes a prototype suite of Excel-based tools that could be used for estimating lifecycle costs for newly planned or modified long-term archival facilities. These tools may also prove valuable for monitoring the long-term performance of such facilities once operational. Cost estimation is by analogy, using statistical curve-fitting techniques across a database of comparable data activities. The database currently includes 29 operational data centers ranging from small (2 FTEs) to large (66 FTEs), and is readily expandable to include additional activities specifically involving data preservation and added value. Each comparable data center is described in terms of its staffing, throughput workload, archival and distribution requirements, levels of user service, overall complexity, degree of automation, and other data, comprising 94 distinct descriptors in all. The descriptors were developed by normalizing heterogeneous data from the various centers and mapping them into an Excel framework consistent with the OAIS reference model. A user-friendly tool is provided for generating input to and updating the comparables database. This tool can also be used to benchmark the performance (in terms of cost versus throughput) of an operational data center, and to update the staffing, cost and workload data on a periodic basis. The comparables database could thus provide a history of staffing and throughput over time, as a means of performance monitoring and providing feedback for continuous improvement. Ancillary tools are also provided for performing "what-if' cost exercises for planning purposes, and for graphical display of data and results. We provide a high-level description of the tools; present our experiences and observations on gathering the information and maintaining the database; and discuss how this tool set might be applied to long term archives.

Fontaine, Kathy↗
NASA NTRS2006

Proven Innovations and New Initiatives in Ground System Development: Reducing Costs in the Ground System

The state-of-the-practice for engineering and development of Ground Systems has evolved significantly over the past half decade. Missions that challenge ground system developers with significantly reduced budgets in spite of requirements for greater and previously unimagined functionality are now the norm. Making the right trades early in the mission lifecycle is one of the key factors to minimizing ground system costs. The Mission Operations Strategic Leadership Team at the Jet Propulsion Laboratory has spent the last year collecting and working through successes and failures in ground systems for application to future missions.

costs↗
NASA NTRS2006

Advancing the practice of systems engineering at JPL

In FY 2004, JPL launched an initiative to improve the way it practices systems engineering. The Lab's senior management formed the Systems Engineering Advancement (SEA) Project in order to "significantly advance the practice and organizational capabilities of systems engineering at JPL on flight projects and ground support tasks." The scope of the SEA Project includes the systems engineering work performed in all three dimensions of a program, project, or task: 1. the full life-cycle, i.e., concept through end of operations 2. the full depth, i.e., Program, Project, System, Subsystem, Element (SE Levels 1 to 5) 3. the full technical scope, e.g., the flight, ground and launch systems, avionics, power, propulsion, telecommunications, thermal, etc. The initial focus of their efforts defined the following basic systems engineering functions at JPL: systems architecture, requirements management, interface definition, technical resource management, system design and analysis, system verification and validation, risk management, technical peer reviews, design process management and systems engineering task management, They also developed a list of highly valued personal behaviors of systems engineers, and are working to inculcate those behaviors into members of their systems engineering community. The SEA Project is developing products, services, and training to support managers and practitioners throughout the entire system lifecycle. As these are developed, each one needs to be systematically deployed. Hence, the SEA Project developed a deployment process that includes four aspects: infrastructure and operations, communication and outreach, education and training, and consulting support. In addition, the SEA Project has taken a proactive approach to organizational change management and customer relationship management - both concepts and approaches not usually invoked in an engineering environment. This paper'3 describes JPL's approach to advancing the practice of systems engineering at the Lab. It describes the general approach used and how they addressed the three key aspects of change: people, process and technology. It highlights a list of highly valued personal behaviors of systems engineers, discusses the various products, services and training that were developed, describes the deployment approach used, and concludes with several lessons learned.

process improvement↗
NASA NTRS2007

System Engineering Strategy for Distributed Multi-Purpose Simulation Architectures

This paper describes the system engineering approach used to develop distributed multi-purpose simulations. The multi-purpose simulation architecture focuses on user needs, operations, flexibility, cost and maintenance. This approach was used to develop an International Space Station (ISS) simulator, which is called the International Space Station Integrated Simulation (ISIS)1. The ISIS runs unmodified ISS flight software, system models, and the astronaut command and control interface in an open system design that allows for rapid integration of multiple ISS models. The initial intent of ISIS was to provide a distributed system that allows access to ISS flight software and models for the creation, test, and validation of crew and ground controller procedures. This capability reduces the cost and scheduling issues associated with utilizing standalone simulators in fixed locations, and facilitates discovering unknowns and errors earlier in the development lifecycle. Since its inception, the flexible architecture of the ISIS has allowed its purpose to evolve to include ground operator system and display training, flight software modification testing, and as a realistic test bed for Exploration automation technology research and development.

Bhula, Dlilpkumar↗
NASA NTRS2007

Computational Modeling Develops Ultra-Hard Steel

Glenn Research Center's Mechanical Components Branch developed a spiral bevel or face gear test rig for testing thermal behavior, surface fatigue, strain, vibration, and noise; a full-scale, 500-horsepower helicopter main-rotor transmission testing stand; a gear rig that allows fundamental studies of the dynamic behavior of gear systems and gear noise; and a high-speed helical gear test for analyzing thermal behavior for rotorcraft. The test rig provides accelerated fatigue life testing for standard spur gears at speeds of up to 10,000 rotations per minute. The test rig enables engineers to investigate the effects of materials, heat treat, shot peen, lubricants, and other factors on the gear's performance. QuesTek Innovations LLC, based in Evanston, Illinois, recently developed a carburized, martensitic gear steel with an ultra-hard case using its computational design methodology, but needed to verify surface fatigue, lifecycle performance, and overall reliability. The Battelle Memorial Institute introduced the company to researchers at Glenn's Mechanical Components Branch and facilitated a partnership allowing researchers at the NASA Center to conduct spur gear fatigue testing for the company. Testing revealed that QuesTek's gear steel outperforms the current state-of-the-art alloys used for aviation gears in contact fatigue by almost 300 percent. With the confidence and credibility provided by the NASA testing, QuesTek is commercializing two new steel alloys. Uses for this new class of steel are limitless in areas that demand exceptional strength for high throughput applications.

Source record↗
NASA NTRS2008

Sensitivity of Hollow Fiber Spacesuit Water Membrane Evaporator Systems to Potable Water Constituents, Contaminants and Air Bubbles

The Spacesuit Water Membrane Evaporator (SWME) is the baseline heat rejection technology selected for development for the Constellation lunar suit. The first SWME prototype, designed, built, and tested at Johnson Space Center in 1999 used a Teflon hydrophobic porous membrane sheet shaped into an annulus to provide cooling to the coolant loop through water evaporation to the vacuum of space. This present study describes the test methodology and planning and compares the test performance of three commercially available hollow fiber materials as alternatives to the sheet membrane prototype for SWME, in particular, a porous hydrophobic polypropylene, and two variants that employ ion exchange through non-porous hydrophilic modified Nafion. Contamination tests will be performed to probe for sensitivities of the candidate SWME elements to ordinary constituents that are expected to be found in the potable water provided by the vehicle, the target feedwater source. Some of the impurities in potable water are volatile, such as the organics, while others, such as the metals and inorganic ions are nonvolatile. The non-volatile constituents will concentrate in the SWME as evaporated water from the loop is replaced by the feedwater. At some point in the SWME mission lifecycle as the concentrations of the non-volatiles increase, the solubility limits of one or more of the constituents may be reached. The resulting presence of precipitate in the coolant water may begin to plug pores and tube channels and affect the SWME performance. Sensitivity to macroparticles, lunar dust simulant, and air bubbles will also be investigated.

Bue, Grant C.↗
NASA NTRS2008

Implementation of Integrated System Fault Management Capability

Fault Management to support rocket engine test mission with highly reliable and accurate measurements; while improving availability and lifecycle costs. CORE ELEMENTS: Architecture, taxonomy, and ontology (ATO) for DIaK management. Intelligent Sensor Processes; Intelligent Element Processes; Intelligent Controllers; Intelligent Subsystem Processes; Intelligent System Processes; Intelligent Component Processes.

Figueroa, Fernando↗