Search NASA⌕ Search

SEARCH · Search NASA

Results for “Software errors”

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 523 records · Page 29

An intelligent advisory system for pre-launch processing

The shuttle system of interest in this paper is the shuttle's data processing system (DPS). The DPS is composed of the following: (1) general purpose computers (GPC); (2) a multifunction CRT display system (MCDS); (3) mass memory units (MMU); and (4) a multiplexer/demultiplexer (MDM) and related software. In order to ensure the correct functioning of shuttle systems, some level of automatic error detection has been incorporated into all shuttle systems. For the DPS, error detection equipment has been incorporated into all of its subsystems. The automated diagnostic system, (MCDS) diagnostic tool, that aids in a more efficient processing of the DPS is described.

Engrand, Peter A.↗

Characterization of slow and fast phase nystagmus

A current literature review of the analog and digital process of vestibular and optical kinetic nystagmus reveals little agreement in the methods used by various labs. The strategies for detection of saccade (fast phase velocity component of nystagmus) vary between labs, and most of the process have not been evaluated and validated with a standard database. A survey was made of major vestibular labs in the U.S. that perform computer analyses of vestibular and optokinetic reflexes to stimuli, and a baseline was established from which to standardize data acquisition and analysis programs. The concept of an Error Index was employed as the criterium for evaluating the performance of the vestibular analysis software programs. The performance criterium is based on the detection of saccades and is the average of the percentages of missed detections and false detections. Evaluation of the programs produced results for lateral gaze with saccadic amplitude of one, two, three, five, and ten degrees with various signal-to-noise ratios. In addition, results were obtained for sinusoidal pursuit of 0.05, 0.10, and 0.50 Hz with saccades from one to ten degrees at various signal-to-noise ratios. Selection of the best program was made from the performance in the lateral gaze with three degrees of saccadic amplitude and in the 0.10 Hz sinusoid with three degrees of saccadic amplitude.

Lessard, Charles S.↗

Extracting galactic structure parameters from multivariated density estimation

Multivariate statistical analysis, including includes cluster analysis (unsupervised classification), discriminant analysis (supervised classification) and principle component analysis (dimensionlity reduction method), and nonparameter density estimation have been successfully used to search for meaningful associations in the 5-dimensional space of observables between observed points and the sets of simulated points generated from a synthetic approach of galaxy modelling. These methodologies can be applied as the new tools to obtain information about hidden structure otherwise unrecognizable, and place important constraints on the space distribution of various stellar populations in the Milky Way. In this paper, we concentrate on illustrating how to use nonparameter density estimation to substitute for the true densities in both of the simulating sample and real sample in the five-dimensional space. In order to fit model predicted densities to reality, we derive a set of equations which include n lines (where n is the total number of observed points) and m (where m: the numbers of predefined groups) unknown parameters. A least-square estimation will allow us to determine the density law of different groups and components in the Galaxy. The output from our software, which can be used in many research fields, will also give out the systematic error between the model and the observation by a Bayes rule.

Chen, B.↗

Results from the First Two Flights of the Static Computer Memory Integrity Testing Experiment

This paper details the scientific objectives, experiment design, data collection method, and post flight analysis following the first two flights of the Static Computer Memory Integrity Testing (SCMIT) experiment. SCMIT is designed to detect soft-event upsets in passive magnetic memory. A soft-event upset is a change in the logic state of active or passive forms of magnetic memory, commonly referred to as a "Bitflip". In its mildest form a soft-event upset can cause software exceptions, unexpected events, start spacecraft safeing (ending data collection) or corrupted fault protection and error recovery capabilities. In it's most severe form loss of mission or spacecraft can occur. Analysis after the first flight (in 1991 during STS-40) identified possible soft-event upsets to 25% of the experiment detectors. Post flight analysis after the second flight (in 1997 on STS-87) failed to find any evidence of soft-event upsets. The SCMIT experiment is currently scheduled for a third flight in December 1999 on STS-101.

