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 289 records · Page 16
All sourcesNASA NTRSDOE OSTI
NASA NTRS1995

Evaluation of Visualization Software

Visualization software is widely used in scientific and engineering research. But computed visualizations can be very misleading, and the errors are easy to miss. We feel that the software producing the visualizations must be thoroughly evaluated and the evaluation process as well as the results must be made available. Testing and evaluation of visualization software is not a trivial problem. Several methods used in testing other software are helpful, but these methods are (apparently) often not used. When they are used, the description and results are generally not available to the end user. Additional evaluation methods specific to visualization must also be developed. We present several useful approaches to evaluation, ranging from numerical analysis of mathematical portions of algorithms to measurement of human performance while using visualization systems. Along with this brief survey, we present arguments for the importance of evaluations and discussions of appropriate use of some methods.

Globus, Al↗
NASA NTRS2002

Single event upset susceptibility testing of the Xilinx Virtex II FPGA

Heavy ion testing of the Xilinx Virtex IZ was conducted on the configuration, block RAM and user flip flop cells to determine their single event upset susceptibility using LETs of 1.2 to 60 MeVcm^2/mg. A software program specifically designed to count errors in the FPGA is used to reveal L1/e values and single-event-functional interrupt failures.

FPGA Xilinx Virtex static test single event upset↗
NASA NTRS2002

Single event upset suspectibility testing of the Xilinx Virtex II FPGA

Heavy ion testing of the Xilinx Virtex II was conducted on the configuration, block RAM and user flip flop cells to determine their static single-event upset susceptibility using LETs of 1.2 to 60 MeVcm^2/mg. A software program specifically designed to count errors in the FPGA was used to reveal L1/e, values (the LET at which the cross section is l/e times the saturation cross-section) and single-event functional-interrupt failures.

FPGA Virtex II SEU↗
NASA NTRS2007

Volatile Organic Analyzer (VOA) in 2006: Repair, Revalidation, and Restart of Elektron Even

The Volatile Organic Analyzer (VOA) had been providing valuable data on trace contaminants in the atmosphere of the International Space Station (ISS) from January 2002 through May 2003. Component temperature errors, detected by the VOA s software, shut down the unit in May 2003, but in early 2005 on orbit diagnostics verified fuse failures had disabled both VOA channels. An in-flight maintenance (IFM) session in December 2005 returned the VOA to an operational mode by January 2006. This paper will present the on-orbit data from 2006 that were used to revalidate the VOA, and provide an overview of the VOA s contributions during the Elecktron contingency event that occurred on ISS in September 2006.

Limero, Thomas↗
NASA NTRS2009

Direct-Solve Image-Based Wavefront Sensing

A method of wavefront sensing (more precisely characterized as a method of determining the deviation of a wavefront from a nominal figure) has been invented as an improved means of assessing the performance of an optical system as affected by such imperfections as misalignments, design errors, and fabrication errors. The method is implemented by software running on a single-processor computer that is connected, via a suitable interface, to the image sensor (typically, a charge-coupled device) in the system under test. The software collects a digitized single image from the image sensor. The image is displayed on a computer monitor. The software directly solves for the wavefront in a time interval of a fraction of a second. A picture of the wavefront is displayed. The solution process involves, among other things, fast Fourier transforms. It has been reported to the effect that some measure of the wavefront is decomposed into modes of the optical system under test, but it has not been reported whether this decomposition is postprocessing of the solution or part of the solution process.

Lyon, Richard G.↗
NASA NTRS2011

The Legacy of Space Shuttle Flight Software

The initial goals of the Space Shuttle Program required that the avionics and software systems blaze new trails in advancing avionics system technology. Many of the requirements placed on avionics and software were accomplished for the first time on this program. Examples include comprehensive digital fly-by-wire technology, use of a digital databus for flight critical functions, fail operational/fail safe requirements, complex automated redundancy management, and the use of a high-order software language for flight software development. In order to meet the operational and safety goals of the program, the Space Shuttle software had to be extremely high quality, reliable, robust, reconfigurable and maintainable. To achieve this, the software development team evolved a software process focused on continuous process improvement and defect elimination that consistently produced highly predictable and top quality results, providing software managers the confidence needed to sign each Certificate of Flight Readiness (COFR). This process, which has been appraised at Capability Maturity Model (CMM)/Capability Maturity Model Integration (CMMI) Level 5, has resulted in one of the lowest software defect rates in the industry. This paper will present an overview of the evolution of the Primary Avionics Software System (PASS) project and processes over thirty years, an argument for strong statistical control of software processes with examples, an overview of the success story for identifying and driving out errors before flight, a case study of the few significant software issues and how they were either identified before flight or slipped through the process onto a flight vehicle, and identification of the valuable lessons learned over the life of the project.

