Search NASA⌕ Search

SEARCH · Search NASA

Results for “software differences”

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 451 records · Page 25

Implementation of J-A Methodology Elastic-Plastic Crack Instability Analysis Capability into the WARP-3D Code

Characterization of the near crack-tip stress/strain fields is the foundation of fracture mechanics. The description of the near tip stress field and the prediction of when fracture occurs is well established for brittle materials that exhibit linear elastic behavior. However, in ductile materials or conditions that violate linear elastic assumptions (Aluminum alloys, Al 2024-T3, Al 2024- T351 etc.), the elastic-plastic crack-tip stress fields are characterized by the Hutchison-Rice-Rosengren (HRR) field. The J-integral is commonly used to characterize amplitude of the HRR field under elastic-plastic conditions. The J-integral has been demonstrated for crack-tip fields that are under high constraint conditions (i.e., small-scale plasticity where the J-dominance is maintained). However, as the external load increases, yielding changes from small- to largescale plasticity and usually a loss of constraint (i.e., reduction in the triaxial stress field along the crack front). The loss of constraint leads to the deviation of the crack-tip stress fields from that given by the HRR field. Hence, the J-dominance will be gradually lost and additional parameter(s) are required to quantify the crack-tip stress fields and predict fracture behavior. The assessment objectives were to: 1) implement a two-parameter (i.e., J-A) fracture criterion into an elastic-plastic three-dimensional (3D) finite element analysis (FEA), 2) validate the implementation by comparison with the A parameter from literature data, 3) conduct material characterization tests to quantify the material behavior and provide fracture data for validation of the J-A fracture criteria, and (4) perform evaluations to establish if the J-A criteria can be used to predict fracture in a ductile metallic material (e.g., aluminum alloys). The A parameter in these criteria is the second parameter in a three-term elastic-plastic asymptotic expansion of the neartip stress behavior. A series of extensive FEAs were performed using WARP3D software package to obtain solutions for the A parameter for different specimen configurations. The methodology needed for the estimation of the A parameter in the asymptotic expansion was developed and implemented using Matlab®. A user material (UMAT) routine was used to model the material stress-strain response using a Ramberg-Osgood power law with a hardening exponent (n) and a material coefficient (alpha). This UMAT routine was successfully implemented in WARP3D software and validated through comparison with the experimental data. Three configurations were extracted from published results: 1) center cracked plate (CCP), 2) single edge-cracked plate (SECP), and 3) double edge-cracked plate (DECP). These configurations and four other configurations (three-hole tension (THT)), three-point bend (3PTB), three-hole compact tension (3PCT), and compact tension (CT)) were analyzed to verify the methodology that was developed and implemented into WARP3D. Solutions of the A parameter were obtained for remote tension loading conditions that started with small-scale yielding and continued into the large-scale plasticity regime. The results indicate that the methodology developed can be used to calculate the elastic-plastic J-A parameters for test specimens with a range of crack geometries, material strain hardening behaviors, and loading conditions. The J-A parameters were implemented as fracture criteria and used to predict the test results. For comparison, other fracture criteria were used to predict the same test results. Major findings include: The A constraint parameter A varies with specimen type and applied load thus accurate determination is crucial in predicting the failure load, and the A parameter is asymptotic as the failure load is approached, making an accurate determination difficult (i.e., small differences in the A parameter can cause large variations in failure load) for materials exhibiting elastic-plastic behavior. The failure predictions from J-A methodology were more accurate than the traditionally used KC and J methods, and have comparable scatter to that observed when using the crack-tip opening angle (CTOA) method. However, the J-A methodology requires considerable effort (expertise level and labor) to implement and to evaluate the A parameter for different specimen types and materials, or to apply this methodology to part-through crack (e.g., 3D problems) structural applications.

Hamm, Kenneth R., Jr.↗

New literal approximations for the longitudinal dynamic characteristics of flexible flight vehicles

The goal of the literal approximation method is to obtain simple literal (analytical) approximations for key dynamic characteristics of flexible flight vehicles. A basic question regarding the method is its usefulness as an additional design tool for existing design and simulation procedures. Two aspects of this question are: (1) ease of derivation and use of the literal approximations, and (2) the suitability of one set of literal approximations to describe the dynamics of a large set of significantly different vehicles. These issues are addressed by incorporating symbolic manipulation software into the literal approximation method for the analysis of a fifth order model of the longitudinal dynamics of a flexible flight vehicle. The automated literal approximation generated in this fashion reduces the manual derivation time by an approximate factor of four. A single set of literal approximations is shown to provide adequate approximations for the dynamics of significantly different flight vehicles configurations, such as an aircraft, a missile, and a hypersonic vehicle.