Hancock, Thomas M., III↗

Development of an Integrated Rocket Thrust Chamber Assembly Analysis and Design Toolkit (TCAT)

There are many individual computational tools and methods used to analyze and design components of a rocket engine thrust chamber assembly (TCA) 11,21. To analyze and design a thrust chamber assembly these tools are usually used in sequence while communication of information between these tools is usually done manually. Each component of a TCA is usually designed and optimized individually with limited considerations on system optimized design. This approach is often iterative and can be prone to error. Also at present, expert knowledge of each tool is required. The objective of this software development effort is to select, integrate and automate the best tools into an easy-to-use computational package, the Thrust Chamber Analysis Toolkit (TCAT). This tool will provide a seamless process to analyze and design all or individual components of a thrust chamber assembly. This paper describes the current status of the MAT software development. The selected component codes and their capabilities are briefly described. User and module interfaces and integration status are presented. MAT pre- and post-processing added options are presented and overall MAT capabilities are demonstrated with the results of sample cases. Ongoing and planned model validation efforts are also described. Finally, the MAT future plan options are discussed.

Farhangi, S.↗

Formal Inspection: A Tool for TQM

The goal of the Formal Inspection Program at the Jet Propulsion Laboratory (JPL) is to support projects wishing to use Formal Inspections to improve the quality of software and system level engineering products.

errors total quality↗

MRO DKF Post-Processing Tool

This software tool saves time and reduces risk by automating two labor-intensive and error-prone post-processing steps required for every DKF [DSN (Deep Space Network) Keyword File] that MRO (Mars Reconnaissance Orbiter) produces, and is being extended to post-process the corresponding TSOE (Text Sequence Of Events) as well. The need for this post-processing step stems from limitations in the seq-gen modeling resulting in incorrect DKF generation that is then cleaned up in post-processing.

Ayap, Shanti↗

NASA Tech Briefs, April 2002

The contents include: 1) Application Briefs; 2) Sneak Preview of Sensors Expo; 3) The Complexity of the Diagnosis Problem; 4) Design Concepts for the ISS TransHab Module; 5) Characteristics of Supercritical Transitional Mixing Layers; 6) Electrometer for Triboelectric Evaluation of Materials; 7) Infrared CO2 Sensor With Built-In Calibration Chambers; 8) Solid-State Potentiometric CO Sensor; 9) Planetary Rover Absolute Heading Detection Using a Sun Sensor; 10) Concept for Utilizing Full Areas of STJ Photodetector Arrays; 11) Development of Cognitive Sensors; 12) Enabling Higher-Voltage Operation of SOl CMOS Transistors; 13) Estimating Antenna-Pointing Errors From Beam Squints; 14) Advanced-Fatigue-Crack-Growth and Fracture- Mechanics Program; 15) Software for Sequencing Spacecraft Actions; 16) Program Distributes and Tracks Organizational Memoranda; 16) Flat Membrane Device for Dehumidification of Air; 17) Inverted Hindle Mount Reduces Sag of a Large, Precise Mirror; 18) Heart-Pump-Outlet/Cannula Coupling; 19) Externally Triggered Microcapsules Release Drugs In Situ; 20) Combinatorial Drug Design Augmented by Information Theory; 21) Multiple-Path-Length Optical Absorbance Cell; 22) Model of a Fluidized Bed Containing a Mixture of Particles; 23) Refractive Secondary Concentrators for Solar Thermal Systems; 24) Cold Flow Calorimeter; 25) Methodology for Tracking Hazards and Predicting Failures; 26) Estimating Heterodyne-Interferometer Polarization Leakage; 27) An Efficient Algorithm for Propagation of Temporal- Constraint Networks; 28) Software for Continuous Replanning During Execution; 29) Surface-Launched Explorers for Reconnaissance/Scouting; 30) Firmware for a Small Motion-Control Processor; 31) Gear Bearings and Gear-Bearing Transmissions; and 32) Linear Dynamometer With Variable Stroke and Frequency.

