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 163 records · Page 9
All sourcesNASA NTRSDOE OSTI
NASA NTRS2010

PLOT3D Export Tool for Tecplot

The PLOT3D export tool for Tecplot solves the problem of modified data being impossible to output for use by another computational science solver. The PLOT3D Exporter add-on enables the use of the most commonly available visualization tools to engineers for output of a standard format. The exportation of PLOT3D data from Tecplot has far reaching effects because it allows for grid and solution manipulation within a graphical user interface (GUI) that is easily customized with macro language-based and user-developed GUIs. The add-on also enables the use of Tecplot as an interpolation tool for solution conversion between different grids of different types. This one add-on enhances the functionality of Tecplot so significantly, it offers the ability to incorporate Tecplot into a general suite of tools for computational science applications as a 3D graphics engine for visualization of all data. Within the PLOT3D Export Add-on are several functions that enhance the operations and effectiveness of the add-on. Unlike Tecplot output functions, the PLOT3D Export Add-on enables the use of the zone selection dialog in Tecplot to choose which zones are to be written by offering three distinct options - output of active, inactive, or all zones (grid blocks). As the user modifies the zones to output with the zone selection dialog, the zones to be written are similarly updated. This enables the use of Tecplot to create multiple configurations of a geometry being analyzed. For example, if an aircraft is loaded with multiple deflections of flaps, by activating and deactivating different zones for a specific flap setting, new specific configurations of that aircraft can be easily generated by only writing out specific zones. Thus, if ten flap settings are loaded into Tecplot, the PLOT3D Export software can output ten different configurations, one for each flap setting.

Alter, Stephen↗
NASA NTRS1988

Resource utilization during software development

This paper discusses resource utilization over the life cycle of software development and discusses the role that the current 'waterfall' model plays in the actual software life cycle. Software production in the NASA environment was analyzed to measure these differences. The data from 13 different projects were collected by the Software Engineering Laboratory at NASA Goddard Space Flight Center and analyzed for similarities and differences. The results indicate that the waterfall model is not very realistic in practice, and that as technology introduces further perturbations to this model with concepts like executable specifications, rapid prototyping, and wide-spectrum languages, we need to modify our model of this process.

Zelkowitz, Marvin V.↗
NASA NTRS1989

Chemical calculations on Cray computers

The influence of recent developments in supercomputing on computational chemistry is discussed with particular reference to Cray computers and their pipelined vector/limited parallel architectures. After reviewing Cray hardware and software the performance of different elementary program structures are examined, and effective methods for improving program performance are outlined. The computational strategies appropriate for obtaining optimum performance in applications to quantum chemistry and dynamics are discussed. Finally, some discussion is given of new developments and future hardware and software improvements.

Taylor, Peter R.↗
NASA NTRS1989

Chemical calculations on Cray computers

The influence of recent developments in supercomputing on computational chemistry is discussed with particular reference to Cray computers and their pipelined vector/limited parallel architectures. After reviewing Cray hardware and software the performance of different elementary program structures are examined, and effective methods for improving program performance are outlined. The computational strategies appropriate for obtaining optimum performance in applications to quantum chemistry and dynamics are discussed. Finally, some discussion is given of new developments and future hardware and software improvements.

Taylor, Peter R.↗
NASA NTRS1992

Working Notes from the 1992 AAAI Workshop on Automating Software Design. Theme: Domain Specific Software Design

The goal of this workshop is to identify different architectural approaches to building domain-specific software design systems and to explore issues unique to domain-specific (vs. general-purpose) software design. Some general issues that cut across the particular software design domain include: (1) knowledge representation, acquisition, and maintenance; (2) specialized software design techniques; and (3) user interaction and user interface.

Keller, Richard M.↗
NASA NTRS2005

Rotational spectroscopy at the Jet Propulsion Laboratory

Environmental monitoring, atmospheric remote sensing and astrophysical studies promoted by NASA require a strong basis of spectroscopic information. The rotational spectroscopy capabilities at NASAs Jet Propulsion Laboratory (JPL) are currently maintained for the measurement of key mission priorities that enable modeling and retrieval of geophysical data from the atmosphere as well as validation of the space-borne instruments in the Earth Observing System, particularly the Microwave Limb Sounder. Rotational spectra are measured using a variety of spectroscopic techniques including pulsed-beam Fourier transform microwave spectroscopy (at CalTech); millimeter wavelength Stark spectroscopy; millimeter, submillimeter and THz FM spectroscopy; laser sideband spectroscopy and Fourier Transform far-infrared spectroscopy. Remote measurements of atmospheric rotational spectra are made using two limb-sounder instruments in the submillimeter and THz. Recent advances in the direct synthesis of THz radiation that enable more efficient laboratory science will be presented. Software for comprehensive and systematic study of different molecular systems is maintained at JPL, the software is freely available via http://spec.jpl.nasa.gov and is used by our group to create and sustain the JPL spectral line catalog also available online.