Livneh, Rafael↗

ELISA, a demonstrator environment for information systems architecture design

This paper describes an approach of reusability of software engineering technology in the area of ground space system design. System engineers have lots of needs similar to software developers: sharing of a common data base, capitalization of knowledge, definition of a common design process, communication between different technical domains. Moreover system designers need to simulate dynamically their system as early as possible. Software development environments, methods and tools now become operational and widely used. Their architecture is based on a unique object base, a set of common management services and they host a family of tools for each life cycle activity. In late '92, CNES decided to develop a demonstrative software environment supporting some system activities. The design of ground space data processing systems was chosen as the application domain. ELISA (Integrated Software Environment for Architectures Specification) was specified as a 'demonstrator', i.e. a sufficient basis for demonstrations, evaluation and future operational enhancements. A process with three phases was implemented: system requirements definition, design of system architectures models, and selection of physical architectures. Each phase is composed of several activities that can be performed in parallel, with the provision of Commercial Off the Shelves Tools. ELISA has been delivered to CNES in January 94, currently used for demonstrations and evaluations on real projects (e.g. SPOT4 Satellite Control Center). It is on the way of new evolutions.

Panem, Chantal↗

The need for a comprehensive expert system development methodology

In a traditional software development environment, the introduction of standardized approaches has led to higher quality, maintainable products on the technical side and greater visibility into the status of the effort on the management side. This study examined expert system development to determine whether it differed enough from traditional systems to warrant a reevaluation of current software development methodologies. Its purpose was to identify areas of similarity with traditional software development and areas requiring tailoring to the unique needs of expert systems. A second purpose was to determine whether existing expert system development methodologies meet the needs of expert system development, management, and maintenance personnel. The study consisted of a literature search and personal interviews. It was determined that existing methodologies and approaches to developing expert systems are not comprehensive nor are they easily applied, especially to cradle to grave system development. As a result, requirements were derived for an expert system development methodology and an initial annotated outline derived for such a methodology.

Baumert, John↗

An Innovative Approach to Modeling VIPER Rover Software Life Cycle Cost

NASA’s “Volatiles Investigating Polar Exploration Rover” (VIPER) will be the first robotic mission to prospect for water ice near the south pole of the Moon in late 2023 on a 100-Earth-day mission. The information that the VIPER rover provides will help improve understanding of the composition, distribution, and accessibility of Lunar polar volatiles and will help determine how the Moon’s resources can support future human space exploration. VIPER, however, represents a radical departure from the way that NASA has traditionally developed planetary robotic missions. A key consequence of these differences is that estimating the cost of VIPER’s rover software is challenging and complex.For example, VIPER is being developed using management procedures typically applied to NASA research and technology projects, rather than space flight programs. In addition, key portions of the rover’s software are being designed as ground software to run on mission control computers (rather than on-board the rover as flight software as with prior planetary missions) taking advantage of continuous, interactive data communications between the Moon and Earth and higher performance computing available on the ground. Moreover, the rover’s software is being engineered using Agile software development practices and incorporates a significant amount of open-source, rather than following traditional (spiral, waterfall, etc.) development methods and in-house code. In this paper, we present an innovative process to estimate the life cycle cost of VIPER’s rover software. We first describe how we modeled the architecture and code counts for three software elements: Rover Flight Software (RFSW), Rover Ground Software (RGSW), and Rover Simulation Software (RSIM). We then discuss key challenges and unique aspects of our approach, such as the lack of Lunar rover analogies, the need to integrate and test large open source software, and the strategies developed to account for use of non-space flight management practices and the impact of the COVID-19 pandemic. We conclude with a summary of our results, including cumulative distribution, nearest neighbors and cluster analysis, as well as heuristics used to confirm the reasonableness of the cost estimate.

Utz, Hans↗

Software-Engineering Process Simulation (SEPS) model

The Software Engineering Process Simulation (SEPS) model is described which was developed at JPL. SEPS is a dynamic simulation model of the software project development process. It uses the feedback principles of system dynamics to simulate the dynamic interactions among various software life cycle development activities and management decision making processes. The model is designed to be a planning tool to examine tradeoffs of cost, schedule, and functionality, and to test the implications of different managerial policies on a project's outcome. Furthermore, SEPS will enable software managers to gain a better understanding of the dynamics of software project development and perform postmodern assessments.

Lin, C. Y.↗

Developing Information Power Grid Based Algorithms and Software