Source record↗

Simulation Control Graphical User Interface Logging Report

One of the many tasks of my project was to revise the code of the Simulation Control Graphical User Interface (SIM GUI) to enable logging functionality to a file. I was also tasked with developing a script that directed the startup and initialization flow of the various LCS software components. This makes sure that a software component will not spin up until all the appropriate dependencies have been configured properly. Also I was able to assist hardware modelers in verifying the configuration of models after they have been upgraded to a new software version. I developed some code that analyzes the MDL files to determine if any error were generated due to the upgrade process. Another one of the projects assigned to me was supporting the End-to-End Hardware/Software Daily Tag-up meeting.

Hewling, Karl B., Jr.↗

Development of Human System Integration at NASA

Human Systems Integration seeks to design systems around the capabilities and limitations of the humans which use and interact with the system, ensuring greater efficiency of use, reduced error rates, and less rework in the design, manufacturing and operational deployment of hardware and software. One of the primary goals of HSI is to get the human factors practitioner involved early in the design process. In doing so, the aim is to reduce future budget costs and resources in redesign and training. By the preliminary design phase of a project nearly 80% of the total cost of the project is locked in. Potential design changes recommended by evaluations past this point will have little effect due to lack of funding or a huge cost in terms of resources to make changes. Three key concepts define an effective HSI program. First, systems are comprised of hardware, software, and the human, all of which operate within an environment. Too often, engineers and developers fail to consider the human capacity or requirements as part of the system. This leads to poor task allocation within the system. To promote ideal task allocation, it is critical that the human element be considered early in system development. Poor design, or designs that do not adequately consider the human component, could negatively affect physical or mental performance, as well as, social behavior. Second, successful HSI depends upon integration and collaboration of all the domains that represent acquisition efforts. Too often, these domains exist as independent disciplines due to the location of expertise within the service structure. Proper implementation of HSI through participation would help to integrate these domains and disciplines to leverage and apply their interdependencies to attain an optimal design. Via this process domain interests can be integrated to perform effective HSI through trade-offs and collaboration. This provides a common basis upon which to make knowledgeable decisions. Finally, HSI must be considered early in the requirements development phase of system design and acquisition. This will provide the best opportunity to maximize return on investment (ROI) and system performance. HSI requirements must be developed in conjunction with capability ]based requirements generation through functional. HSI requirements will drive HSI metrics and embed HSI issues within the system design. After a system is designed, implementation of HSI oversights can be very expensive. An HSI program should be included as an integral part of a total system approach to vehicle and habitat development. This would include, but not limited to, workstation design, D&C development, volumetric analysis, training, operations, and human -robotic interaction. HSI is a necessary process for Human Space Flight programs to meet the Agency Human ]System standards and thus mitigate human risks to acceptable levels. NASA has been involved in HSI planning, procedures development, process, and implementation for many years, and has been building several internal and publicly accessible products to facilitate HSI fs inclusion in the NASA Systems Engineering Lifecycle. Some of these products include: NASA STD 3001 Volumes 1 and 2, Human Integration Design Handbook, NASA HSI Implementation Plan, NASA HSI Implementation Plan Templates, NASA HSI Implementation Handbook, and a 2 ]hour short course on HSI delivered as part of the NASA Space and Life Sciences Directorate Academy. These products have been created leveraging industry best practices and lessons learned from other Federal Government agencies.

Whitmore, Mihriban↗

Development of the Resource Prospector Planetary Rover

