Search NASA⌕ Search

SEARCH · Search NASA

Results for “checking”

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 451 records · Page 25
All sourcesNASA NTRSDOE OSTI
NASA NTRS1986

A study of the use of abstract types for the representation of engineering units in integration and test applications

Physical quantities using various units of measurement can be well represented in Ada by the use of abstract types. Computation involving these quantities (electric potential, mass, volume) can also automatically invoke the computation and checking of some of the implicitly associable attributes of measurements. Quantities can be held internally in SI units, transparently to the user, with automatic conversion. Through dimensional analysis, the type of the derived quantity resulting from a computation is known, thereby allowing dynamic checks of the equations used. The impact of the possible implementation of these techniques in integration and test applications is discussed. The overhead of computing and transporting measurement attributes is weighed against the advantages gained by their use. The construction of a run time interpreter using physical quantities in equations can be aided by the dynamic equation checks provided by dimensional analysis. The effects of high levels of abstraction on the generation and maintenance of software used in integration and test applications are also discussed.

Johnson, Charles S.↗
NASA NTRS1988

Utilization of wind tunnel instrumentation with software verifications

Software tools developed for the National Full-Scale Aerodynamic Complex (NFAC) for verifying data integrity and troublehooting problems are discussed. The Hardware Check verifies that the incoming signals are properly connected and are being acquired into the real time data system. The Zero/Cal Check program verifies the reliability of the wind tunnel instrumentation by checking the zero and calibration points. The Power Spectral Density Plots help to identify the frequency components of a signal. Drift Program and Thermal Plots tools are also described.

Silva, Betty W.↗
NASA NTRS1990

Procedural error monitoring and smart checklists

Human beings make and usually detect errors routinely. The same mental processes that allow humans to cope with novel problems can also lead to error. Bill Rouse has argued that errors are not inherently bad but their consequences may be. He proposes the development of error-tolerant systems that detect errors and take steps to prevent the consequences of the error from occurring. Research should be done on self and automatic detection of random and unanticipated errors. For self detection, displays should be developed that make the consequences of errors immediately apparent. For example, electronic map displays graphically show the consequences of horizontal flight plan entry errors. Vertical profile displays should be developed to make apparent vertical flight planning errors. Other concepts such as energy circles could also help the crew detect gross flight planning errors. For automatic detection, systems should be developed that can track pilot activity, infer pilot intent and inform the crew of potential errors before their consequences are realized. Systems that perform a reasonableness check on flight plan modifications by checking route length and magnitude of course changes are simple examples. Another example would be a system that checked the aircraft's planned altitude against a data base of world terrain elevations. Information is given in viewgraph form.

Palmer, Everett↗
NASA NTRS1990

The design and proof of correctness of a fault-tolerant circuit

The flowing achievements are presented in view graph form: (1) a formal statement of interactive consistency conditions in the Boyer-Moore logic; (2) a formal statement of the oral messages (OM) algorithm in the Boyer-Moore logic; (3) a mechanically checked proof that OM satisfies the interactive consistency conditions; (4) a mechanically checked proof of the optimality result--no algorithm can tolerate fewer faults than OM yet still achieve interactive consistency; (5) the use of OM in a functional specification for a fault-tolerant device; (6) a formal description of the design of the device; (7) a mechanically checked proof that the device design satisfies the specification; and (8) an implementation of the design in programmable logic arrays.

Bevier, William R.↗
NASA NTRS1992

Design and scheduling for periodic concurrent error detection and recovery in processor arrays

Periodic application of time-redundant error checking provides the trade-off between error detection latency and performance degradation. The goal is to achieve high error coverage while satisfying performance requirements. We derive the optimal scheduling of checking patterns in order to uniformly distribute the available checking capability and maximize the error coverage. Synchronous buffering designs using data forwarding and dynamic reconfiguration are described. Efficient single-cycle diagnosis is implemented by error pattern analysis and direct-mapped recovery cache. A rollback recovery scheme using start-up control for local recovery is also presented.

Wang, Yi-Min↗
NASA NTRS1992

Technology test bed engine real-time failure control

