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 55 records · Page 3

NASA Pathways Co-op Tour Johnson Space Center Fall 2013

This report outlines the tasks and objectives completed during a co‐operative education tour with National Aeronautics and Space Association (NASA) at the Johnson Space Center in Houston, Texas. I worked for the Attitude & Pointing group of the Flight Dynamics Division within the Mission Operations Directorate at Johnson Space Center. NASA's primary mission is to support and expand the various ongoing space exploration programs and any research and development activities associated with it. My primary project required me to develop and a SharePoint web application for my group. My secondary objective was to become familiar with the role of my group which was primarily to provide spacecraft attitude and line of sight determination, including Tracking and Data Relay Satellite (TDRS) communications coverage for various NASA, International, and commercial partner spacecraft. My projects required me to become acquainted with different software systems, fundamentals of aerospace engineering, project management, and develop essential interpersonal communication skills. Overall, I accomplished multiple goals which included laying the foundations for an updated SharePoint which will allow for an organized platform to communicate and share data for group members and external partners. I also successfully learned about the operations of the Attitude & Pointing Group and how it contributes to the Missions Operations Directorate and NASA's Space Program as a whole

Masood, Amir↗

Design and Control of Compliant Tensegrity Robots Through Simulation and Hardware Validation

To better understand the role of tensegrity structures in biological systems and their application to robotics, the Dynamic Tensegrity Robotics Lab at NASA Ames Research Center has developed and validated two different software environments for the analysis, simulation, and design of tensegrity robots. These tools, along with new control methodologies and the modular hardware components developed to validate them, are presented as a system for the design of actuated tensegrity structures. As evidenced from their appearance in many biological systems, tensegrity ("tensile-integrity") structures have unique physical properties which make them ideal for interaction with uncertain environments. Yet these characteristics, such as variable structural compliance, and global multi-path load distribution through the tension network, make design and control of bio-inspired tensegrity robots extremely challenging. This work presents the progress in using these two tools in tackling the design and control challenges. The results of this analysis includes multiple novel control approaches for mobility and terrain interaction of spherical tensegrity structures. The current hardware prototype of a six-bar tensegrity, code-named ReCTeR, is presented in the context of this validation.

Robotics↗

Optimizing the Model of the Viking-400 UAS

This project intends to update and redesign imperfections in the scanned 3D CAD model of the Viking 400 aircraft. This aircraft, similar to the Sierra-B UAS, will carry payloads of scientific instruments for research purposes. The goals of this project are to modify the current scanned model such that it better represents the physical qualities of the aircraft, as well as creating the features that are missing from the model. As the model was imported from a different software, many of the critical surfaces did not accurately reflect the actual aircraft. Those parts of the model were redesigned entirely so that they can be edited for future use, as well as correctly representing the aircraft as it is now. Additionally, parts of the aircraft that did not appear in the scanned model were designed and added to the new model. In order to prioritize ease of use for future missions, the model has been reorganized in a logical fashion that enables modification of specific parts of the aircraft. The organization of this model imitates the drawing tree of the Sierra-B, with the intention of maintaining a functional system of redesign, analysis, and implementation. Ultimately, this project will be a catalyst for making Viking 400 into a functional aircraft and increasing scientific research in airborne vehicles.

Wandrocke, Evan W. J.↗

Microwave Structure Construction Capability Year One Accomplishments