The Resource Prospector (RP) is an In-­‐Situ Resource Utilization (ISRU) lunar rover mission under study by NASA. RP is planned to launch in 2020 to prospect for subsurface volatiles and to extract oxygen from lunar regolith. The mission will address several of NASA's "Strategic Knowledge Gaps" for lunar exploration. The mission will also address the Global Exploration Roadmap's strategic goal of using local resources for human exploration. The distribution of lunar subsurface volatiles drives the mission requirement for mobility. The spatial distribution is hypothesized to be governed by impact cratering with the top 0.5 m being patchy at scales of 100 m. The mixing time scale increases with depth (less frequent larger impacts). Consequently, increased mobility reduces the depth requirement for sampling. The target RP traverse will extend 1 km radially from the landing site to sample craters of varying sizes. Sampling craters with different ages will reveal possible volatile emplacement history. In 1 Ga, approximately 60-­70 craters of 10 m diameter form per km2. Thus, the rover will need to sample at least ten of these craters, which may require a total traverse path length of 2-­‐3 km. During 2014-­2015, we developed an initial prototype rover for RP. The current design is a solar powered, four-­wheeled vehicle, with hub motor drive, offset four wheel steering, and active suspension. Active suspension provides capabilities including changing vehicle ride height, traversing comparatively large obstacles, and controlling load on the wheels. All-­wheel steering enables the vehicle to point arbitrarily while roving, e.g., to keep the solar array pointed at the sun while in motion. The offset steering combined with active suspension improves driving in soft soil. The rover's on-­board software utilizes NASA's Core Flight Software, which is a reusable flight software environment. During 2015, we completed the initial rover software build, which provides low-­level hardware interfaces, basic mobility control, waypoint driving, odometry, basic error checking, and camera services. Development of the prototype rover has enabled maturation of many of the subsystems to TRL 5. During the next year, we will conduct integrated testing of concepts of operation, navigation, and remote driving tools. In addition, we will perform environmental tests including radiation (avionics), thermal and thermal/vacuum (mechanisms), and gravity offload (mobility).

robotics↗

TPSAS-NF1676L-32967-DND

The Stratospheric Aerosol and Gas Experiment III (SAGE III) was delivered to the International Space Station (ISS) on 23 February 2017. The SAGE III payload was robotically installed on Ex-PRESS Logistics Carrier-4 (ELC-4) on the S3 Truss and began acquiring science measurements on 17 March 2017. The SAGE III telescope and instrument assembly employs the methods of solar occultation and lunar occultation to retrieve near-global vertical profiles of atmospheric ozone, water vapor, nitrogen dioxide, multiwavelength aerosol extinctions, and other gaseous species and atmospheric state parameters. The activities on the ISS contribute to a dynamic operational environment. The attitude changes, EVAs, and the arrival and departure of vehicles require continual consideration when operating. After operating for two years, the SAGE III payload has planned over 20,000 occultation events and acquired approximately 17,000. A significant number of the missed events were because of visiting vehicles blocking the field of view. Using instrument data from these blocked events, the SAGE III team has mapped the structure of the ISS from the perspective of the instrument. Error Correction and Detection (EDAC) methods are necessary to preserve the functionality of the instrument software. On SAGE III the Hexapod Electrical Unit (HEU), which controls the orientation of the telescope, reports whenever an EDAC occurs. By analyzing the EDAC messages in the HEU telemetry, information concerning the orbital environment of the ISS can be obtained. To be presented is a summary of operational considerations when working on ISS along with how instrument data can be used to map the structural and electromagnetic environment of ISS.

Andrew J Peterson↗

Creating and Testing Simulation Software

The goal of this project is to learn about the software development process, specifically the process to test and fix components of the software. The paper will cover the techniques of testing code, and the benefits of using one style of testing over another. It will also discuss the overall software design and development lifecycle, and how code testing plays an integral role in it. Coding is notorious for always needing to be debugged due to coding errors or faulty program design. Writing tests either before or during program creation that cover all aspects of the code provide a relatively easy way to locate and fix errors, which will in turn decrease the necessity to fix a program after it is released for common use. The backdrop for this paper is the Spaceport Command and Control System (SCCS) Simulation Computer Software Configuration Item (CSCI), a project whose goal is to simulate a launch using simulated models of the ground systems and the connections between them and the control room. The simulations will be used for training and to ensure that all possible outcomes and complications are prepared for before the actual launch day. The code being tested is the Programmable Logic Controller Interface (PLCIF) code, the component responsible for transferring the information from the models to the model Programmable Logic Controllers (PLCs), basic computers that are used for very simple tasks.

