Engineering Papers⌕ Search

SEARCH · Engineering Papers

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 757 records · Page 42
All sourcesNASA NTRSDOE OSTI
NASA NTRS2013

Two Mechanisms to Avoid Control Conflicts Resulting from Uncoordinated Intent

This software implements a real-time access control protocol that is intended to make all connected users aware of the presence of other connected users, and which of them is currently in control of the system. Here, "in control" means that a single user is authorized and enabled to issue instructions to the system. The software The software also implements a goal scheduling mechanism that can detect situations where plans for the operation of a target system proposed by different users overlap and interact in conflicting ways. In such situations, the system can either simply report the conflict (rejecting one goal or the entire plan), or reschedule the goals in a way that does not conflict. The access control mechanism (and associated control protocol) is unique. Other access control mechanisms are generally intended to authenticate users, or exclude unauthorized access. This software does neither, and would likely depend on having some other mechanism to support those requirements.

Mishkin, Andrew H.↗
NASA NTRS2025

Modeling and Simulation Credibility Assessments of Musculoskeletal Computational Models for Simulating Astronaut Injuries Due to a Poor Spacesuit Fit

The musculoskeletal (MS) system of astronauts is subject to physiological changes, potentially leading to injuries due to the exposure to different gravitational environments experienced during spaceflight. These injuries can occur while an astronaut is performing an Extravehicular Activity (EVA) in space, on lunar or planetary surfaces or while wearing a spacesuit during terrestrial training for an EVA. The OpenSim MS modeling software can assess EVA induced MS injury mechanisms such as muscle strains, ligament injuries and joint injuries. One area of concern, since there are only a few different spacesuit sizes with limited adjustability, is the possibility of a poorly fitting spacesuit. This can cause unnatural joint motions and torques resulting in various MS injuries. A credibility assessment of the OpenSim modeling and simulation procedures is performed per NASA-STD-7009A to provide information on the credibility of the model’s use in simulating EVA related injury mechanisms. The credibility assessment evaluated various OpenSim models against the following eight credibility factors: data pedigree, input pedigree, code verification, solution verification, conceptual validation, referent validation, results uncertainty and results robustness (sensitivity). The models evaluated for EVA injuries will require additional credibility factor analysis and upgrades to the model features, such as adding ligaments to a whole-body model, to reliably predict and analyze the EVA injuries expected to occur due to a poor spacesuit fit. The degree of elevation strategy required to increase the credibility assessment scores will depend on the model complexity and the injury mechanism.

Christopher A. Gallo↗
NASA NTRS2024

Modeling and Simulation Credibility Assessments of Musculoskeletal Computational Models for Simulating Astronaut Injuries Due to a Poor Spacesuit Fit

The musculoskeletal (MS) system of astronauts is subject to physiological changes, potentially leading to injuries due to the exposure to different gravitational environments experienced during spaceflight. These injuries can occur while an astronaut is performing an Extravehicular Activity (EVA) in space, on lunar or planetary surfaces or while wearing a spacesuit during terrestrial training for an EVA. The OpenSim MS modeling software can assess EVA induced MS injury mechanisms such as muscle strains, ligament injuries and joint injuries. One area of concern, since there are only a few different spacesuit sizes with limited adjustability, is the possibility of a poorly fitting spacesuit. This can cause unnatural joint motions and torques resulting in various MS injuries. A credibility assessment of the OpenSim modeling and simulation procedures is performed per NASA-STD-7009A to provide information on the credibility of the model’s use in simulating EVA related injury mechanisms. The credibility assessment evaluated various OpenSim models against the following eight credibility factors: data pedigree, input pedigree, code verification, solution verification, conceptual validation, referent validation, results uncertainty and results robustness (sensitivity). The models evaluated for EVA injuries will require additional credibility factor analysis and upgrades to the model features, such as adding ligaments to a whole-body model, to reliably predict and analyze the EVA injuries expected to occur due to a poor spacesuit fit. The degree of elevation strategy required to increase the credibility assessment scores will depend on the model complexity and the injury mechanism.

Christopher A Gallo↗
NASA NTRS2000

Software Released by LEWICE 2.0 Ice Accretion Software Development Project

