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 397 records · Page 22

Automatic oscillator frequency control system

A frequency control system makes an initial correction of the frequency of its own timing circuit after comparison against a frequency of known accuracy and then sequentially checks and corrects the frequencies of several voltage controlled local oscillator circuits. The timing circuit initiates the machine cycles of a central processing unit which applies a frequency index to an input register in a modulo-sum frequency divider stage and enables a multiplexer to clock an accumulator register in the divider stage with a cyclical signal derived from the oscillator circuit being checked. Upon expiration of the interval, the processing unit compares the remainder held as the contents of the accumulator against a stored zero error constant and applies an appropriate correction word to a correction stage to shift the frequency of the oscillator being checked. A signal from the accumulator register may be used to drive a phase plane ROM and, with periodic shifts in the applied frequency index, to provide frequency shift keying of the resultant output signal. Interposition of a phase adder between the accumulator register and phase plane ROM permits phase shift keying of the output signal by periodic variation in the value of a phase index applied to one input of the phase adder.

Smith, S. F.↗

Second generation experiments in fault tolerant software

The purpose of the Multi-Version Software (MVS) experiment is to obtain empirical measurements of the performance of multi-version systems. Twenty version of a program were prepared under reasonably realistic development conditions from the same specifications. The overall structure of the testing environment for the MVS experiment and its status are described. A preliminary version of the control system is described that was implemented for the MVS experiment to allow the experimenter to have control over the details of the testing. The results of an empirical study of error detection using self checks are also presented. The analysis of the checks revealed that there are great differences in the ability of individual programmers to design effective checks.

Knight, J. C.↗

Development of the helium signature test for orbiter main propulsion system revalidation between flights

This paper presents the development of a test technique for revalidation of the Space Shuttle Orbiter Main Propulsion System during ground turnaround operations between flights of the Space Transportation System (STS). The Main Propulsion System consists of the three Space Shuttle Main Engines (SSME's) and the Main Propulsion System (MPS) connecting the SSME's to the orbiter/ground and orbiter/External Tank (ET) interfaces. The Helium Signature Test (HST) performs an end-to-end leak check of the MPS/SSME subsystems that serves as a final validation of those systems for reuse. The test was initially developed during the ground processing flow prior to the STS-6 launch of orbiter Challenger. The test was developed to fulfill a requirement for an overall subsystem leak check as a result of experience gained during the STS-6 Challenger Flight Readiness Firing (FRF) series, during which leaks were encountered in the SSME's that were not detected by routine fluid joint leak checks. The HST technique is described in detail, including orbiter and test equipment configuration, and compared to other leak detection methods used to revalidate MPS/SSME systems for reuse. The HST data base accumulated since STS-6 is summarized and future test applications are described.

Bilardo, Vincent J., Jr.↗

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

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

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↗

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

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↗

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

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

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↗

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↗

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

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↗

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

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↗

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↗

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↗