This was an exploratory study to enhance our understanding of problems involved in developing large scale applications in a heterogeneous distributed environment. It is likely that the large scale applications of the future will be built by coupling specialized computational modules together. For example, efforts now exist to couple ocean and atmospheric prediction codes to simulate a more complete climate system. These two applications differ in many respects. They have different grids, the data is in different unit systems and the algorithms for inte,-rating in time are different. In addition the code for each application is likely to have been developed on different architectures and tend to have poor performance when run on an architecture for which the code was not designed, if it runs at all. Architectural differences may also induce differences in data representation which effect precision and convergence criteria as well as data transfer issues. In order to couple such dissimilar codes some form of translation must be present. This translation should be able to handle interpolation from one grid to another as well as construction of the correct data field in the correct units from available data. Even if a code is to be developed from scratch, a modular approach will likely be followed in that standard scientific packages will be used to do the more mundane tasks such as linear algebra or Fourier transform operations. This approach allows the developers to concentrate on their science rather than becoming experts in linear algebra or signal processing. Problems associated with this development approach include difficulties associated with data extraction and translation from one module to another, module performance on different nodal architectures, and others. In addition to these data and software issues there exists operational issues such as platform stability and resource management.

Dongarra, Jack↗

An Engineering Data Management System for Ipad

An overview of the capabilities and software architecture of the IPAD information processor (IPIP) is presented. IPIP is a state-of-the-art data base management system that satisfies engineering requirements not addressed by present day commercial systems. It also significantly advances a number of capabilities that are offered commercially. IPIP capabilities range from support for multiple schemas and data models to support for distributed processing, configuration control, and data inventory management. IPIP exploits semantic commonality in features offered in various forms at different user interfaces in today's commercial systems. An integrated software architecture supports all user interfaces: programming languages, interactive data manipulation, and schema languages. This approach promotes simplicity and compactness in software and permits features to be offered symmetrically across all appropriate user interfaces.

H R Johnson↗

Benefits and Challenges of Model-based Software Engineering: Lessons Learned based on Qualitative and Quantitative Findings

Even though Model-based Software Engineering (MBSwE) techniques and Autogenerated Code (AGC) have been increasingly used to produce complex software systems, there is only anecdotal knowledge about the state-of-thepractice. Furthermore, there is a lack of empirical studies that explore the potential quality improvements due to the use of these techniques. This paper presents in-depth qualitative findings about development and Software Assurance (SWA) practices and detailed quantitative analysis of software bug reports of a NASA mission that used MBSwE and AGC. The mission’s flight software is a combination of handwritten code and AGC developed by two different approaches: one based on state chart models (AGC-M) and another on specification dictionaries (AGC-D). The empirical analysis of fault proneness is based on 380 closed bug reports created by software developers. Our main findings include: (1) MBSwE and AGC provide some benefits, but also impose challenges. (2) SWA done only at a model level is not sufficient. AGC code should also be tested and the models and AGC should always be kept in-sync. AGC must not be changed manually. (3) Fixes made to address an individual bug report were spread both across multiple modules and across multiple files. On average, for each bug report 1.4 modules, that is, 3.4 files were fixed. (4) Most bug reports led to changes in more than one type of file. The majority of changes to auto-generated source code files were made in conjunction to changes in either file with state chart models or XML files derived from dictionaries. (5) For newly developed files, AGC-M and handwritten code were of similar quality, while AGC-D files were the least fault prone.

Goseva-Popstojanova, Katerina↗

Discovering Recurring Anomalies in Text Reports Regarding Complex Space Systems

Many existing complex space systems have a significant amount of historical maintenance and problem data bases that are stored in unstructured text forms. For some platforms, these reports may be encoded as scanned images rather than even searchable text. The problem that we address in this paper is the discovery of recurring anomalies and relationships between different problem reports that may indicate larger systemic problems. We will illustrate our techniques on data from discrepancy reports regarding software anomalies in the Space Shuttle. These free text reports are written by a number of different penp!e, thus the emphasis and wording varies considerably.

Zane-Ulman, Brett↗

Leading Edge Software Support

The purpose of this paper is an attempt to get the reader to recognize that different requirements that are surfacing and to be proactive in achieving successful support of these systems. This paper will identify areas of concern and present some areas of focus applicable to the development and support of software intensive systems.

Baylis, William T.↗

Experiments with conjugate gradient algorithms for homotopy curve tracking