Computational icing simulation methods are making the transition from the realm of research to commonplace use in design and certification. As such, standards of software management, design, validation, and documentation must be adjusted to accommodate the increased expectations of the user community with respect to accuracy, reliability, capability, and usability. With this in mind, in collaboration with Glenn's Engineering Design and Analysis Division, the Icing Branch of the NASA Glenn Research Center at Lewis Field began a software improvement project focused on the two-dimensional ice accretion simulation tool LEWICE. This project is serving as an introduction to the concepts of software management and is intended to serve as a pilot project for future icing simulation code development. The LEWICE 2.0 Software Development Project consisted of two major elements: software management and software validation. The software management element consisted of identifying features of well-designed and well-managed software that are appropriate for an analytical prediction tool such as LEWICE and applying them to a revised version of the code. This element included tasks such as identification of software requirements, development and implementation of coding standards, and implementation of software revision control practices. With the application of these techniques, the LEWICE ice accretion code became a more stable and reliable software product. In addition, the lessons learned about software development and maintenance can be factored into future software projects at the outset. The software validation activity was an integral part of our effort to make LEWICE a more accurate and reliable analysis tool. Because of the efforts taken to extensively validate this software, LEWICE 2.0 is more robust than previous releases and can reproduce results accurately across several computing platforms. It also differs from previous versions in the extensive quantitative comparisons of its results with a data base of ice shapes that were generated in Glenn's Icing Research Tunnel. The results of the shape comparisons were analyzed to determine the range of meteorological conditions under which LEWICE 2.0 is within the repeatability found for ice shapes obtained from experiments. These comparisons show that the average variation of LEWICE 2.0 from experimental data is 7.2 percent, whereas the overall variability of the experimental data is 2.5 percent. The LEWICE 2.0 Software Development Project resulted in the release, at the recent Icing Branch LEWICE Workshop, of a more useful and robust analysis tool than was previously available to the icing community. The lessons learned from this project will be applied to the Icing Branch s future software development efforts.

Potapczuk, Mark G.↗
NASA NTRS2011

Content Documents Management

The Content Documents are created and managed under the System Software group with. Launch Control System (LCS) project. The System Software product group is lead by NASA Engineering Control and Data Systems branch (NE~C3) at Kennedy Space Center. The team is working on creating Operating System Images (OSI) for different platforms (i.e. AIX, Linux, Solaris and Windows). Before the OSI can be created, the team must create a Content Document which provides the information of a workstation or server, with the list of all the software that is to be installed on it and also the set where the hardware belongs. This can be for example in the LDS, the ADS or the FR-l. The objective of this project is to create a User Interface Web application that can manage the information of the Content Documents, with all the correct validations and filters for administrator purposes. For this project we used one of the most excellent tools in agile development applications called Ruby on Rails. This tool helps pragmatic programmers develop Web applications with Rails framework and Ruby programming language. It is very amazing to see how a student can learn about OOP features with the Ruby language, manage the user interface with HTML and CSS, create associations and queries with gems, manage databases and run a server with MYSQL, run shell commands with command prompt and create Web frameworks with Rails. All of this in a real world project and in just fifteen weeks!

Muniz, R.↗
NASA NTRS2006

Titan Explorer Entry, Descent and Landing Trajectory Design

The Titan Explorer mission concept includes an orbiter, entry probe and inflatable airship designed to take remote and in-situ measurements of Titan's atmosphere. A modified entry, descent and landing trajectory at Titan that incorporates mid-air airship inflation (under a parachute) and separation is developed and examined for Titan Explorer. The feasibility of mid-air inflation and deployment of an airship under a parachute is determined by implementing and validating an airship buoyancy and inflation model in the trajectory simulation program, Program to Optimize Simulated Trajectories II (POST2). A nominal POST2 trajectory simulation case study is generated which examines different descent scenarios by varying airship inflation duration, orientation, and separation. The buoyancy model incorporation into POST2 is new to the software and may be used in future trajectory simulations. Each case from the nominal POST2 trajectory case study simulates a successful separation between the parachute and airship systems with sufficient velocity change as to alter their paths to avoid collision throughout their descent. The airship and heatshield also separate acceptably with a minimum distance of separation from the parachute system of 1.5 km. This analysis shows the feasibility of airship inflation on a parachute for different orientations, airship separation at various inflation times, and preparation for level-flight at Titan.

Fisher, Jody L.↗
NASA NTRS2003

Three-Dimensional Venturi Sensor for Measuring Extreme Winds