Heinich, Christina M.↗

A Software Architecture for Semiautonomous Robot Control

A software architecture has been developed to increase the safety and effectiveness with which tasks are performed by robots that are capable of functioning autonomously but sometimes are operated under control by humans. The control system of such a robot designed according to a prior software architecture has no way of taking account of how the environment has changed or what parts of a task were performed during an interval of control by a human, so that errors can occur (and, hence, safety and effectiveness jeopardized) when the human relinquishes control. The present architecture incorporates the control, task-planning, and sensor-based-monitoring features of typical prior autonomous-robot software architectures, plus features for updating information on the environment and planning of tasks during control by a human operator in order to enable the robot to track the actions taken by the operator and to be ready to resume autonomous operation with minimal error. The present architecture also provides a user interface that presents, to the operator, a variety of information on the internal state of the robot and the status of the task.

Kortenkamp, David↗

Experiments in software reliability - Life-critical applications

The paper discusses four reliability data gathering experiments which were conducted using a small sample of programs for two problems having ultrareliability requirements, n-version programming for fault detection, and repetitive run modeling for failure and fault rate estimation. The experimental results agree with those of Nagel and Skrivan in that the program error rates suggest an approximate log-linear pattern and the individual faults occurred with significantly different error rates. Additional analysis of the experimental data raises new questions concerning the phenomenon of interacting faults. This phenomenon may provide one explanation for software reliability decay. The fourth experiment underscored the difficulty in distinguishing between observations of deficiencies in the design of the algorithm and observations of software faults for real-time process control software. These experiments are a part of a program of serial experiments being pursued by the System Validation Methods of NASA-Langley Research Center to find a means of credibly performing reliability evaluations of flight control software.

Dunham, J. R.↗

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.↗

IBM system/360 assembly language interval arithmetic software

Computer software designed to perform interval arithmetic is described. An interval is defined as the set of all real numbers between two given numbers including or excluding one or both endpoints. Interval arithmetic consists of the various elementary arithmetic operations defined on the set of all intervals, such as interval addition, subtraction, union, etc. One of the main applications of interval arithmetic is in the area of error analysis of computer calculations. For example, it has been used sucessfully to compute bounds on sounding errors in the solution of linear algebraic systems, error bounds in numerical solutions of ordinary differential equations, as well as integral equations and boundary value problems. The described software enables users to implement algorithms of the type described in references efficiently on the IBM 360 system.

Phillips, E. J.↗

Projected Impact of Compositional Verification on Current and Future Aviation Safety Risk

The projected impact of compositional verification research conducted by the National Aeronautic and Space Administration System-Wide Safety and Assurance Technologies on aviation safety risk was assessed. Software and compositional verification was described. Traditional verification techniques have two major problems: testing at the prototype stage where error discovery can be quite costly and the inability to test for all potential interactions leaving some errors undetected until used by the end user. Increasingly complex and nondeterministic aviation systems are becoming too large for these tools to check and verify. Compositional verification is a "divide and conquer" solution to addressing increasingly larger and more complex systems. A review of compositional verification research being conducted by academia, industry, and Government agencies is provided. Forty-four aviation safety risks in the Biennial NextGen Safety Issues Survey were identified that could be impacted by compositional verification and grouped into five categories: automation design; system complexity; software, flight control, or equipment failure or malfunction; new technology or operations; and verification and validation. One capability, 1 research action, 5 operational improvements, and 13 enablers within the Federal Aviation Administration Joint Planning and Development Office Integrated Work Plan that could be addressed by compositional verification were identified.

Reveley, Mary S.↗