The Microwave Structure Construction Capability (MSCC) element, part of the Moon to Mars Planetary Autonomous Construction Project (MMPACT) was initiated in 2020. MSCC is responsible for creating horizontal and vertical infrastructure on the moon using microwave energy. Microwave energy was selected since it is the only method to volumetrically heat the regolith. All other sintering/melting methods rely on thermal conduction through the very low conductivity surface, resulting in an inefficient process. Advances were achieved in materials characterization and understanding, microwave sintering in vacuum, and microwave design and analyses. Two dielectric property testing systems have been developed at Radiance Technologies and JPL. These will examine dielectric properties at cryogenic temperatures and over a broad frequency range. Permittivity and permeability testing at -60 ̊C in vacuum from 0.05 to 3 GHz has been generated at JPL. Additional modifications will be made to go to -190 ̊C (LN2). Radiance Technologies created a test system to measure dielectric properties at greater than 10 GHz and initiated work on developing a vacuum capable, portable test system to measure dielectric properties of Apollo regolith and simulants from 100 MHz to 18 GHz. These tests are to identify optimal heating frequencies and protocols. During microwave sintering at about 1100 ̊C, volatiles were creating difficulty in achieving a reasonably dense specimen. Due to processing in vacuum and the nature of the lunar regolith, some volatiles and porosity are expected. However, the Earth produced simulants have non-lunar materials in them that create volatiles that aren’t representative of lunar regolith. Therefore, a five month effort was conducted to establish a heat treat method to remove these non-lunar materials. Tests were conducted using TGA mass spectrometry, heating in vacuum and conducting mass spectrometry, dielectric and DTA, Raman, BET, particle size analysis, morphological analysis, carbon and sulfur chemical content determination and microscopy. The process has been scaled-up to 6 kg batch size and undergoing evaluation. A 36 kg batch size is the target for JSC-1A and other limited availability simulants. These calcining protocols will be standard for NASA and beyond. MSCC has also created scalable processes for fabricating synthetic lunar materials. Processes to fabricate Anorthite (plagioclase CaAl2Si2O8), Diopside (pyroxene CaMgSi₂O₆), and Enstatite (pyroxene Mg2Si2O6) have been generated. These materials will enable generation of microwave sintering models to bound various composition ranges anticipated on the Moon, therefore mitigating the need for a precise simulant with respect to location on the Moon. Successful microwave sintering in air using a horn applicator was demonstrated. All previous microwave vacuum sintering in the literature was at small scale and in a contained enclosure thus taking advantage of reflections. This is the first to use a lunar like microwave applicator to sinter ceramic in a bed as it would be done on the Moon. Small scale and inert sintering were conducted to assist in developing protocols with quicker turnaround times than larger scale testing. Testing has anchored thermal analysis predicting heat flow in vacuum during microwave sintering. Thermal conductivity testing was also initiated. Microwave coupling to the regolith has been modeled by multiple organizations and with different software packages. At least six horn designs and applicator configurations for both magnetron and solid state sources are being examined. Optimal simulant container designs for microwaves have also been generated. The power and electronics design for the solid state microwave system has been initiated. Concept designs for a lander based microwave sintering have been evaluated.

microwave↗

Analysis of Ada as a prototyping language

This paper examines the suitability of Ada as a language for developing software prototypes. The differences between software prototypes and traditional engineering prototypes are discussed; the approaches to software prototyping are identified. Ada's potential as a language for prototyping is evaluated according to the writability, expressiveness, and flexibility of the language; Ada is found to be inadequate as a prototyping language because it lacks writability and expressiveness. Possible approaches to improving the expressiveness of the language are discussed.

Holloway, C. Michael↗

The independence of software metrics taken at different life-cycle stages

Over the past few years a large number of software metrics have been proposed and, in varying degrees, a number of these metrics have been subjected to empirical validation which demonstrated the utility of the metrics in the software development process. Attempts to classify these metrics and to determine if the metrics in these different classes appear to be measuring distinct attributes of the software product are studied. Statistical analysis is used to determine the degree of relationship among the metrics.

Kafura, D.↗

From Bridges and Rockets, Lessons for Software Systems

Although differences exist between building software systems and building physical structures such as bridges and rockets, enough similarities exist that software engineers can learn lessons from failures in traditional engineering disciplines. This paper draws lessons from two well-known failures the collapse of the Tacoma Narrows Bridge in 1940 and the destruction of the space shuttle Challenger in 1986 and applies these lessons to software system development. The following specific applications are made: (1) the verification and validation of a software system should not be based on a single method, or a single style of methods; (2) the tendency to embrace the latest fad should be overcome; and (3) the introduction of software control into safety-critical systems should be done cautiously.

Holloway, C. Michael↗

Multidisciplinary Concurrent Design Optimization via the Internet

A methodology is presented which uses commercial design and analysis software and the Internet to perform concurrent multidisciplinary optimization. The methodology provides a means to develop multidisciplinary designs without requiring that all software be accessible from the same local network. The procedures are amenable to design and development teams whose members, expertise and respective software are not geographically located together. This methodology facilitates multidisciplinary teams working concurrently on a design problem of common interest. Partition of design software to different machines allows each constituent software to be used on the machine that provides the most economy and efficiency. The methodology is demonstrated on the concurrent design of a spacecraft structure and attitude control system. Results are compared to those derived from performing the design with an autonomous FORTRAN program.

Woodard, Stanley E.↗

TOPEX/Poseidon Precision Orbit Determination Using Combined GPS, SLR, and DORIS

TOPEX/Poseidon (T/P) is a joint spaceborne oceanographic mission of U.W. NASA and France CNES design launched August 10, 1992. The satellite has a variety tracking systems for both operational and precision orbit determination. Three precise tracking systems: Satellite Laser Ranging (SLR), Doppler Orbitography and Radiopositioning Integrated by Satellite (DORIS), and Global Positioning System (GPS) provide high quality measurements essential for reconstructing the T/P orbital height with centimeter precision. This paper presents results of simultaneously processing all three data types to exploit the inherent strength of each in a combined solution. SLR and DORIS are routinely combined to provide orbit solutions for the T/P science team. GPS orbit solutions are produced as part of the first demonstration flight of a high quality spaceborne GPS receiver. Coordinate frame and software system differences between the combined SLR/DORIS orbits and the GPS orbits induce orbital height differences of 2 to 3 centimeters. Combining the three data types within a single software system permits removal of software system differences while obtaining coordinate frame calibration information. These calibrations will aid future spaceborne GPS missions that are not complemented with SLR and/or DORIS.