A three-dimensional (3D) Venturi sensor is being developed as a compact, rugged means of measuring wind vectors having magnitudes of as much as 300 mph (134 m/s). This sensor also incorporates auxiliary sensors for measuring temperature from -40 to +120 F (-40 to +49 C), relative humidity from 0 to 100 percent, and atmospheric pressure from 846 to 1,084 millibar (85 to 108 kPa). Conventional cup-and-vane anemometers are highly susceptible to damage by both high wind forces and debris, due to their moving parts and large profiles. In addition, they exhibit slow recovery times contributing to an inaccurately high average-speed reading. Ultrasonic and hot-wire anemometers overcome some of the disadvantages of the cup and-vane anemometers, but they have other disadvantageous features, including limited dynamic range and susceptibility to errors caused by external acoustic noise and rain. In contrast, the novel 3D Venturi sensor is less vulnerable to wind damage because of its smaller profile and ruggedness. Since the sensor has no moving parts, it provides increased reliability and lower maintenance costs. It has faster response and recovery times to changing wind conditions than traditional systems. In addition, it offers wide dynamic range and is expected to be relatively insensitive to rain and acoustic energy. The Venturi effect in this sensor is achieved by the mirrored double-inflection curve, which is then rotated 360 to create the desired detection surfaces. The curve is optimized to provide a good balance of pressure difference between sensor ports and overall maximum fluid velocity while in the shape. Four posts are used to separate the two shapes, and their size and location were chosen to minimize effects on the pressure measurements. The 3D Venturi sensor has smart software algorithms to map the wind pressure exerted on the surfaces of the design. Using Bernoulli's equation, the speed of the wind is calculated from the differences among the pressure readings at the various ports. The direction of the wind is calculated from the spatial distribution and magnitude of the pressure readings. All of the pressure port sizes and locations have been optimized to minimize measurement errors and to reside in areas demonstrating a stable pressure reading proportional to the velocity range.

Zysko, Jan A.↗
NASA NTRS1995

Property-Based Software Engineering Measurement

Little theory exists in the field of software system measurement. Concepts such as complexity, coupling, cohesion or even size are very often subject to interpretation and appear to have inconsistent definitions in the literature. As a consequence, there is little guidance provided to the analyst attempting to define proper measures for specific problems. Many controversies in the literature are simply misunderstandings and stem from the fact that some people talk about different measurement concepts under the same label (complexity is the most common case). There is a need to define unambiguously the most important measurement concepts used in the measurement of software products. One way of doing so is to define precisely what mathematical properties characterize these concepts regardless of the specific software artifacts to which these concepts are applied. Such a mathematical framework could generate a consensus in the software engineering community and provide a means for better communication among researchers, better guidelines for analysis, and better evaluation methods for commercial static analyzers for practitioners. In this paper, we propose a mathematical framework which is generic, because it is not specific to any particular software artifact, and rigorous, because it is based on precise mathematical concepts. This framework defines several important measurement concepts (size, length, complexity, cohesion, coupling). It is not intended to be complete or fully objective; other frameworks could have been proposed and different choices could have been made. However, we believe that the formalism and properties we introduce are convenient and intuitive. In addition, we have reviewed the literature on this subject and compared it with our work. This framework contributes constructively to a firmer theoretical ground of software measurement.

Briand, Lionel↗
NASA NTRS1993

Sculpting in cyberspace: Parallel processing the development of new software

Stimulating creativity in problem solving, particularly where software development is involved, is applicable to many disciplines. Metaphorical thinking keeps the problem in focus but in a different light, jarring people out of their mental ruts and sparking fresh insights. It forces the mind to stretch to find patterns between dissimilar concepts, in the hope of discovering unusual ideas in odd associations (Technology Review January 1993, p. 37). With a background in Engineering and Visual Design from MIT, I have for the past 30 years pursued a career as a sculptor of interdisciplinary monumental artworks that bridge the fields of science, engineering and art. Since 1979, I have pioneered the application of computer simulation to solve the complex problems associated with these projects. A recent project for the roof of the Carnegie Science Center in Pittsburgh made particular use of the metaphoric creativity technique described above. The problem-solving process led to the creation of hybrid software combining scientific, architectural and engineering visualization techniques. David Steich, a Doctoral Candidate in Electrical Engineering at Penn State, was commissioned to develop special software that enabled me to create innovative free-form sculpture. This paper explores the process of inventing the software through a detailed analysis of the interaction between an artist and a computer programmer.

Fisher, Rob↗
NASA NTRS2006

Cooperative Collision Avoidance Step 1 - Technology Demonstration Flight Test Report. Revision 1

