Search NASA⌕ Search

SEARCH · Search NASA

Results for “Debugging”

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 433 records · Page 24

Agent Architecture for Aviation Data Integration System

This paper describes the proposed agent-based architecture of the Aviation Data Integration System (ADIS). ADIS is a software system that provides integrated heterogeneous data to support aviation problem-solving activities. Examples of aviation problem-solving activities include engineering troubleshooting, incident and accident investigation, routine flight operations monitoring, safety assessment, maintenance procedure debugging, and training assessment. A wide variety of information is typically referenced when engaging in these activities. Some of this information includes flight recorder data, Automatic Terminal Information Service (ATIS) reports, Jeppesen charts, weather data, air traffic control information, safety reports, and runway visual range data. Such wide-ranging information cannot be found in any single unified information source. Therefore, this information must be actively collected, assembled, and presented in a manner that supports the users problem-solving activities. This information integration task is non-trivial and presents a variety of technical challenges. ADIS has been developed to do this task and it permits integration of weather, RVR, radar data, and Jeppesen charts with flight data. ADIS has been implemented and used by several airlines FOQA teams. The initial feedback from airlines is that such a system is very useful in FOQA analysis. Based on the feedback from the initial deployment, we are developing a new version of the system that would make further progress in achieving following goals of our project.

Kulkarni, Deepak↗

Digital Channel Simulator Developed and Tested