Hickey, Christopher J.↗
NASA NTRS2005

Contour Error Map Algorithm

The contour error map (CEM) algorithm and the software that implements the algorithm are means of quantifying correlations between sets of time-varying data that are binarized and registered on spatial grids. The present version of the software is intended for use in evaluating numerical weather forecasts against observational sea-breeze data. In cases in which observational data come from off-grid stations, it is necessary to preprocess the observational data to transform them into gridded data. First, the wind direction is gridded and binarized so that D(i,j;n) is the input to CEM based on forecast data and d(i,j;n) is the input to CEM based on gridded observational data. Here, i and j are spatial indices representing 1.25-km intervals along the west-to-east and south-to-north directions, respectively; and n is a time index representing 5-minute intervals. A binary value of D or d = 0 corresponds to an offshore wind, whereas a value of D or d = 1 corresponds to an onshore wind. CEM includes two notable subalgorithms: One identifies and verifies sea-breeze boundaries; the other, which can be invoked optionally, performs an image-erosion function for the purpose of attempting to eliminate river-breeze contributions in the wind fields.

Merceret, Francis↗
NASA NTRS2018

Air Traffic Management-eXploration Testbed for Urban Air Mobility Research and Development

The presentation will describe the architecture, current capabilities and some future enhancements of the testbed that is being developed at the National Aeronautics and Space Administration (NASA) to enable benefit, impact, safety and cost assessments for accelerating the deployment of air traffic management concept and technologies in the national airspace system. The testbed will support analysis of operational feasibility of urban air mobility operations, a part of NASA's Air Traffic Management eXploration project, and provide the data needed by regulatory agencies charged with public safety. Introduction of concepts and technologies, especially new concepts and technologies, is difficult and often takes decades because of the inability to assess the operational impact of the interaction between the proposed concept and technology and operationally deployed systems in terms of system-wide safety, traffic flow efficiency, roles and workload of controllers and traffic managers, and impact on airlines and other operators. To overcome these limitations, the testbed is developing infrastructure to enable mathematical modeling, human-in-the-loop evaluations and testing with operational systems in a simulated environment. In addition to the difficulty of establishing communications between geographically distributed systems, downloading/installing software, and management of startup, error-handling and shutdown, a major impediment for conducting simulations and human-in-the-loop testing with operational systems is the tedious manual scenario generation process. Several of these difficulties have been addressed in the current state of the testbed. The testbed can be described in terms of the following elements (1) web-based frontend and backend, (2) Testbed Builder, (3) Data Distribution Service, (4) Component Library, (5) Simulation Management, and (6) Scenario Generation. The web-based frontend and backend enable the user to interact with the testbed for tasks such as composing a simulation, running a simulation and retrieving output data. The Testbed Builder application launched from the web frontend is a graphical user interface for the user to drag-and-drop and connect predefined blocks for composing a simulation/scenario generation task. The Builder writes a set of instructions for Simulation Management based on the links between the blocks and the block properties such as the component (executable) associated with a particular block. Management of the distributed simulation is accomplished by Execution and Component Managers. Execution Manager interprets the instructions provided by the Builder to instruct the Component Managers to download components from the Component Library to specified computers and to start them up. Once started, the components communicate with each other by publishing messages and subscribing to messages that are delivered by the Data Distribution Service. The Scenario Generation capability can be used for creating traffic scenarios for Multi-Aircraft Control System, which has been used extensively at NASA for human-in-the-loop-based concept evaluations. The presentation will provide a testbed enabled example scenario of Multi-Aircraft Control System based simulation in which the urban air mobility pilot using the conflict detection and resolution system would interact with the air traffic controllers for resolving conflicts with other aircraft during terminal area operations.

Testbed↗
NASA NTRS2018

Air Traffic Management-eXploration Testbed for Urban Air Mobility Research and Development