TOPEX/Poseidon↗

On-Orbit Software Analysis

The On-Orbit Software Analysis Research Infusion Project was done by Intrinsyx Technologies Corporation (Intrinsyx) at the National Aeronautics and Space Administration (NASA) Ames Research Center (ARC). The Project was a joint collaborative effort between NASA Codes IC and SL, Kestrel Technology (Kestrel), and Intrinsyx. The primary objectives of the Project were: Discovery and verification of software program properties and dependencies, Detection and isolation of software defects across different versions of software, and Compilation of historical data and technical expertise for future applications

Moran, Susanne I.↗

Shuttle avionics and the goal language including the impact of error detection and redundancy management

The relationship is examined between the space shuttle onboard avionics and the ground test computer language GOAL when used in the onboard computers. The study is aimed at providing system analysis support to the feasibility analysis of a GOAL to HAL translator, where HAL is the language used to program the onboard computers for flight. The subject is dealt with in three aspects. First, the system configuration at checkout, the general checkout and launch sequences, and the inventory of subsystems are described. Secondly, the hierarchic organization of onboard software and different ways of introducing GOAL-derived software onboard are described. Also the flow of commands and test data during checkout is diagrammed. Finally, possible impact of error detection and redundancy management on the GOAL language is discussed.

Flanders, J. H.↗

Strategy for reflector pattern calculation: Let the computer do the work

Using high frequency approximations, the secondary pattern of a reflector antenna can be calculated by numerically evaluating a radiation integral I(u,v). In recent years, tremendous effort has been expended to reducing I(u,v) to Fourier integrals. These reduction schemes are invariably reflector geometry dependent. Hence, different analyses/computer software development must be carried out for different reflector shapes/boundaries. it is pointed out, that, as the computer power improves, these reduction schemes are no longer necessary. Comparable accuracy and computation time can be achieved by evaluating I(u,v) by a brute force FFT described in this note. Furthermore, there is virtually no restriction on the reflector geometry by using the brute force FFT.

Lam, P. T.↗

Strategy for reflector pattern calculation - Let the computer do the work

Using high frequency approximations, the secondary pattern of a reflector antenna can be calculated by numerically evaluating a radiation integral I(u,v). In recent years, tremendous effort has been expended to reducing I(u,v) to Fourier integrals. These reduction schemes are invariably reflector geometry dependent. Hence, different analyses/computer software development must be carried out for different reflector shapes/boundaries. It is pointed out, that, as the computer power improves, these reduction schemes are no longer necessary. Comparable accuracy and computation time can be achieved by evaluating I(u,v) by a brute force FFT described in this note. Furthermore, there is virtually no restriction on the reflector geometry by using the brute force FFT.

Lam, P. T.↗

Model for Simulating a Spiral Software-Development Process

A discrete-event simulation model, and a computer program that implements the model, have been developed as means of analyzing a spiral software-development process. This model can be tailored to specific development environments for use by software project managers in making quantitative cases for deciding among different software-development processes, courses of action, and cost estimates. A spiral process can be contrasted with a waterfall process, which is a traditional process that consists of a sequence of activities that include analysis of requirements, design, coding, testing, and support. A spiral process is an iterative process that can be regarded as a repeating modified waterfall process. Each iteration includes assessment of risk, analysis of requirements, design, coding, testing, delivery, and evaluation. A key difference between a spiral and a waterfall process is that a spiral process can accommodate changes in requirements at each iteration, whereas in a waterfall process, requirements are considered to be fixed from the beginning and, therefore, a waterfall process is not flexible enough for some projects, especially those in which requirements are not known at the beginning or may change during development. For a given project, a spiral process may cost more and take more time than does a waterfall process, but may better satisfy a customer's expectations and needs. Models for simulating various waterfall processes have been developed previously, but until now, there have been no models for simulating spiral processes. The present spiral-process-simulating model and the software that implements it were developed by extending a discrete-event simulation process model of the IEEE 12207 Software Development Process, which was built using commercially available software known as the Process Analysis Tradeoff Tool (PATT). Typical inputs to PATT models include industry-average values of product size (expressed as number of lines of code), productivity (number of lines of code per hour), and number of defects per source line of code. The user provides the number of resources, the overall percent of effort that should be allocated to each process step, and the number of desired staff members for each step. The output of PATT includes the size of the product, a measure of effort, a measure of rework effort, the duration of the entire process, and the numbers of injected, detected, and corrected defects as well as a number of other interesting features. In the development of the present model, steps were added to the IEEE 12207 waterfall process, and this model and its implementing software were made to run repeatedly through the sequence of steps, each repetition representing an iteration in a spiral process. Because the IEEE 12207 model is founded on a waterfall paradigm, it enables direct comparison of spiral and waterfall processes. The model can be used throughout a software-development project to analyze the project as more information becomes available. For instance, data from early iterations can be used as inputs to the model, and the model can be used to estimate the time and cost of carrying the project to completion.