molecular spectroscopy↗
NASA NTRS2012

Architectural Implementation of NASA Space Telecommunications Radio System Specification

This software demonstrates a working implementation of the NASA STRS (Space Telecommunications Radio System) architecture specification. This is a developing specification of software architecture and required interfaces to provide commonality among future NASA and commercial software-defined radios for space, and allow for easier mixing of software and hardware from different vendors. It provides required functions, and supports interaction with STRS-compliant simple test plug-ins ("waveforms"). All of it is programmed in "plain C," except where necessary to interact with C++ plug-ins. It offers a small footprint, suitable for use in JPL radio hardware. Future NASA work is expected to develop into fully capable software-defined radios for use on the space station, other space vehicles, and interplanetary probes.

Peters, Kenneth J.↗
NASA NTRSDate not supplied

Orion Backup Flight Software

Orion Backup Flight Software (BFS) is a joint NASA/Lockheed Martin effort designed to prevent the loss of the Orion crew. BFS will only take over in the event the primary flight software (PFSW) fails to operate properly due to either hardware or software failures. Since the PFSW runs identical software on identical hardware, it is conceivable that a single issue could simultaneously bring down all the PFSW. To minimize the likelihood BFS would be affected by the same issue, BFS was specifically designed to be as different as possible from PFSW: BFS runs on different hardware, a separate operating system, a different compiler, does not share software libraries, and is written by a different team of programmers. This presentation will provide a high-level overview of the Artemis missions and the Orion vehicle, as well as provide additional details of the BFS system (including how BFS is different than the PFSW). The overall BFS capability evolution and timeline (milestones reached as well as work remaining) through the Artemis III mission will be discussed. Additionally, the verification and validation plans for BFS will be presented, describing how we ensure that only validated configuration data is loaded onto the flight vehicle. Finally, the presentation will close with lessons learned and future plans for Orion BFS.

Orion↗
NASA NTRSDate not supplied

Orion Backup Flight Software (BFS)

Orion Backup Flight Software (BFS) is a joint NASA/Lockheed Martin effort designed to prevent the loss of the Orion crew. BFS will only take over in the event the primary flight software (PFSW) fails to operate properly due to either hardware or software failures. Since the PFSW runs identical software on identical hardware, it is conceivable that a single issue could simultaneously bring down all the PFSW. To minimize the likelihood BFS would be affected by the same issue, BFS was specifically designed to be as different as possible from PFSW: BFS runs on different hardware, a separate operating system, a different compiler, does not share software libraries, and is written by a different team of programmers. This presentation will provide a high-level overview of the Artemis missions and the Orion vehicle, as well as provide additional details of the BFS system (including how BFS is different than the PFSW). The overall BFS capability evolution and timeline (milestones reached as well as work remaining) through the Artemis III mission will be discussed. Additionally, the verification and validation plans for BFS will be presented, describing how we ensure that only validated configuration data is loaded onto the flight vehicle. Finally, the presentation will close with lessons learned and future plans for Orion BFS.

CFS↗
NASA NTRS1988

PC analysis of an acousto-ultrasonic signal

An introduction is given to PC software developed to analyze a digitized signal. The specific way in which the software was implemented and the relative ease with which the same software can be implemented in different systems for various applications are discussed. The basic equations and related theory used in the software are furnished. Specifically, mention is made of signal digitization, dc biasing, Fourier analysis, moment analysis, digital filtering, and transfer functions. Examples of calculations are given to indicate the physical significance of variables calculated from the frequency domain via moment equations.

Kiernan, M. T.↗
NASA NTRS2004

Human-Robot Planetary Exploration Teams