The Real-Time Failure Control (RTFC) program involves development of a failure detection algorithm, for the Space Shuttle Main Engine (SSME). This failure detection approach is signal-based and entails monitoring SSME measurement signals based on predetermined as well as on-line computed mean and standard deviation values. Twenty-four engine measurements are monitored in the algorithm and provisions are made to add more parameters if needed. Each of the first values of every measurement signal at the algorithm start is checked against safety limits placed around a pre-computed engine-to-engine mean value (MV) with a bandwidth equal to a given multiple of the pre-computed standard deviation (SD). If several parameters are out of the bounds of these limits a failure is signaled. During the first two seconds (after algorithm start) a moving average (MA) and a SD is computed on-line in real-time. The moving average of each parameter is computed by averaging the incoming signal measurement with the four most recent previous signal measurements. The moving average is updated at every sampling interval (40 msec) and is checked against a similar safety band around the initial signal value for each parameter. If several anomalies are registered, a failure is signaled by the algorithm. At the end of the two-second interval the MA is fixed as the mean value for the rest of the algorithm operation and a safety band is placed above and below this value equal to a multiple of the computed SD. However, the safety band is adjusted by adjusting the mean value when propellant tank repressurization and venting take place. 'Influence Coefficients' are used to make the necessary adjustments to the safety limits of those parameters that are affected by repressurization and venting or valve closure and opening. The MA is, in both cases, continuously updated and checked against the safety band. Once more, if several parameters exceed the limits a failure is signaled. At the start of every scheduled power transient the algorithm is stopped. It is re-initiated after two seconds from the termination of the power transient and the process is repeated. The final report is divided into four major sections. The most encompassing of all is the discussion section that has sub-sections on: (1) RTFC algorithm development, (2) RTFC simulations; (3) RTFC current limitations; and (4) enhancements planned for.

Panossian, Hagop V.↗
NASA NTRS1992

SPPTOOLS: Programming tools for the IRAF SPP language

An IRAF package to assist in SPP code development and debugging is described. SPP is the machine-independent programming language used by virtually all IRAF tasks. Tools have been written to aide both novice and advanced SPP programmers with development and debugging by providing tasks to check the code for the number and type of arguments in all calls to IRAF VOS library procedures, list the calling sequences of IRAF tasks, create a database of identifiers for quick access, check for memory which is not freed, and a source code formatter. Debugging is simplified since the programmer is able to get a better understanding of the structure of his/her code, and IRAF library procedure calls (probably the most common source of errors) are automatically checked for correctness.

Fitzpatrick, M.↗
NASA NTRS1993

Orbital Signature Analyzer (OSA): A spacecraft health/safety monitoring and analysis tool

Fixed or static limit sensing is employed in control centers to ensure that spacecraft parameters remain within a nominal range. However, many critical parameters, such as power system telemetry, are time-varying and, as such, their 'nominal' range is necessarily time-varying as well. Predicted data, manual limits checking, and widened limit-checking ranges are often employed in an attempt to monitor these parameters without generating excessive limits violations. Generating predicted data and manual limits checking are both resource intensive, while broadening limit ranges for time-varying parameters is clearly inadequate to detect all but catastrophic problems. OSA provides a low-cost solution by using analytically selected data as a reference upon which to base its limits. These limits are always defined relative to the time-varying reference data, rather than as fixed upper and lower limits. In effect, OSA provides individual limits tailored to each value throughout all the data. A side benefit of using relative limits is that they automatically adjust to new reference data. In addition, OSA provides a wealth of analytical by-products in its execution.

Weaver, Steven↗
NASA NTRS1993

Evaluation of the efficiency and fault density of software generated by code generators

Flight computers and flight software are used for GN&C (guidance, navigation, and control), engine controllers, and avionics during missions. The software development requires the generation of a considerable amount of code. The engineers who generate the code make mistakes and the generation of a large body of code with high reliability requires considerable time. Computer-aided software engineering (CASE) tools are available which generates code automatically with inputs through graphical interfaces. These tools are referred to as code generators. In theory, code generators could write highly reliable code quickly and inexpensively. The various code generators offer different levels of reliability checking. Some check only the finished product while some allow checking of individual modules and combined sets of modules as well. Considering NASA's requirement for reliability, an in house manually generated code is needed. Furthermore, automatically generated code is reputed to be as efficient as the best manually generated code when executed. In house verification is warranted.

Schreur, Barbara↗
NASA NTRS1997

Monitoring Properties of Programs

Development of complex systems requires interaction between a large group of people at various levels of software development, including the communication of properties of the system and the data to be manipulated. A natural idea is to maintain a centralized database of properties of the system to which all members of the development group have access, and to automate the process of checking for violations against this database. The focus of this paper is to discuss such an automated process, called integrity constraint checking. The paper defines the notion of an integrity constraint and discusses considerations for adding an automated checker to a programming language compiler or interpreter. Current work on the implementation of integrity constraint checking in a very high-level language called SequenceL is discussed, and future work in developing a similar checker in an imperative language is outlined.

Fernandez, Francisco G.↗
NASA NTRS1999

STS-96 FD Highlights and Crew Activities Report: Flight Day 03