Mizell, Carolyn↗

Autonomous Performance Monitoring System: Monitoring and Self-Tuning (MAST)

Maintaining the long-term performance of software onboard a spacecraft can be a major factor in the cost of operations. In particular, the task of controlling and maintaining a future mission of distributed spacecraft will undoubtedly pose a great challenge, since the complexity of multiple spacecraft flying in formation grows rapidly as the number of spacecraft in the formation increases. Eventually, new approaches will be required in developing viable control systems that can handle the complexity of the data and that are flexible, reliable and efficient. In this paper we propose a methodology that aims to maintain the accuracy of flight software, while reducing the computational complexity of software tuning tasks. The proposed Monitoring and Self-Tuning (MAST) method consists of two parts: a flight software monitoring algorithm and a tuning algorithm. The dependency on the software being monitored is mostly contained in the monitoring process, while the tuning process is a generic algorithm independent of the detailed knowledge on the software. This architecture will enable MAST to be applicable to different onboard software controlling various dynamics of the spacecraft, such as attitude self-calibration, and formation control. An advantage of MAST over conventional techniques such as filter or batch least square is that the tuning algorithm uses machine learning approach to handle uncertainty in the problem domain, resulting in reducing over all computational complexity. The underlying concept of this technique is a reinforcement learning scheme based on cumulative probability generated by the historical performance of the system. The success of MAST will depend heavily on the reinforcement scheme used in the tuning algorithm, which guarantees the tuning solutions exist.

Peterson, Chariya↗

Software Reliability 2002

In FY01 we learned that hardware reliability models need substantial changes to account for differences in software, thus making software reliability measurements more effective, accurate, and easier to apply. These reliability models are generally based on familiar distributions or parametric methods. An obvious question is 'What new statistical and probability models can be developed using non-parametric and distribution-free methods instead of the traditional parametric method?" Two approaches to software reliability engineering appear somewhat promising. The first study, begin in FY01, is based in hardware reliability, a very well established science that has many aspects that can be applied to software. This research effort has investigated mathematical aspects of hardware reliability and has identified those applicable to software. Currently the research effort is applying and testing these approaches to software reliability measurement, These parametric models require much project data that may be difficult to apply and interpret. Projects at GSFC are often complex in both technology and schedules. Assessing and estimating reliability of the final system is extremely difficult when various subsystems are tested and completed long before others. Parametric and distribution free techniques may offer a new and accurate way of modeling failure time and other project data to provide earlier and more accurate estimates of system reliability.

Wallace, Dolores R.↗

Spacecraft Avionics Software Development Then and Now: Different but the Same

NASA has always been in the business of balancing new technologies and techniques to achieve human space travel objectives. NASA s historic Software Production Facility (SPF) was developed to serve complex avionics software solutions during an era dominated by mainframes, tape drives, and lower level programming languages. These systems have proven themselves resilient enough to serve the Shuttle Orbiter Avionics life cycle for decades. The SPF and its predecessor the Software Development Lab (SDL) at NASA s Johnson Space Center (JSC) hosted flight software (FSW) engineering, development, simulation, and test. It was active from the beginning of Shuttle Orbiter development in 1972 through the end of the shuttle program in the summer of 2011 almost 40 years. NASA s Kedalion engineering analysis lab is on the forefront of validating and using many contemporary avionics HW/SW development and integration techniques, which represent new paradigms to NASA s heritage culture in avionics software engineering. Kedalion has validated many of the Orion project s HW/SW engineering techniques borrowed from the adjacent commercial aircraft avionics environment, inserting new techniques and skills into the Multi-Purpose Crew Vehicle (MPCV) Orion program. Using contemporary agile techniques, COTS products, early rapid prototyping, in-house expertise and tools, and customer collaboration, NASA has adopted a cost effective paradigm that is currently serving Orion effectively. This paper will explore and contrast differences in technology employed over the years of NASA s space program, due largely to technological advances in hardware and software systems, while acknowledging that the basic software engineering and integration paradigms share many similarities.

Mangieri, Mark L.↗