The National Aeronautics and Space Administration (NASA) Access 5 Project Office sponsored a cooperative collision avoidance flight demonstration program for unmanned aircraft systems (UAS). This flight test was accomplished between September 21st and September 27th 2005 from the Mojave Airport, Mojave, California. The objective of these flights was to collect data for the Access 5 Cooperative Collision Avoidance (CCA) Work Package simulation effort, i.e., to gather data under select conditions to allow validation of the CCA simulation. Subsequent simulation to be verified were: Demonstrate the ability to detect cooperative traffic and provide situational awareness to the ROA pilot; Demonstrate the ability to track the detected cooperative traffic and provide position information to the ROA pilot; Demonstrate the ability to determine collision potential with detected cooperative traffic and provide notification to the ROA pilot; Demonstrate that the CCA subsystem provides information in sufficient time for the ROA pilot to initiate an evasive maneuver to avoid collision; Demonstrate an evasive maneuver that avoids collision with the threat aircraft; and lastly, Demonstrate the ability to assess the adequacy of the maneuver and determine that the collision potential has been avoided. The Scaled Composites, LLC Proteus Optionally Piloted Vehicle (OPV) was chosen as the test platform. Proteus was manned by two on-board pilots but was also capable of being controlled from an Air Vehicle Control Station (AVCS) located on the ground. For this demonstration, Proteus was equipped with cooperative collision sensors and the required hardware and software to place the data on the downlink. Prior to the flight phase, a detailed set of flight test scenarios were developed to address the flight test objectives. Two cooperative collision avoidance sensors were utilized for detecting aircraft in the evaluation: Traffic Alert and Collision Avoidance System-II (TCAS-II) and Automatic Dependent Surveillance Broadcast (ADS-B). A single intruder aircraft was used during all the flight testing, a NASA Gulfstream III (G-III). During the course of the testing, six geometrically different near-collision scenarios were evaluated. These six scenarios were each tested using various combinations of sensors and collision avoidance software. Of the 54 planned test points 49 were accomplished successfully. Proteus flew a total of 21.5 hours during the testing and the G-III flew 19.8 hours. The testing fully achieved all flight test objectives. The Flight IPT performed an analysis to determine the accuracy of the simulation model used to predict the location of the host aircraft downstream during an avoidance maneuver. The data collected by this flight program was delivered to the Access 5 Cooperative Collision Avoidance (CCA) Work Package Team who was responsible for reporting on their analysis of this flight data.

Trongale, Nicholas A.↗
NASA NTRS1990

The cleanroom case study in the Software Engineering Laboratory: Project description and early analysis

This case study analyzes the application of the cleanroom software development methodology to the development of production software at the NASA/Goddard Space Flight Center. The cleanroom methodology emphasizes human discipline in program verification to produce reliable software products that are right the first time. Preliminary analysis of the cleanroom case study shows that the method can be applied successfully in the FDD environment and may increase staff productivity and product quality. Compared to typical Software Engineering Laboratory (SEL) activities, there is evidence of lower failure rates, a more complete and consistent set of inline code documentation, a different distribution of phase effort activity, and a different growth profile in terms of lines of code developed. The major goals of the study were to: (1) assess the process used in the SEL cleanroom model with respect to team structure, team activities, and effort distribution; (2) analyze the products of the SEL cleanroom model and determine the impact on measures of interest, including reliability, productivity, overall life-cycle cost, and software quality; and (3) analyze the residual products in the application of the SEL cleanroom model, such as fault distribution, error characteristics, system growth, and computer usage.

Green, Scott↗
NASA NTRS2003

Improved Conflict Detection for Reducing Operational Errors in Air Traffic Control

An operational error is an incident in which an air traffic controller allows the separation between two aircraft to fall below the minimum separation standard. The rates of such errors in the US have increased significantly over the past few years. This paper proposes new detection methods that can help correct this trend by improving on the performance of Conflict Alert, the existing software in the Host Computer System that is intended to detect and warn controllers of imminent conflicts. In addition to the usual trajectory based on the flight plan, a "dead-reckoning" trajectory (current velocity projection) is also generated for each aircraft and checked for conflicts. Filters for reducing common types of false alerts were implemented. The new detection methods were tested in three different ways. First, a simple flightpath command language was developed t o generate precisely controlled encounters for the purpose of testing the detection software. Second, written reports and tracking data were obtained for actual operational errors that occurred in the field, and these were "replayed" to test the new detection algorithms. Finally, the detection methods were used to shadow live traffic, and performance was analysed, particularly with regard to the false-alert rate. The results indicate that the new detection methods can provide timely warnings of imminent conflicts more consistently than Conflict Alert.

Paielli, Russell A.↗
NASA NTRS2004

Controlling Distributed Planning

