Search NASASearch

SEARCH · Search NASA

Results for “product development”

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

Effective Schedule and Cost Management as a Product Development Lead

The presentation will be given at the 26th Annual Thermal Fluids Analysis Workshop (TFAWS 2015) hosted by the Goddard SpaceFlight Center (GSFC) Thermal Engineering Branch (Code 545). This course provides best practices, helpful tools and lessons learned for staying on plan and day-to-day management of Subsystem flight development after getting Project approval for your Subsystem schedule and budget baseline.

Schedule

The 2GCHAS: A high productivity software development environment

To the user, the most visible feature of the Transportable Applications Executive (TAE) is its very powerful user interface. To the programmer, TAE's user interface, proc concept, standardized interface definitions, and hierarchy search provide a set of tools for rapidly prototyping or developing production software. The 2GCHAS (Second Generation Comprehensive Helicopter Analysis System) project has extended and enhanced these mechanisms, creating a powerful and high productivity programming environment where the 2GCHAS development environment is 2GCHAS itself and where a sustained rate for certified, documented, and tested software above 30 delivered source instructions per programmer day has been achieved. The 2GCHAS environment is not limited to helicopter analysis, but is applicable to other disciplines where software development is important.

Babb, Larry

Constructing the 'Best' Reliability Data for the Job - Developing Generic Reliability Data from Alternative Sources Early in a Product's Development Phase

Reliability practitioners advocate getting reliability involved early in a product development process. However, when assigned to estimate or assess the (potential) reliability of a product or system early in the design and development phase, they are faced with lack of reasonable models or methods for useful reliability estimation. Developing specific data is costly and time consuming. Instead, analysts rely on available data to assess reliability. Finding data relevant to the specific use and environment for any project is difficult, if not impossible. Instead, analysts attempt to develop the "best" or composite analog data to support the assessments. Industries, consortia and vendors across many areas have spent decades collecting, analyzing and tabulating fielded item and component reliability performance in terms of observed failures and operational use. This data resource provides a huge compendium of information for potential use, but can also be compartmented by industry, difficult to find out about, access, or manipulate. One method used incorporates processes for reviewing these existing data sources and identifying the available information based on similar equipment, then using that generic data to derive an analog composite. Dissimilarities in equipment descriptions, environment of intended use, quality and even failure modes impact the "best" data incorporated in an analog composite. Once developed, this composite analog data provides a "better" representation of the reliability of the equipment or component. It can be used to support early risk or reliability trade studies, or analytical models to establish the predicted reliability data points. It also establishes a baseline prior that may updated based on test data or observed operational constraints and failures, i.e., using Bayesian techniques. This tutorial presents a descriptive compilation of historical data sources across numerous industries and disciplines, along with examples of contents and data characteristics. It then presents methods for combining failure information from different sources and mathematical use of this data in early reliability estimation and analyses.

Kleinhammer, Roger K.

Fostering Better Collaboration in Software Development Cycles Between Scientists and Programmers to Ensure the Integrity of and Promote the Development of New Scientific Data Products.

Misaligned incentives lead to reduced interaction between scientists and programmers on modern NASA science data-product development teams. Typically, situations arise where the scientist is not incentivized to learn modern coding practices and the programmer does not understand the science algorithms in the code. A programmer is responsible for the deliverable code thus setting a tradeoff between the desire for code improvement versus fear of compromising the integrity of data-product while the scientist continues to rely on their legacy codebases owing to the complexity of using the delivered code outside the processing environment and lack of validation modules. The NASA/CERES-TISA project has adopted a collaborative approach, with scientists and programmers both utilizing the same software repository with multiple branches, some optimized for delivery to a processing datacenter and others for scientific product development and validation. A team of scientists and programmers jointly review any new science code updates for integration into the codebase and strive to improve practices through promoting algorithm understanding, better institutional knowledge exchange and documentation, modularization, and developing data processing flow-dictated validation and debugging methods. This leads to a reduction in the personnel single point failures and reduced development time for creation of new science data-products.

CERES

Multijunction Solar Cell Development and Production at Spectrolab