There are algorithms for finding zeros or fixed points of nonlinear systems of equations that are globally convergent for almost all starting points, i.e., with probability one. The essence of all such algorithms is the construction of an appropriate homotopy map and then tracking some smooth curve in the zero set of this homotopy map. HOMPACK is a mathematical software package implementing globally convergent homotopy algorithms with three different techniques for tracking a homotopy zero curve, and has separate routines for dense and sparse Jacobian matrices. The HOMPACK algorithms for sparse Jacobian matrices use a preconditioned conjugate gradient algorithm for the computation of the kernel of the homotopy Jacobian matrix, a required linear algebra step for homotopy curve tracking. Here, variants of the conjugate gradient algorithm are implemented in the context of homotopy curve tracking and compared with Craig's preconditioned conjugate gradient method used in HOMPACK. The test problems used include actual large scale, sparse structural mechanics problems.

Irani, Kashmira M.↗

ART/Ada design project, phase 1. Task 1 report: Overall design

The design methodology for the ART/Ada project is introduced, and the selected design for ART/Ada is described in detail. The following topics are included: object-oriented design, reusable software, documentation techniques, impact of Ada, design approach, and differences between ART-IM 1.5 and ART/Ada 1.0 prototype. Also, Ada generator and ART/Ada runtime systems are discussed.

Allen, Bradley P.↗

The Management and Security Expert (MASE)

The Management and Security Expert (MASE) is a distributed expert system that monitors the operating systems and applications of a network. It is capable of gleaning the information provided by the different operating systems in order to optimize hardware and software performance; recognize potential hardware and/or software failure, and either repair the problem before it becomes an emergency, or notify the systems manager of the problem; and monitor applications and known security holes for indications of an intruder or virus. MASE can eradicate much of the guess work of system management.

Miller, Mark D.↗

Probe For Measuring Dynamic Gas Temperature In Reversing Flows

In proposed technique for determining time-varying temperature of flowing gas, raw measurements of three thermocouples of different sizes processed by relatively simple data-reduction software. Three-thermocouple technique overcomes limitation of single-thermocouple technique.

Fralick, Gustave C.↗

STEP: A Futurevision, Today

STEP (STandard for the Exchange of Product Model Data) is an innovative software tool that allows the exchange of data between different programming systems to occur and helps speed up the designing in various process industries. This exchange occurs easily between those companies that have STEP, and many industries and government agencies are requiring that their vendors utilize STEP in their computer aided design projects, such as in the areas of mechanical, aeronautical, and electrical engineering. STEP allows the process of concurrent engineering to occur and increases the quality of the design product. One example of the STEP program is the Boeing 777, the first paperless airplane.

Source record↗

Comparing the OpenMP, MPI, and Hybrid Programming Paradigm on an SMP Cluster

Clusters of SMP (Symmetric Multi-Processors) nodes provide support for a wide range of parallel programming paradigms. The shared address space within each node is suitable for OpenMP parallelization. Message passing can be employed within and across the nodes of a cluster. Multiple levels of parallelism can be achieved by combining message passing and OpenMP parallelization. Which programming paradigm is the best will depend on the nature of the given problem, the hardware components of the cluster, the network, and the available software. In this study we compare the performance of different implementations of the same CFD benchmark application, using the same numerical algorithm but employing different programming paradigms.

Jost, Gabriele↗

Autonomous Sciencecraft Experiment (ASE) Test Operations in 2003

NASA has identified the development of an autonomously operating spacecraft as a necessity for an expanded program of missions exploring the Solar System. The Autonomous Sciencecraft Experiment (ASE) has been selected for flight demonstration by NASA s New Millennium Program (NMP) as part of the Space Technology 6 (ST6) mission. ASE is scheduled to fly on the US Air Force Research Laboratory (AFRL) Techsat-21 constellation in 2006. Tech- Sat-21 consists of three satellites flying in a variable-geometry formation in Earth orbit. Each satellite is equipped with X-band Synthetic Aperture Radar, yielding high spatial resolution images (approx. 3 m) of the Earth s surface. The constellation will fly at an altitude of 550 km, in a 35.4 inclination circular orbit, yielding exact repeat-track observations every 13 days. Prior to full deployment, elements of the versatile ASE spacecraft command and control software, image formation software and science processing software will be utilized and tested on two very different platforms in 2003: AirSAR and EO-1 (described below). Advantages of Autonomous Operations: ASE will demonstrate advanced autonomous science data acquisition, processing, and product downlink prioritization, as well as autonomous spacecraft command and control, and fault detection. The advantages of spacecraft autonomy are to future missions include: (a) making the best use of reduced downlink; (b) the overcoming of communication delays through decisionmaking in situ, enabling fast reaction to dynamic events; (c) an increase of science content per byte of returned data; and (d) an avoidance of return of null (no-change/no feature) datasets: if there is no change detectable between two scenes of the same target, there is no need to return the second dataset.

Chien, S.↗