The presentation will describe the architecture, current capabilities and some future enhancements of the testbed that is being developed at the National Aeronautics and Space Administration (NASA) to enable benefit, impact, safety and cost assessments for accelerating the deployment of air traffic management concept and technologies in the national airspace system. The testbed will support analysis of operational feasibility of urban air mobility operations, a part of NASA's Air Traffic Management eXploration project, and provide the data needed by regulatory agencies charged with public safety. Introduction of concepts and technologies, especially new concepts and technologies, is difficult and often takes decades because of the inability to assess the operational impact of the interaction between the proposed concept and technology and operationally deployed systems in terms of system-wide safety, traffic flow efficiency, roles and workload of controllers and traffic managers, and impact on airlines and other operators. To overcome these limitations, the testbed is developing infrastructure to enable mathematical modeling, human-in-the-loop evaluations and testing with operational systems in a simulated environment. In addition to the difficulty of establishing communications between geographically distributed systems, downloading/installing software, and management of startup, error-handling and shutdown, a major impediment for conducting simulations and human-in-the-loop testing with operational systems is the tedious manual scenario generation process. Several of these difficulties have been addressed in the current state of the testbed. The testbed can be described in terms of the following elements- (1) web-based frontend and backend, (2) Testbed Builder, (3) Data Distribution Service, (4) Component Library, (5) Simulation Management, and (6) Scenario Generation. The web-based frontend and backend enable the user to interact with the testbed for tasks such as composing a simulation, running a simulation and retrieving output data. The Testbed Builder application launched from the web frontend is a graphical user interface for the user to drag-and-drop and connect predefined blocks for composing a simulation/scenario generation task. The Builder writes a set of instructions for Simulation Management based on the links between the blocks and the block properties such as the component (executable) associated with a particular block. Management of the distributed simulation is accomplished by Execution and Component Managers. Execution Manager interprets the instructions provided by the Builder to instruct the Component Managers to download components from the Component Library to specified computers and to start them up. Once started, the components communicate with each other by publishing messages and subscribing to messages that are delivered by the Data Distribution Service. The Scenario Generation capability can be used for creating traffic scenarios for Multi-Aircraft Control System, which has been used extensively at NASA for human-in-the-loop-based concept evaluations. The presentation will provide a testbed enabled example scenario of Multi-Aircraft Control System based simulation in which the urban air mobility pilot using the conflict detection and resolution system would interact with the air traffic controllers for resolving conflicts with other aircraft during terminal area operations.

Simulation↗
NASA NTRS2011

Determination of Barometric Altimeter Errors for the Orion Exploration Flight Test-1 Entry

The EFT-1 mission is the unmanned flight test for the upcoming Multi-Purpose Crew Vehicle (MPCV). During entry, the EFT-1 vehicle will trigger several Landing and Recovery System (LRS) events, such as parachute deployment, based on onboard altitude information. The primary altitude source is the filtered navigation solution updated with GPS measurement data. The vehicle also has three barometric altimeters that will be used to measure atmospheric pressure during entry. In the event that GPS data is not available during entry, the altitude derived from the barometric altimeter pressure will be used to trigger chute deployment for the drogues and main parachutes. Therefore it is important to understand the impact of error sources on the pressure measured by the barometric altimeters and on the altitude derived from that pressure. There are four primary error sources impacting the sensed pressure: sensor errors, Analog to Digital conversion errors, aerodynamic errors, and atmosphere modeling errors. This last error source is induced by the conversion from pressure to altitude in the vehicle flight software, which requires an atmosphere model such as the US Standard 1976 Atmosphere model. There are several secondary error sources as well, such as waves, tides, and latencies in data transmission. Typically, for error budget calculations it is assumed that all error sources are independent, normally distributed variables. Thus, the initial approach to developing the EFT-1 barometric altimeter altitude error budget was to create an itemized error budget under these assumptions. This budget was to be verified by simulation using high fidelity models of the vehicle hardware and software. The simulation barometric altimeter model includes hardware error sources and a data-driven model of the aerodynamic errors expected to impact the pressure in the midbay compartment in which the sensors are located. The aerodynamic model includes the pressure difference between the midbay compartment and the free stream pressure as a function of altitude, oscillations in sensed pressure due to wake effects, and an acoustics model capturing fluctuations in pressure due to motion of the passive vents separating the barometric altimeters from the outside of the vehicle.

Brown, Denise L.↗
NASA NTRS2015

Star Tracker Performance Estimate with IMU

A software tool for estimating cross-boresight error of a star tracker combined with an inertial measurement unit (IMU) was developed to support trade studies for the Integrated Radio and Optical Communication project (iROC) at the National Aeronautics and Space Administration Glenn Research Center. Typical laser communication systems, such as the Lunar Laser Communication Demonstration (LLCD) and the Laser Communication Relay Demonstration (LCRD), use a beacon to locate ground stations. iROC is investigating the use of beaconless precision laser pointing to enable laser communication at Mars orbits and beyond. Precision attitude knowledge is essential to the iROC mission to enable high-speed steering of the optical link. The preliminary concept to achieve this precision attitude knowledge is to use star trackers combined with an IMU. The Star Tracker Accuracy (STAcc) software was developed to rapidly assess the capabilities of star tracker and IMU configurations. STAcc determines the overall cross-boresight error of a star tracker with an IMU given the characteristic parameters: quantum efficiency, aperture, apparent star magnitude, exposure time, field of view, photon spread, detector pixels, spacecraft slew rate, maximum stars used for quaternion estimation, and IMU angular random walk. This paper discusses the supporting theory used to construct STAcc, verification of the program and sample results.