The EVA Robotic Assistant (ERA) project at NASA Johnson Space Center studies human-robot interaction and robotic assistance for future human planetary exploration. Over the past four years, the ERA project has been performing field tests with one or more four-wheeled robotic platforms and one or more space-suited humans. These tests have provided experience in how robots can assist humans, how robots and humans can communicate in remote environments, and what combination of humans and robots works best for different scenarios. The most efficient way to understand what tasks human explorers will actually perform, and how robots can best assist them, is to have human explorers and scientists go and explore in an outdoor, planetary-relevant environment, with robots to demonstrate what they are capable of, and roboticists to observe the results. It can be difficult to have a human expert itemize all the needed tasks required for exploration while sitting in a lab: humans do not always remember all the details, and experts in one arena may not even recognize that the lower level tasks they take for granted may be essential for a roboticist to know about. Field tests thus create conditions that more accurately reveal missing components and invalid assumptions, as well as allow tests and comparisons of new approaches and demonstrations of working systems. We have performed field tests in our local rock yard, in several locations in the Arizona desert, and in the Utah desert. We have tested multiple exploration scenarios, such as geological traverses, cable or solar panel deployments, and science instrument deployments. The configuration of our robot can be changed, based on what equipment is needed for a given scenario, and the sensor mast can even be placed on one of two robot bases, each with different motion capabilities. The software architecture of our robot is also designed to be as modular as possible, to allow for hardware and configuration changes. Two focus areas of our research are safety and crew time efficiency. For safety, our work involves enabling humans to reliably communicate with a robot while moving in the same workspace, and enabling robots to monitor and advise humans of potential problems. Voice, gesture, remote computer control, and enhanced robot intelligence are methods we are studying. For crew time efficiency, we are investigating the effects of assigning different roles to humans and robots in collaborative exploration scenarios.

Tyree, Kimberly↗
NASA NTRS1990

Study of the available finite element software packages at KSC

The interaction among the three finite element software packages, SDRCI/I-DEAS, MSC/NASTRAN, and I/FEM, used at NASA, Kennedy Space Center is addressed. The procedures for using more than one of these application software packages to model and analyze a structure design are discussed. Design and stress analysis of a solid rocket booster fixture is illustrated by using four different combinations of the three software packages. Their results are compared and show small yet acceptable differences.

Lu, Chu-Ho↗
NASA NTRS1997

Measurement and Analysis of Failures in Computer Systems

This thesis presents a study of software failures spanning several different releases of Tandem's NonStop-UX operating system running on Tandem Integrity S2(TMR) systems. NonStop-UX is based on UNIX System V and is fully compliant with industry standards, such as the X/Open Portability Guide, the IEEE POSIX standards, and the System V Interface Definition (SVID) extensions. In addition to providing a general UNIX interface to the hardware, the operating system has built-in recovery mechanisms and audit routines that check the consistency of the kernel data structures. The analysis is based on data on software failures and repairs collected from Tandem's product report (TPR) logs for a period exceeding three years. A TPR log is created when a customer or an internal developer observes a failure in a Tandem Integrity system. This study concentrates primarily on those TPRs that report a UNIX panic that subsequently crashes the system. Approximately 200 of the TPRs fall into this category. Approximately 50% of the failures reported are from field systems, and the rest are from the testing and development sites. It has been observed by Tandem developers that fewer cases are encountered from the field than from the test centers. Thus, the data selection mechanism has introduced a slight skew.

Thakur, Anshuman↗
NASA NTRS1995

Software packager user's guide

Software integration is a growing area of concern for many programmers and software managers because the need to build new programs quickly from existing components is greater than ever. This includes building versions of software products for multiple hardware platforms and operating systems, building programs from components written in different languages, and building systems from components that must execute on different machines in a distributed network. The goal of software integration is to make building new programs from existing components more seamless -- programmers should pay minimal attention to the underlying configuration issues involved. Libraries of reusable components and classes are important tools but only partial solutions to software development problems. Even though software components may have compatible interfaces, there may be other reasons, such as differences between execution environments, why they cannot be integrated. Often, components must be adapted or reimplemented to fit into another application because of implementation differences -- they are implemented in different programming languages, dependent on different operating system resources, or must execute on different physical machines. The software packager is a tool that allows programmers to deal with interfaces between software components and ignore complex integration details. The packager takes modular descriptions of the structure of a software system written in the package specification language and produces an integration program in the form of a makefile. If complex integration tools are needed to integrate a set of components, such as remote procedure call stubs, their use is implied by the packager automatically and stub generation tools are invoked in the corresponding makefile. The programmer deals only with the components themselves and not the details of how to build the system on any given platform.

Callahan, John R.↗
NASA NTRS1981

Integrated Analysis Capability pilot computer program

An integrated analysis capability (IAC) computer software package was developed for the design analysis and performance evaluation of large space systems. The IAC aids the user in coupling the required technical disciplines (initially structures, thermal and controls), providing analysis solution paths which reveal critical interactive effects in order to study loads, stability and mission performance. Existing technical software modules, having a wide existing user community, are combined with the interface software to bridge between the different technologies and mathematical modeling techniques. The package is supported by executive, data management and interactive graphics software, with primary development within the superminicomputer environment.