On this third day of the STS-96 Discovery mission, the flight crew, Commander Kent V. Rominger, Pilot Rick D. Husband, and Mission Specialists Ellen Ochoa, Tamara E. Jernigan, Daniel T. Barry, Julie Payette, and Valery Ivanovich Tokarev are seen executing the very first docking with the International Space Station. Also shown are views of the docking taken from both the Unity and Discovery. Final preparation for the mission's space walk is also presented. Jernigan and Barry check the tools and the emergency rescue backpacks they will need for their space walk. Ochoa and Jernigan perform leak and pressurization checks and open the hatch to the Unity module. Ochoa and Takarev store docking targets and lights and check the hatch seals in the narrow passageway. Rominger and Husband remove and store four electronic boxes around the Unity module.

Source record↗
NASA NTRS1999

Statistical Quality Control of Moisture Data in GEOS DAS

A new statistical quality control algorithm was recently implemented in the Goddard Earth Observing System Data Assimilation System (GEOS DAS). The final step in the algorithm consists of an adaptive buddy check that either accepts or rejects outlier observations based on a local statistical analysis of nearby data. A basic assumption in any such test is that the observed field is spatially coherent, in the sense that nearby data can be expected to confirm each other. However, the buddy check resulted in excessive rejection of moisture data, especially during the Northern Hemisphere summer. The analysis moisture variable in GEOS DAS is water vapor mixing ratio. Observational evidence shows that the distribution of mixing ratio errors is far from normal. Furthermore, spatial correlations among mixing ratio errors are highly anisotropic and difficult to identify. Both factors contribute to the poor performance of the statistical quality control algorithm. To alleviate the problem, we applied the buddy check to relative humidity data instead. This variable explicitly depends on temperature and therefore exhibits a much greater spatial coherence. As a result, reject rates of moisture data are much more reasonable and homogeneous in time and space.

Dee, D. P.↗
NASA NTRS2001

Monitoring Java Programs with Java PathExplorer

We present recent work on the development Java PathExplorer (JPAX), a tool for monitoring the execution of Java programs. JPAX can be used during program testing to gain increased information about program executions, and can potentially furthermore be applied during operation to survey safety critical systems. The tool facilitates automated instrumentation of a program's late code which will then omit events to an observer during its execution. The observer checks the events against user provided high level requirement specifications, for example temporal logic formulae, and against lower level error detection procedures, for example concurrency related such as deadlock and data race algorithms. High level requirement specifications together with their underlying logics are defined in the Maude rewriting logic, and then can either be directly checked using the Maude rewriting engine, or be first translated to efficient data structures and then checked in Java.

Havelund, Klaus↗
NASA NTRS2001

Efficient Translation of LTL Formulae into Buchi Automata

Model checking is a fully automated technique for checking that a system satisfies a set of required properties. With explicit-state model checkers, properties are typically defined in linear-time temporal logic (LTL), and are translated into B chi automata in order to be checked. This report presents how we have combined and improved existing techniques to obtain an efficient LTL to B chi automata translator. In particular, we optimize the core of existing tableau-based approaches to generate significantly smaller automata. Our approach has been implemented and is being released as part of the Java PathFinder software (JPF), an explicit state model checker under development at the NASA Ames Research Center.

Giannakopoulou, Dimitra↗
NASA NTRS2004

Assume-Guarantee Verification of Source Code with Design-Level Assumptions

Model checking is an automated technique that can be used to determine whether a system satisfies certain required properties. To address the 'state explosion' problem associated with this technique, we propose to integrate assume-guarantee verification at different phases of system development. During design, developers build abstract behavioral models of the system components and use them to establish key properties of the system. To increase the scalability of model checking at this level, we have developed techniques that automatically decompose the verification task by generating component assumptions for the properties to hold. The design-level artifacts are subsequently used to guide the implementation of the system, but also to enable more efficient reasoning at the source code-level. In particular we propose to use design-level assumptions to similarly decompose the verification of the actual system implementation. We demonstrate our approach on a significant NASA application, where design-level models were used to identify; and correct a safety property violation, and design-level assumptions allowed us to check successfully that the property was presented by the implementation.

Giannakopoulou, Dimitra↗
NASA NTRS2004

Use of GOES, SSM/I, TRMM Satellite Measurements Estimating Water Budget Variations in Gulf of Mexico - Caribbean Sea Basins