A system of software implements an extended version of an approach, denoted shared activity coordination (SHAC), to the interleaving of planning and the exchange of plan information among organizations devoted to different missions that normally communicate infrequently except that they need to collaborate on joint activities and/or the use of shared resources. SHAC enables the planning and scheduling systems of the organizations to coordinate by resolving conflicts while optimizing local planning solutions. The present software provides a framework for modeling and executing communication protocols for SHAC. Shared activities are represented in each interacting planning system to establish consensus on joint activities or to inform the other systems of consumption of a common resource or a change in a shared state. The representations of shared activities are extended to include information on (1) the role(s) of each participant, (2) permissions (defined as specifications of which participant controls what aspects of shared activities and scheduling thereof), and (3) constraints on the parameters of shared activities. Also defined in the software are protocols for changing roles, permissions, and constraints during the course of coordination and execution.

Clement, Bradley↗
NASA NTRS1982

Data processing for a cosmic ray experiment onboard the solar probes Helios 1 and 2: Experiment 6

The data processing system for the Helios experiment 6, measuring energetic charged particles of solar, planetary and galactic origin in the inner solar system, is described. The aim of this experiment is to extend knowledge on origin and propagation of cosmic rays. The different programs for data reduction, analysis, presentation, and scientific evaluation are described as well as hardware and software of the data processing equipment. A chronological presentation of the data processing operation is given. Procedures and methods for data analysis which were developed can be used with minor modifications for analysis of other space research experiments.

Mueller-Mellin, R.↗
NASA NTRS1985

Orbits: Computer simulation

In rotating machinery dynamics an orbit (Lissajous curve) represents the dynamic path of the shaft centerline motion during shaft rotation and resulting precession. The orbit can be observed with an oscilloscope connected to XY promixity probes. The orbits can also be simulated by a computer. The software for HP computer simulates orbits for two cases: (1) Symmetric orbit with four frequency components with different radial amplitudes and relative phase angles; and (2) Nonsymmetric orbit with two frequency components with two different vertical/horizontal amplitudes and two different relative phase angles. Each orbit carries a Keyphasor mark (one-per-turn reference). The frequencies, amplitudes, and phase angles, as well as number of time steps for orbit computation, have to be chosen and introduced to the computer by the user. The orbit graphs can be observed on the computer screen.

Muszynska, A.↗
NASA NTRS1986

Spectroscopic aspects of differential method for sounding gas composition of the atmosphere

The problems concerning the dynamics of populations of the sounded atmospheric gas molecule levels taking into account the nonmonochromatic character of radiation, durations of exciting and sounding pulses, rates of relaxation of excited vibration-rotation states population along different channels in a natural multicomponent mixture of gases and air were investigated. The problems of spectroscopic software, completeness and accuracy of the initial spectroscopic information, information on channels and rates of relaxation from the viewpoint of developing specific schemes of sounding are discussed. The values of deviations of vibration-rotation level populations of some atmospheric molecules from their equilibrium value at simultaneous action of double frequency radiation on the sounding path and the corresponding dynamic variation of lidar return amplitude were estimated. The importance of nonlinear spectrosopic effects in the lidar return value variation at sounding radiation frequency equaling the resonance frequency of vibration-rotation transition in the problem on sounding the humidity profiles and concentrations of gaseous pollutants was also estimated.

Zuev, V. V.↗
NASA NTRS1987

The predictive information obtained by testing multiple software versions

Multiversion programming is a redundancy approach to developing highly reliable software. In applications of this method, two or more versions of a program are developed independently by different programmers and the versions are combined to form a redundant system. One variation of this approach consists of developing a set of n program versions and testing the versions to predict the failure probability of a particular program or a system formed from a subset of the programs. The precision that might be obtained, and also the effect of programmer variability if predictions are made over repetitions of the process of generating different program versions, are examined.

Lee, Larry D.↗
NASA NTRS1988

A strategy for reducing turnaround time in design optimization using a distributed computer system

There is a need to explore methods for reducing lengthly computer turnaround or clock time associated with engineering design problems. Different strategies can be employed to reduce this turnaround time. One strategy is to run validated analysis software on a network of existing smaller computers so that portions of the computation can be done in parallel. This paper focuses on the implementation of this method using two types of problems. The first type is a traditional structural design optimization problem, which is characterized by a simple data flow and a complicated analysis. The second type of problem uses an existing computer program designed to study multilevel optimization techniques. This problem is characterized by complicated data flow and a simple analysis. The paper shows that distributed computing can be a viable means for reducing computational turnaround time for engineering design problems that lend themselves to decomposition. Parallel computing can be accomplished with a minimal cost in terms of hardware and software.

Young, Katherine C.↗