The Digital Channel Simulator (DCS) is a real-time test set developed in-house by the NASA Glenn Research Center at Lewis Field that simulates the characteristics of the modulator, demodulator, and transmission medium in a typical communications system to enable controlled laboratory testing of codec pairs. The DCS can support data rates up to 100 megasymbols per second (Msymbols/sec) with symbol sizes up to 10 bits and is compatible with both TTL (transistor transistor logic) and ECL (emitter coupled logic) interfaces. Because of its use of digital integrated circuits (IC's), the DCS offers the user accurate and repeatable testing while maintaining a simple reconfiguration of the modulation scheme and noise characteristics. The PC-based graphical user interface (GUI) assures user friendly operation for configuring, controlling, and monitoring the DCS and system during tests. In a typical communications system, the modulator places a symbol in constellation space and puts it on a carrier to be sent to the demodulator. Because of noise on the channel, the I and Q position in constellation space cannot be recovered exactly, and the received coordinates shift. To mimic this process in the laboratory, the DCS uses a mapper to place the symbol in constellation space. It simulates the shift in coordinates by digitally adding "noise" to the I and Q values. The mapper and noise source are implemented in lookup tables. Modulation schemes and noise characteristics are set by the values loaded in these tables. The mapper also has a pass-through mode to facilitate modulator testing, allowing noise to be added to 8-bit I and Q values of modulated data without a second mapping. To achieve high symbol rates, eight processing circuits are placed in parallel between an ECL demultiplexer and multiplexer. A graphical user interface was developed to calculate, load, and verify the values for the lookup tables. This interface can also be used to debug and verify proper operation of the channel simulator or to control an experiment. Operation of the DCS has been verified through three tests: a low-speed comprehensive system test, a high-speed (20 Msymbols/sec) test of the TTL interface, and a high-speed (100 Msymbols/sec) test of the ECL interface. The DCS is now ready for use by NASA and external customers.

Bizon, Thomas P.↗

Development and operations of the astrophysics data system

Abstract service - Continued regular updates of abstracts in the databases, both at SA0 and at all mirror sites. - Modified loading scripts to accommodate changes in data format (PhyS) - Discussed data deliveries with providers to clear up problems with format or other errors (EGU) - Continued inclusion of large numbers of historical literature volumes and physics conference volumes xeroxed from the library. - Performed systematic fixes on some data sets in the database to account for changes in article numbering (AGU journals) - Implemented linking of ADS bibliographic records with multimedia files - Debugged and fixed obscure connection problems with the ADS Korean mirror site which were preventing successful updates of the data holdings. - Wrote procedure to parse citation data and characterize an ADS record based on its citation ratios within each database.

Murray, Stephen S.↗

Fast Whole-Engine Stirling Analysis

This presentation discusses the simulation approach to whole-engine for physical consistency, REV regenerator modeling, grid layering for smoothness, and quality, conjugate heat transfer method adjustment, high-speed low cost parallel cluster, and debugging.

Dyson, Rodger W.↗

Modernizing Fortran 77 legacy codes

Legacy software has great value since it is generally well debugged, produces results that are trusted and is actively meeting end-user goals. The amount of hidden expert knowledge embedded in such software can be significant, making its preservation important.

Fortran scientific programming↗

Towards an Intelligent Planning Knowledge Base Development Environment

ract describes work in developing knowledge base editing and debugging tools for the Multimission VICAR Planner (MVP) system. MVP uses artificial intelligence planning techniques to automatically construct executable complex image processing procedures (using models of the smaller constituent image processing requests made to the JPL Multimission Image Processing Laboratory.

image processing knowledge bases artificial intell↗

Symbolic LTL Compilation for Model Checking: Extended Abstract

In Linear Temporal Logic (LTL) model checking, we check LTL formulas representing desired behaviors against a formal model of the system designed to exhibit these behaviors. To accomplish this task, the LTL formulas must be translated into automata [21]. We focus on LTL compilation by investigating LTL satisfiability checking via a reduction to model checking. Having shown that symbolic LTL compilation algorithms are superior to explicit automata construction algorithms for this task [16], we concentrate here on seeking a better symbolic algorithm.We present experimental data comparing algorithmic variations such as normal forms, encoding methods, and variable ordering and examine their effects on performance metrics including processing time and scalability. Safety critical systems, such as air traffic control, life support systems, hazardous environment controls, and automotive control systems, pervade our daily lives, yet testing and simulation alone cannot adequately verify their reliability [3]. Model checking is a promising approach to formal verification for safety critical systems which involves creating a formal mathematical model of the system and translating desired safety properties into a formal specification for this model. The complement of the specification is then checked against the system model. When the model does not satisfy the specification, model-checking tools accompany this negative answer with a counterexample, which points to an inconsistency between the system and the desired behaviors and aids debugging efforts.

Rozier, Kristin Y.↗

Lessons Learned from the Aquarius Radiometer Engineering Model

The Aquarius instrument is a combination microwave radiometer and scatterometer operating in the L-band for the measurement of sea surface salinity (SSS) over the open-ocean. "The Aquarius science goals are to observe and model the processes that relate salinity variations to climatic changes in the global cycling of water and to understand how these variations influence the general ocean circulation. By measuring salinity globally and synoptically every month for 3 years, Aquarius will provide an unprecedented new view of the ocean's role in climate." (http://aquarius.asfc.nasa.gov on Jan. 4, 2007). To launch in 2009, Aquarius will provide 8-day global coverage and monthly-averaged salinity maps at approx.120-km spatial resolution. Because the microwave emissivity of the ocean surface is weakly dependent upon salinity, the Aquarius radiometer remain sufficiently stable to provide accurate salinity measurements. An engineering model (EM) of one radiometer receiver was developed and tested for functionality and performance at NASA's Goddard Space Flight Center. It was tested for long-term stability starting July 27,2006. Two discrepancies where found at the start of testing and a four-month correction process ensued. This paper covers the testing and debugging of the EM radiometer through resolution of the problems. The radiometer is required to have calibration stability of less than or equal to 0.15 K over 7 days. The radiometer is in a three-beam push-broom configuration with each beam being an independent three-state Dicke radiometer (antenna, reference load, and additive noise). Internal noise diodes and reference loads provide periodic and rapid calibration of the receiver. Front-end loss contributions must be corrected as the lossy components are outside the calibration loop. A key design feature for obtaining stability is active thermal control of the front-end lossy components and the RF receiver. The thermal stability is predicted to be about 0.1 C over an orbit and no more than 1 C over a year. The radiometric stability requirement is 0.13 K rms 1 7 days without using temperature corrections. Temperature corrections and post-launch calibration are expected to extend the stability period through the life of the mission.

Piepmeier, Jeffrey↗

Building a GPS Receiver for Space Lessons Learned

Over the past 4 years the Component Systems and Hardware branch at NASA GSFC has pursued an inhouse effort to build a unique space-flight GPS receiver. This effort has resulted in the Navigator GPS receiver. Navigator's first flight opportunity will come with the STS-125 HST-SM4 mission in August 2008. This paper covers the overall hardware design for the receiver and the difficulties encountered during the transition from the breadboard design to the final flight hardware design. Among the different lessons learned, the paper stresses the importance of selecting and verifying parts that are appropriate for space applications, as well as what happens when these parts are not accurately characterized by their datasheets. Additionally, the paper discusses what analysis needs to be performed when deciding system frequencies and filters. The presentation also covers how to prepare for thermal vacuum testing, and problems that may arise during vibration testing. It also contains what criteria should be considered when determining which portions of a design to create in-house, and which portions to license from a third party. Finally, the paper shows techniques which have proven to be extraordinarily helpful in debugging and analysis.

Sirotzky, Steve↗

Adjoint-Based Methodology for Time-Dependent Optimization

This paper presents a discrete adjoint method for a broad class of time-dependent optimization problems. The time-dependent adjoint equations are derived in terms of the discrete residual of an arbitrary finite volume scheme which approximates unsteady conservation law equations. Although only the 2-D unsteady Euler equations are considered in the present analysis, this time-dependent adjoint method is applicable to the 3-D unsteady Reynolds-averaged Navier-Stokes equations with minor modifications. The discrete adjoint operators involving the derivatives of the discrete residual and the cost functional with respect to the flow variables are computed using a complex-variable approach, which provides discrete consistency and drastically reduces the implementation and debugging cycle. The implementation of the time-dependent adjoint method is validated by comparing the sensitivity derivative with that obtained by forward mode differentiation. Our numerical results show that O(10) optimization iterations of the steepest descent method are needed to reduce the objective functional by 3-6 orders of magnitude for test problems considered.

Yamaleev, N. K.↗

Injecting Artificial Memory Errors Into a Running Computer Program

Single-event upsets (SEUs) or bitflips are computer memory errors caused by radiation. BITFLIPS (Basic Instrumentation Tool for Fault Localized Injection of Probabilistic SEUs) is a computer program that deliberately injects SEUs into another computer program, while the latter is running, for the purpose of evaluating the fault tolerance of that program. BITFLIPS was written as a plug-in extension of the open-source Valgrind debugging and profiling software. BITFLIPS can inject SEUs into any program that can be run on the Linux operating system, without needing to modify the program s source code. Further, if access to the original program source code is available, BITFLIPS offers fine-grained control over exactly when and which areas of memory (as specified via program variables) will be subjected to SEUs. The rate of injection of SEUs is controlled by specifying either a fault probability or a fault rate based on memory size and radiation exposure time, in units of SEUs per byte per second. BITFLIPS can also log each SEU that it injects and, if program source code is available, report the magnitude of effect of the SEU on a floating-point value or other program variable.

Bornstein, Benjamin J.↗

Support for Diagnosis of Custom Computer Hardware

The Coldfire SDN Diagnostics software is a flexible means of exercising, testing, and debugging custom computer hardware. The software is a set of routines that, collectively, serve as a common software interface through which one can gain access to various parts of the hardware under test and/or cause the hardware to perform various functions. The routines can be used to construct tests to exercise, and verify the operation of, various processors and hardware interfaces. More specifically, the software can be used to gain access to memory, to execute timer delays, to configure interrupts, and configure processor cache, floating-point, and direct-memory-access units. The software is designed to be used on diverse NASA projects, and can be customized for use with different processors and interfaces. The routines are supported, regardless of the architecture of a processor that one seeks to diagnose. The present version of the software is configured for Coldfire processors on the Subsystem Data Node processor boards of the Solar Dynamics Observatory. There is also support for the software with respect to Mongoose V, RAD750, and PPC405 processors or their equivalents.

Molock, Dwaine S.↗

VERSE - Virtual Equivalent Real-time Simulation

Distributed real-time simulations provide important timing validation and hardware in the- loop results for the spacecraft flight software development cycle. Occasionally, the need for higher fidelity modeling and more comprehensive debugging capabilities - combined with a limited amount of computational resources - calls for a non real-time simulation environment that mimics the real-time environment. By creating a non real-time environment that accommodates simulations and flight software designed for a multi-CPU real-time system, we can save development time, cut mission costs, and reduce the likelihood of errors. This paper presents such a solution: Virtual Equivalent Real-time Simulation Environment (VERSE). VERSE turns the real-time operating system RTAI (Real-time Application Interface) into an event driven simulator that runs in virtual real time. Designed to keep the original RTAI architecture as intact as possible, and therefore inheriting RTAI's many capabilities, VERSE was implemented with remarkably little change to the RTAI source code. This small footprint together with use of the same API allows users to easily run the same application in both real-time and virtual time environments. VERSE has been used to build a workstation testbed for NASA's Space Interferometry Mission (SIM PlanetQuest) instrument flight software. With its flexible simulation controls and inexpensive setup and replication costs, VERSE will become an invaluable tool in future mission development.

virtual real time↗

Auto-Generated Semantic Processing Services

Auto-Generated Semantic Processing (AGSP) Services is a suite of software tools for automated generation of other computer programs, denoted cross-platform semantic adapters, that support interoperability of computer-based communication systems that utilize a variety of both new and legacy communication software running in a variety of operating- system/computer-hardware combinations. AGSP has numerous potential uses in military, space-exploration, and other government applications as well as in commercial telecommunications. The cross-platform semantic adapters take advantage of common features of computer- based communication systems to enforce semantics, messaging protocols, and standards of processing of streams of binary data to ensure integrity of data and consistency of meaning among interoperating systems. The auto-generation aspect of AGSP Services reduces development time and effort by emphasizing specification and minimizing implementation: In effect, the design, building, and debugging of software for effecting conversions among complex communication protocols, custom device mappings, and unique data-manipulation algorithms is replaced with metadata specifications that map to an abstract platform-independent communications model. AGSP Services is modular and has been shown to be easily integrable into new and legacy NASA flight and ground communication systems.

Davis, Rodney↗

Arrays of Miniature Microphones for Aeroacoustic Testing

A phased-array system comprised of custom-made and commercially available microelectromechanical system (MEMS) silicon microphones and custom ancillary hardware has been developed for use in aeroacoustic testing in hard-walled and acoustically treated wind tunnels. Recent advances in the areas of multi-channel signal processing and beam forming have driven the construction of phased arrays containing ever-greater numbers of microphones. Traditional obstacles to this trend have been posed by (1) the high costs of conventional condenser microphones, associated cabling, and support electronics and (2) the difficulty of mounting conventional microphones in the precise locations required for high-density arrays. The present development overcomes these obstacles. One of the hallmarks of the new system is a series of fabricated platforms on which multiple microphones can be mounted. These mounting platforms, consisting of flexible polyimide circuit-board material (see left side of figure), include all the necessary microphone power and signal interconnects. A single bus line connects all microphones to a common power supply, while the signal lines terminate in one or more data buses on the sides of the circuit board. To minimize cross talk between array channels, ground lines are interposed as shields between all the data bus signal lines. The MEMS microphones are electrically connected to the boards via solder pads that are built into the printed wiring. These flexible circuit boards share many characteristics with their traditional rigid counterparts, but can be manufactured much thinner, as small as 0.1 millimeter, and much lighter with boards weighing as much as 75 percent less than traditional rigid ones. For a typical hard-walled wind-tunnel installation, the flexible printed-circuit board is bonded to the tunnel wall and covered with a face sheet that contains precise cutouts for the microphones. Once the face sheet is mounted, a smooth surface is established over the entire array due to the flush mounting of all microphones (see right side of figure). The face sheet is made from a continuous glass-woven-fabric base impregnated with an epoxy resin binder. This material offers a combination of high mechanical strength and low dielectric loss, making it suitable for withstanding the harsh test section environment present in many wind tunnels, while at the same time protecting the underlying polyimide board. Customized signal-conditioning hardware consisting of line drivers and antialiasing filters are coupled with the array. The line drivers are constructed using low-supply-current, high-gain-bandwidth operational amplifiers designed to transmit the microphone signals several dozen feet from the array to external acquisition hardware. The anti-alias filters consist of individual Chebyshev low-pass filters (one for each microphone channel) housed on small printed-circuit boards mounted on one or more motherboards. The mother/daughter board design results in a modular system, which is easy to debug and service and which enables the filter characteristics to be changed by swapping daughter boards with ones containing different filter parameters. The filter outputs are passed to commercially- available acquisition hardware to digitize and store the conditioned microphone signals. Wind-tunnel testing of the new MEMS microphone polyimide mounting system shows that the array performance is comparable to that of traditional arrays, but with significantly less cost of construction.

Shams, Qamar A.↗

"Smart" Sensor Module

An assembly that contains a sensor, sensor-signal-conditioning circuitry, a sensor-readout analog-to-digital converter (ADC), data-storage circuitry, and a microprocessor that runs special-purpose software and communicates with one or more external computer(s) has been developed as a prototype of "smart" sensor modules for monitoring the integrity and functionality (the "health") of engineering systems. Although these modules are now being designed specifically for use on rocket-engine test stands, it is anticipated that they could also readily be designed to be incorporated into health-monitoring subsystems of such diverse engineering systems as spacecraft, aircraft, land vehicles, bridges, buildings, power plants, oilrigs, and defense installations. The figure is a simplified block diagram of the "smart" sensor module. The analog sensor readout signal is processed by the ADC, the digital output of which is fed to the microprocessor. By means of a standard RS-232 cable, the microprocessor is connected to a local personal computer (PC), from which software is downloaded into a randomaccess memory in the microprocessor. The local PC is also used to debug the software. Once the software is running, the local PC is disconnected and the module is controlled by, and all output data from the module are collected by, a remote PC via an Ethernet bus. Several smart sensor modules like this one could be connected to the same Ethernet bus and controlled by the single remote PC. The software running in the microprocessor includes driver programs for operation of the sensor, programs that implement self-assessment algorithms, programs that implement protocols for communication with the external computer( s), and programs that implement evolutionary methodologies to enable the module to improve its performance over time. The design of the module and of the health-monitoring system of which it is a part reflects the understanding that the main purpose of a health-monitoring system is to detect damage and, therefore, the health-monitoring system must be able to function effectively in the presence of damage and should be capable of distinguishing between damage to itself and damage to the system being monitored. A major benefit afforded by the self-assessment algorithms is that in the output of the module, the sensor data indicative of the health of the engineering system being monitored are coupled with a confidence factor that quantifies the degree of reliability of the data. Hence, the output includes information on the health of the sensor module itself in addition to information on the health of the engineering system being monitored.

Mahajan, Ajay↗

Model Checker for Java Programs

Java Pathfinder (JPF) is a verification and testing environment for Java that integrates model checking, program analysis, and testing. JPF consists of a custom-made Java Virtual Machine (JVM) that interprets bytecode, combined with a search interface to allow the complete behavior of a Java program to be analyzed, including interleavings of concurrent programs. JPF is implemented in Java, and its architecture is highly modular to support rapid prototyping of new features. JPF is an explicit-state model checker, because it enumerates all visited states and, therefore, suffers from the state-explosion problem inherent in analyzing large programs. It is suited to analyzing programs less than 10kLOC, but has been successfully applied to finding errors in concurrent programs up to 100kLOC. When an error is found, a trace from the initial state to the error is produced to guide the debugging. JPF works at the bytecode level, meaning that all of Java can be model-checked. By default, the software checks for all runtime errors (uncaught exceptions), assertions violations (supports Java s assert), and deadlocks. JPF uses garbage collection and symmetry reductions of the heap during model checking to reduce state-explosion, as well as dynamic partial order reductions to lower the number of interleavings analyzed. JPF is capable of symbolic execution of Java programs, including symbolic execution of complex data such as linked lists and trees. JPF is extensible as it allows for the creation of listeners that can subscribe to events during searches. The creation of dedicated code to be executed in place of regular classes is supported and allows users to easily handle native calls and to improve the efficiency of the analysis.

Visser, Willem↗

The Kepler Science Operations Center Pipeline Framework Extensions

The Kepler Science Operations Center (SOC) is responsible for several aspects of the Kepler Mission, including managing targets, generating on-board data compression tables, monitoring photometer health and status, processing the science data, and exporting the pipeline products to the mission archive. We describe how the generic pipeline framework software developed for Kepler is extended to achieve these goals, including pipeline configurations for processing science data and other support roles, and custom unit of work generators that control how the Kepler data are partitioned and distributed across the computing cluster. We describe the interface between the Java software that manages the retrieval and storage of the data for a given unit of work and the MATLAB algorithms that process these data. The data for each unit of work are packaged into a single file that contains everything needed by the science algorithms, allowing these files to be used to debug and evolve the algorithms offline.

Klaus, Todd C.↗