Development of multijunction space solar cells is much like that for any high technology product. New products face two major pressures from the market: improving performance while maintaining heritage. This duality of purpose is not new and has been represented since ancient times by the Roman god Janus.[1] This deity was typically represented as two faces on a single head: one facing forward and the other to the rear. The image of Janus has been used as symbolism for many combined forces of dual purpose, such as the balance in life between beginnings and endings, or between art and science. For our purposes, Janus represents our design philosophy balance between looking to the future for improvement while simultaneously blending past heritage. In the space photovoltaics industry there are good reasons for both purposes. Looking to the past, a product must have a space flight heritage to gain widespread use. The main reason being that this is an unforgiving business. Spacecraft are expensive to build, launch and operate. Typically once a satellite is launched, in-field service for a power systems problem is near impossible.[2Balanced with this is looking forward. New missions typically require more power than previous programs or attempt new objectives such as a new orbit. And there is always the cost pressure for both the satellite itself as well as the launch costs. Both of which push solar technology to improve power density at a lower cost. The consequence of this balance in a high-risk environment is that space PV develops as a series of infrequent large technology steps or generational changes interspersed with more frequent small technology steps or evolutionary changes. Figure 1 gives a bit of clarification on this point. It depicts the historical progress in space solar cells tracked by efficiency against first launch date for most major products introduced by Spectrolab. The first generation is the Si-based technology reaching a peak values near 15% AM0 (herein denoted for max. power, AM0, 1.353 W/cm2, 28 C). The GaAs single junction device generation supplanted this technology with first flight of GaAs on GaAs substrate in 1982.[3] More recently this generation has been supplanted by the multijunction solar cell GaInP/GaAs/Ge generation. The first launch of a commercial satellite powered by multijunction technology was in 1997 (Hughes HS 601HP) using solar arrays based on Spectrolab s dual junction (DJ) cells. The cells at that time were an impressive 21.5% efficient at beginning-of-life (BOL).[4] Eight years later, the multijunction device has evolved through several versions. The incorporation of an active Ge subcell formed the Triple Junction (TJ) product line at 25.1% efficient, on orbit since November 2001. The evolution of the TJ into the Improved Triple Junction (ITJ) at 26.8% efficient has been on orbit since June of 2002.[5]

Fetzer, Chris

Utilization of Ancillary Data Sets for SMAP Algorithm Development and Product Generation

Algorithms being developed for the Soil Moisture Active Passive (SMAP) mission require a variety of both static and ancillary data. The selection of the most appropriate source for each ancillary data parameter is driven by a number of considerations, including accuracy, latency, availability, and consistency across all SMAP products and with SMOS (Soil Moisture Ocean Salinity). It is anticipated that initial selection of all ancillary datasets, which are needed for ongoing algorithm development activities on the SMAP algorithm testbed at JPL, will be completed within the year. These datasets will be updated as new or improved sources become available, and all selections and changes will be documented for the benefit of the user community. Wise choices in ancillary data will help to enable SMAP to provide new global measurements of soil moisture and freeze/thaw state at the targeted accuracy necessary to tackle hydrologically-relevant societal issues.

ONeill, P.

Collaborative, Sequential and Isolated Decisions in Design

The Massachusetts Institute of Technology (MIT) Commission on Industrial Productivity, in their report Made in America, found that six recurring weaknesses were hampering American manufacturing industries. The two weaknesses most relevant to product development were 1) technological weakness in development and production, and 2) failures in cooperation. The remedies to these weaknesses are considered the essential twin pillars of CE: 1) improved development process, and 2) closer cooperation. In the MIT report, it is recognized that total cooperation among teams in a CE environment is rare in American industry, while the majority of the design research in mathematically modeling CE has assumed total cooperation. In this paper, we present mathematical constructs, based on game theoretic principles, to model degrees of collaboration characterized by approximate cooperation, sequential decision making and isolation. The design of a pressure vessel and a passenger aircraft are included as illustrative examples.

Lewis, Kemper

CRADA Number NFE-21-08879 with Hempitecture Inc. (CRADA Final Report)