Error Budget↗
NASA NTRS1984

Writing executable assertions to test flight software

An executable assertion is a logical statement about the variables or a block of code. If there is no error during execution, the assertion statement results in a true value. Executable assertions can be used for dynamic testing of software. They can be employed for validation during the design phase, and exception and error detection during the operation phase. The present investigation is concerned with the problem of writing executable assertions, taking into account the use of assertions for testing flight software. They can be employed for validation during the design phase, and for exception handling and error detection during the operation phase The digital flight control system and the flight control software are discussed. The considered system provides autopilot and flight director modes of operation for automatic and manual control of the aircraft during all phases of flight. Attention is given to techniques for writing and using assertions to test flight software, an experimental setup to test flight software, and language features to support efficient use of assertions.

Mahmood, A.↗
NASA NTRS1985

Noncoherent sampling technique for communications parameter estimations

This paper presents a method of noncoherent demodulation of the PSK signal for signal distortion analysis at the RF interface. The received RF signal is downconverted and noncoherently sampled for further off-line processing. Any mismatch in phase and frequency is then compensated for by the software using the estimation techniques to extract the baseband waveform, which is needed in measuring various signal parameters. In this way, various kinds of modulated signals can be treated uniformly, independent of modulation format, and additional distortions introduced by the receiver or the hardware measurement instruments can thus be eliminated. Quantization errors incurred by digital sampling and ensuing software manipulations are analyzed and related numerical results are presented also.

Su, Y. T.↗
NASA NTRS1988

The Sizing and Optimization Language, (SOL): Computer language for design problems

The Sizing and Optimization Language, (SOL), a new high level, special purpose computer language was developed to expedite application of numerical optimization to design problems and to make the process less error prone. SOL utilizes the ADS optimization software and provides a clear, concise syntax for describing an optimization problem, the OPTIMIZE description, which closely parallels the mathematical description of the problem. SOL offers language statements which can be used to model a design mathematically, with subroutines or code logic, and with existing FORTRAN routines. In addition, SOL provides error checking and clear output of the optimization results. Because of these language features, SOL is best suited to model and optimize a design concept when the model consits of mathematical expressions written in SOL. For such cases, SOL's unique syntax and error checking can be fully utilized. SOL is presently available for DEC VAX/VMS systems. A SOL package is available which includes the SOL compiler, runtime library routines, and a SOL reference manual.

Lucas, Stephen H.↗
NASA NTRS2013

MPST Software: grl_suppdoc

Due to the nature of the GRAIL mission, the GRAIL Mission Planning and Sequence Team (MPST) is required to generate ground and uplink products faster than ever done before. The existing correct_transmitter_min_dur tool that provides a similar function to grl_suppdoc lacks the ability to operate accurately or quickly enough to support the rapid turnaround required of the GRAIL MPST. The GRAIL MPST was required to build this new tool to facilitate the ground and uplink generation processes to meet a tight sequence development timeline. The grl_suppdoc tool enables the GRAIL MPST to generate automatically Deep Space Network (DSN) transmitter suppressions based on short uplinks that are found in the ground/modeled Predicted Events File (PEF). The grl_suppdoc script automatically generates applicable DSN uplink suppressions in the form of a Spacecraft Activity Sequence File (SASF) to protect the GRAIL project from short DSN uplink windows, which can be cause for operator error at the DSN antennas. Currently, no software exists that provides this functionality at the efficiency required for GRAIL sequence team operations. Compared to a manual process, this script reduces human error and saves considerable man-hours by automating and streamlining the mission planning and sequencing task for the GRAIL mission.

Call, Jared A.↗
NASA NTRS1989

Determination of Earth orientation using the Global Positioning System

Modern spacecraft tracking and navigation require highly accurate Earth-orientation parameters. For near-real-time applications, errors in these quantities and their extrapolated values are a significant error source. A globally distributed network of high-precision receivers observing the full Global Positioning System (GPS) configuration of 18 or more satellites may be an efficient and economical method for the rapid determination of short-term variations in Earth orientation. A covariance analysis using the JPL Orbit Analysis and Simulation Software (OASIS) was performed to evaluate the errors associated with GPS measurements of Earth orientation. These GPS measurements appear to be highly competitive with those from other techniques and can potentially yield frequent and reliable centimeter-level Earth-orientation information while simultaneously allowing the oversubscribed Deep Space Network (DSN) antennas to be used more for direct project support.

Freedman, A. P.↗