Vos, R. G.↗
NASA NTRS2011

Cassini Tour Atlas Automated Generation

During the Cassini spacecraft s cruise phase and nominal mission, the Cassini Science Planning Team developed and maintained an online database of geometric and timing information called the Cassini Tour Atlas. The Tour Atlas consisted of several hundreds of megabytes of EVENTS mission planning software outputs, tables, plots, and images used by mission scientists for observation planning. Each time the nominal mission trajectory was altered or tweaked, a new Tour Atlas had to be regenerated manually. In the early phases of Cassini s Equinox Mission planning, an a priori estimate suggested that mission tour designers would develop approximately 30 candidate tours within a short period of time. So that Cassini scientists could properly analyze the science opportunities in each candidate tour quickly and thoroughly so that the optimal series of orbits for science return could be selected, a separate Tour Atlas was required for each trajectory. The task of manually generating the number of trajectory analyses in the allotted time would have been impossible, so the entire task was automated using code written in five different programming languages. This software automates the generation of the Cassini Tour Atlas database. It performs with one UNIX command what previously took a day or two of human labor.

Grazier, Kevin R.↗
NASA NTRS2011

Mars Science Laboratory Boot Robustness Testing

Mars Science Laboratory (MSL) is one of the most complex spacecrafts in the history of mankind. Due to the nature of its complexity, a large number of flight software (FSW) requirements have been written for implementation. In practice, these requirements necessitate very complex and very precise flight software with no room for error. One of flight software's responsibilities is to be able to boot up and check the state of all devices on the spacecraft after the wake up process. This boot up and initialization is crucial to the mission success since any misbehavior of different devices needs to be handled through the flight software. I have created a test toolkit that allows the FSW team to exhaustively test the flight software under variety of different unexpected scenarios and validate that flight software can handle any situation after booting up. The test includes initializing different devices on spacecraft to different configurations and validate at the end of the flight software boot up that the flight software has initialized those devices to what they are suppose to be in that particular scenario.

mission phases↗
NASA NTRS2019

The Space Communications and Navigation Testbed aboard International Space Station: Seven Years of Space-based Reconfigurable Software Defined Communications, Navigation, and Networking

The adoption of software defined radios offers space missions a new way to develop and operate space transceivers for communications and navigation.The SCaN Testbed on-board the ISS led groundbreaking efforts to champion use of software defined radios for space communications. The SCaN Testbed has allowed NASA, industry, academia, and international partners to pursue their respective interests in joint collaboration with NASA, and move this technology and it's applications to the space domain. Launched in 2012, The SCaN Testbed has logged over 4000 hours of operation exploring the development, reconfiguration, and operation of software defined radios and their software applications. Over the past seven years, experimenters and organizations from across the United States and around the world, have advanced the applications of software defined radios and networks using the SCaN Tested. Some of SCaN Testbed's successful experiments include the demonstration of the first Ka-band full duplex space transceiver, which became an R&D 100 award winning technology, and was inducted into the Space Technology Hall of Fame, following the launch and space deployment of a successful commercial product line based on the Testbed radios.Experiments have focused on new software development and operations concepts for understanding how to manage and apply this relatively new technology to space to improve communications and navigation for space science and exploration missions. The advanced capabilities of the software radios allow for multiple applications or functions (e.g., communication and navigation) to operate from the same radio platform. Multiple software waveform applications enable software component reuse and improve efficiency for multiple applications operating over different mission phases. The new capabilities of software defined radios such as on-orbit reconfiguration, also present new challenges such as increased operational complexity. Experiments of the SCaN testbed include more intelligent or cognitive applications to improve communications efficiency and manage the complexity of the radios, the communication channels, and the network itself. The software defined radios on the SCaN Testbed are each compliant to NASA's Space Telecommunications Radio System (STRS) Architecture. The STRS Architecture provides commonality among radio developments from different providers and different mission applications, and is designed to reduce the cost, risk, and complexity of unique and custom radio developments. This radio architecture standard defines common waveform software interfaces, methods of instantiation, operation, and documentation. As the SCaN Testbed concludes its operations on ISS, this presentation explores the advancements and accomplishments made to advance software defined radio technology and its applications for exploration. The accomplishments cover a number of experiment areas in Ka-band and S-band communications with TDRS, high rate communications, adaptive waveform operation, navigation using both GPA and Galileo constellations, complex networking and disruptive tolerant link protocols, user initiative service, and initial experiments with intelligent and cognitive applications which demonstrate the significant potential of software defined and cognitive radios.

Mortensen, Dale↗