Participant is a company that was founded on the idea that sustainable materials can help build a better world. These materials can build a better world by preserving our health, saving energy, and storing carbon dioxide. Participant is at a critical juncture where it has significant sales and manufacturing capabilities that can bring innovative, low-carbon, hemp-based building products to market at scale in the United States, but the company has lacked the time and resources to conduct new product development and testing. At Innovation Crossroads, Participant plans to prototype, test, and develop its product roadmap while obtaining necessary performance and impact measurements of its hemp building products for commercialization. Coming into Innovation Crossroads, only one of Participant’s products has commercial sales, HempWool®. Investments are currently being made to add manufacturing capacity in the United States and to provide Participant with the capability to expand its product line throughout the building envelope.

36 MATERIALS SCIENCE

Influence of Design Variations on Systems Performance

High-risk aerospace components have to meet very stringent quality, performance, and safety requirements. Any source of variation is a concern, as it may result in scrap or rework. poor performance, and potentially unsafe flying conditions. The sources of variation during product development, including design, manufacturing, and assembly, and during operation are shown. Sources of static and dynamic variation during development need to be detected accurately in order to prevent failure when the components are placed in operation. The Systems' Health and Safety (SHAS) research at the NASA Ames Research Center addresses the problem of detecting and evaluating the statistical variation in helicopter transmissions. In this work, we focus on the variations caused by design, manufacturing, and assembly of these components, prior to being placed in operation (DMV). In particular, we aim to understand and represent the failure and variation information, and their correlation to performance and safety and feed this information back into the development cycle at an early stage. The feedback of such critical information will assure the development of more reliable components with less rework and scrap. Variations during design and manufacturing are a common source of concern in the development and production of such components. Accounting for these variations, especially those that have the potential to affect performance, is accomplished in a variety ways, including Taguchi methods, FMEA, quality control, statistical process control, and variation risk management. In this work, we start with the assumption that any of these variations can be represented mathematically, and accounted for by using analytical tools incorporating these mathematical representations. In this paper, we concentrate on variations that are introduced during design. Variations introduced during manufacturing are investigated in parallel work.

Tumer, Irem Y.

The Analysis of the Contribution of Human Factors to the In-Flight Loss of Control Accidents

In-flight loss of control (LOC) is currently the leading cause of fatal accidents based on various commercial aircraft accident statistics. As the Next Generation Air Transportation System (NextGen) emerges, new contributing factors leading to LOC are anticipated. The NASA Aviation Safety Program (AvSP), along with other aviation agencies and communities are actively developing safety products to mitigate the LOC risk. This paper discusses the approach used to construct a generic integrated LOC accident framework (LOCAF) model based on a detailed review of LOC accidents over the past two decades. The LOCAF model is comprised of causal factors from the domain of human factors, aircraft system component failures, and atmospheric environment. The multiple interdependent causal factors are expressed in an Object-Oriented Bayesian belief network. In addition to predicting the likelihood of LOC accident occurrence, the system-level integrated LOCAF model is able to evaluate the impact of new safety technology products developed in AvSP. This provides valuable information to decision makers in strategizing NASA's aviation safety technology portfolio. The focus of this paper is on the analysis of human causal factors in the model, including the contributions from flight crew and maintenance workers. The Human Factors Analysis and Classification System (HFACS) taxonomy was used to develop human related causal factors. The preliminary results from the baseline LOCAF model are also presented.

Ancel, Ersin

Modeling Code Is Helping Cleveland Develop New Products

Master Builders, Inc., is a 350-person company in Cleveland, Ohio, that develops and markets specialty chemicals for the construction industry. Developing new products involves creating many potential samples and running numerous tests to characterize the samples' performance. Company engineers enlisted NASA's help to replace cumbersome physical testing with computer modeling of the samples' behavior. Since the NASA Lewis Research Center's Structures Division develops mathematical models and associated computation tools to analyze the deformation and failure of composite materials, its researchers began a two-phase effort to modify Lewis' Integrated Composite Analyzer (ICAN) software for Master Builders' use. Phase I has been completed, and Master Builders is pleased with the results. The company is now working to begin implementation of Phase II.

Source record