This study presents results from a multi-satellite/multi-sensor retrieval system designed to obtain the atmospheric water budget over the open ocean. A combination of 3ourly-sampled monthly datasets derived from the GOES-8 5-channel Imager, the TRMM TMI radiometer, and the DMSP 7-channel passive microwave radiometers (SSM/I) have been acquired for the combined Gulf of Mexico-Caribbean Sea basin. Whereas the methodology has been tested over this basin, the retrieval system is designed for portability to any open-ocean region. Algorithm modules using the different datasets to retrieve individual geophysical parameters needed in the water budget equation are designed in a manner that takes advantage of the high temporal resolution of the GOES-8 measurements, as well as the physical relationships inherent to the TRMM and SSM/I passive microwave measurements in conjunction with water vapor, cloud liquid water, and rainfall. The methodology consists of retrieving the precipitation, surface evaporation, and vapor-cloud water storage terms in the atmospheric water balance equation from satellite techniques, with the water vapor advection term being obtained as the residue needed for balance. Thus, the intent is to develop a purely satellite-based method for obtaining the full set of terms in the atmospheric water budget equation without requiring in situ sounding information on the wind profile. The algorithm is validated by cross-checking all the algorithm components through multiple- algorithm retrieval intercomparisons. A further check on the validation is obtained by directly comparing water vapor transports into the targeted basin diagnosed from the satellite algorithms to those obtained observationally from a network of land-based upper air stations that nearly uniformly surround the basin, although it is fair to say that these checks are more effective m identifying problems in estimating vapor transports from a leaky operational radiosonde network than in verifying the transport estimates determined from the satellite algorithm system Total columnar atmospheric water budget results are presented for an extended annual cycle consisting of the months of October-97, January-98, April-98, July-98,October-98, and January 1999. These results are used to emphasize the changing relationship in E-P, as well as in the varying roles of storage and advection in balancing E-P both on daily and monthly time scales and on localized and basin space scales. Results from the algorithm-to-algorithm intercomparisons are also presented in the context of sensitivity testing to help understand the intrinsic uncertainties in evaluating the water budget terms by an all-satellite algorithm approach.

Smith, Eric A.↗
NASA NTRS2004

Aircraft Fuel Cell Power Systems

In recent years, fuel cells have been explored for use in aircraft. While the weight and size of fuel cells allows only the smallest of aircraft to use fuel cells for their primary engines, fuel cells have showed promise for use as auxiliary power units (APUs), which power aircraft accessories and serve as an electrical backup in case of an engine failure. Fuel cell MUS are both more efficient and emit fewer pollutants. However, sea-level fuel cells need modifications to be properly used in aircraft applications. At high altitudes, the ambient air has a much lower pressure than at sea level, which makes it much more difficult to get air into the fuel cell to react and produce electricity. Compressors can be used to pressurize the air, but this leads to added weight, volume, and power usage, all of which are undesirable things. Another problem is that fuel cells require hydrogen to create electricity, and ever since the Hindenburg burst into flames, aircraft carrying large quantities of hydrogen have not been in high demand. However, jet fuel is a hydrocarbon, so it is possible to reform it into hydrogen. Since jet fuel is already used to power conventional APUs, it is very convenient to use this to generate the hydrogen for fuel-cell-based APUs. Fuel cells also tend to get large and heavy when used for applications that require a large amount of power. Reducing the size and weight becomes especially beneficial when it comes to fuel cells for aircraft. My goal this summer is to work on several aspects of Aircraft Fuel Cell Power System project. My first goal is to perform checks on a newly built injector rig designed to test different catalysts to determine the best setup for reforming Jet-A fuel into hydrogen. These checks include testing various thermocouples, transmitters, and transducers, as well making sure that the rig was actually built to the design specifications. These checks will help to ensure that the rig will operate properly and give correct results when it is finally ready for testing. Another of my goals is to test new membranes for use in proton-exchange membrane fuel cells, in the hope that these membranes can increase the electricity that is produced by he1 cells. Producing more electricity means that fewer fuel cells are needed, thus reducing the weight and volume of an APU based on fuel cells, making such an APU much more viable.

Needham, Robert↗
NASA NTRS2005

STS-114: Discovery L-2 Countdown Status Briefing

George Diller of NASA Public Affairs hosted this briefing. Pete Nickolenko, NASA Test Director; Scott Higgenbotham, STS-114 Payload-Mission Manager; Cathy Winters, Shuttle Weather Officer were present. Pete reports his team has completed the avionics system check ups, servicing of the cryogenic tanks will take about seven hours that day, and will perform engine system checks and pad close outs come evening. Pete also summarized other standard close out activities: check ups of the Orbiter and ground communications network, rotary service, structure retraction, and external tank load (ETL). Pete reported that the mission will be 12 days with two weather contingency days, and end of mission landing scheduled at Kennedy Space Center (KSC) at approximately 11:00 in the morning, Eastern time on July 25th. Scott briefly reported that all hardware is on board Discovery, closed out, and ready to fly. Cathy reported that hurricane Dennis moved to the North and looking forward to launch. She mentioned of a new hurricane looming and will be named Emily, spotted some crosswinds which will migrate to the west, there is 30% probability weather prohibiting launch. Cathy further gave current weather forecast supported with charts: the Launch Forecast, Tanking Forecast, SRB (Shuttle Solid Rocket Booster) Forecast, CONUS and TAL Launch Sites Forecast, and with 24 hours and 48 hours turn around plan. Launch constraints, weather, crosswinds, cloud cover, ground imagery system, launch countdown, launch crews, mission management simulations, launch team simulations were topics covered with the News Media.

Source record↗