Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “CHECK”

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 991 records · Page 55
All sourcesNASA NTRSDOE OSTI
NASA NTRS2000

Verification and Validation of Autonomy Software at NASA

Autonomous software holds the promise of new operation possibilities, easier design and development, and lower operating costs. However, as those system close control loops and arbitrate resources on-board with specialized reasoning, the range of possible situations becomes very large and uncontrollable from the outside, making conventional scenario-based testing very inefficient. Analytic verification and validation (V&V) techniques, and model checking in particular, can provide significant help for designing autonomous systems in a more efficient and reliable manner, by providing a better coverage and allowing early error detection. This article discusses the general issue of V&V of autonomy software, with an emphasis towards model-based autonomy, model-checking techniques, and concrete experiments at NASA.

Pecheur, Charles↗
NASA NTRS1997

An Arbitrary First Order Theory Can Be Represented by a Program: A Theorem

How can we represent knowledge inside a computer? For formalized knowledge, classical logic seems to be the most adequate tool. Classical logic is behind all formalisms of classical mathematics, and behind many formalisms used in Artificial Intelligence. There is only one serious problem with classical logic: due to the famous Godel's theorem, classical logic is algorithmically undecidable; as a result, when the knowledge is represented in the form of logical statements, it is very difficult to check whether, based on this statement, a given query is true or not. To make knowledge representations more algorithmic, a special field of logic programming was invented. An important portion of logic programming is algorithmically decidable. To cover knowledge that cannot be represented in this portion, several extensions of the decidable fragments have been proposed. In the spirit of logic programming, these extensions are usually introduced in such a way that even if a general algorithm is not available, good heuristic methods exist. It is important to check whether the already proposed extensions are sufficient, or further extensions is necessary. In the present paper, we show that one particular extension, namely, logic programming with classical negation, introduced by M. Gelfond and V. Lifschitz, can represent (in some reasonable sense) an arbitrary first order logical theory.

Hosheleva, Olga↗
NASA NTRS2000

Verification and Validation of Autonomy Software at NASA

Autonomous software holds the promise of new operation possibilities, easier design and development and lower operating costs. However, as those system close control loops and arbitrate resources on board with specialized reasoning, the range of possible situations becomes very large and uncontrollable from the outside, making conventional scenario-based testing very inefficient. Analytic verification and validation (V&V) techniques, and model checking in particular, can provide significant help for designing autonomous systems in a more efficient and reliable manner, by providing a better coverage and allowing early error detection. This article discusses the general issue of V&V of autonomy software, with an emphasis towards model-based autonomy, model-checking techniques and concrete experiments at NASA.

Pecheur, Charles↗
NASA NTRS2001

STS-100 Crew Activity Report: Flight Day 2 Highlights

On this second day of the STS-100 mission, the crewmembers of Endeavour (Commander Kent Rominger, Pilot Jeffrey Ashby, and Mission Specialists Chris Hadfield, Scott Parazynski, John Phillips, Umberto Guidoni, and Yuri Valentinovich Lonchakov) are seen during various preparations for the upcoming docking procedure with the International Space Station (ISS). Footage shows Hadfield and Parazynski checking their spacesuits and the tools they will use on the first spacewalk. The Shuttle's robotic arm is used to survey the payload bay of Endeavour and to check on the Canadian Robotic Arm. Expedition 2 crewmembers Susan Helms and Jim Voss are seen in the Destiny Laboratory Module. The Canadian Robotic Arm is shown against a backdrop of Earth after it unfolds from the payload bay.

Source record↗
NASA NTRS2001

A Simple Approach of CCD Camera Calibration for Optical Diagnostics Instrumentation

Solid State array sensors are ubiquitous nowadays for obtaining gross field images in numerous scientific and engineering applications including optical diagnostics and instrumentation. Linear responses of these sensors are often required as in interferometry, light scattering and attenuation measurements, and photometry. In most applications, the linearity is usually taken to be granted without thorough quantitative assessment or correction through calibration. Upper-grade CCD cameras of high price may offer better linearity: however, they also require linearity checking and correction if necessary. Intermediate- or low-grade CCD cameras are more likely to need calibration for linearity . Here, we present two very simple approaches: one for quickly checking camera linearity without any additional setup and one for precisely correcting nonlinear sensor responses. It is believed that after calibration, those sensors of intermediate or low grade can function as effectively as their expensive counterpart.

Cha, Soyoung Stephen↗
NASA NTRS2001

Automata-Based Verification of Temporal Properties on Running Programs

This paper presents an approach to checking a running program against its Linear Temporal Logic (LTL) specifications. LTL is a widely used logic for expressing properties of programs viewed as sets of executions. Our approach consists of translating LTL formulae to finite-state automata, which are used as observers of the program behavior. The translation algorithm we propose modifies standard LTL to Buchi automata conversion techniques to generate automata that check finite program traces. The algorithm has been implemented in a tool, which has been integrated with the generic JPaX framework for runtime analysis of Java programs.

Giannakopoulou, Dimitra↗
NASA NTRS2001

Calibration of of Sun Photometers and Sky Radiance Sensors

The main source of error in retrieving aerosol optical thicknesses using sun photometry comes from the determination of the TOA voltages. The degradation of interference filters is the most important source of the long-term changes in the cross-calibrations. Although major improvements have been made in the design of the filters (interference filters fabricated using ion-assisted deposition), the filters remain the principal factor limiting performance of the sun photometers. Degradation of filters necessitates frequent calibration of sun photometers and frequent measurements of the filter transmission or the relative system response. The degradation of the filters mounted on the CIMEL sun photometers have been monitored since 1993 by the Aerosol Robotic Network (AERONET) project. The decay reported by Holben et al. for the first two years of a CIMEL#s operation is between 1 and 5%. Nevertheless, the filters mounted on CIMEL instruments are regularly replaced after two years of use. The cross-calibration technique consists of taking measurements concurrently with the uncalibrated and the reference sun photometers. While analyzing measurements, the quality of the calibration has to be checked, using the following considerations: (1) any cirrus clouds suspected to be masking the sun, during the calibration period, need to be reported and the corresponding data set removed; and (2) the stability of the day needs to be checked. This chapter will describe calibration techniques, facilities, and protocols used for calibrating sun photometers and sky radiometers.

Pietras, Christophe↗
NASA NTRS2002

Navigation Algorithms for the SeaWiFS Mission

The navigation algorithms for the Sea-viewing Wide Field-of-view Sensor (SeaWiFS) were designed to meet the requirement of 1-pixel accuracy-a standard deviation (sigma) of 2. The objective has been to extract the best possible accuracy from the spacecraft telemetry and avoid the need for costly manual renavigation or geometric rectification. The requirement is addressed by postprocessing of both the Global Positioning System (GPS) receiver and Attitude Control System (ACS) data in the spacecraft telemetry stream. The navigation algorithms described are separated into four areas: orbit processing, attitude sensor processing, attitude determination, and final navigation processing. There has been substantial modification during the mission of the attitude determination and attitude sensor processing algorithms. For the former, the basic approach was completely changed during the first year of the mission, from a single-frame deterministic method to a Kalman smoother. This was done for several reasons: a) to improve the overall accuracy of the attitude determination, particularly near the sub-solar point; b) to reduce discontinuities; c) to support the single-ACS-string spacecraft operation that was started after the first mission year, which causes gaps in attitude sensor coverage; and d) to handle data quality problems (which became evident after launch) in the direct-broadcast data. The changes to the attitude sensor processing algorithms primarily involved the development of a model for the Earth horizon height, also needed for single-string operation; the incorporation of improved sensor calibration data; and improved data quality checking and smoothing to handle the data quality issues. The attitude sensor alignments have also been revised multiple times, generally in conjunction with the other changes. The orbit and final navigation processing algorithms have remained largely unchanged during the mission, aside from refinements to data quality checking. Although further improvements are certainly possible, future evolution of the algorithms is expected to be limited to refinements of the methods presented here, and no substantial changes are anticipated.

Hooker, Stanford B.↗
NASA NTRS2001

Certifying Domain-Specific Policies

Proof-checking code for compliance to safety policies potentially enables a product-oriented approach to certain aspects of software certification. To date, previous research has focused on generic, low-level programming-language properties such as memory type safety. In this paper we consider proof-checking higher-level domain -specific properties for compliance to safety policies. The paper first describes a framework related to abstract interpretation in which compliance to a class of certification policies can be efficiently calculated Membership equational logic is shown to provide a rich logic for carrying out such calculations, including partiality, for certification. The architecture for a domain-specific certifier is described, followed by an implemented case study. The case study considers consistency of abstract variable attributes in code that performs geometric calculations in Aerospace systems.

Lowry, Michael↗
NASA NTRS1984

Computer Component Tester

Carlos Horvath of the Burroughs Corporation, inspired by information published in NASA Tech Briefs, developed the AC/DC tester which checks out ECL (Emitter Coupled Logic) devices and their functionality within the computer. Each ECL device has a specific task in the computer's operation; the tester determines whether the device is performing that function properly. Horvath's invention allows rapid manual checking without extensive programming as it is required by other test methods; thus the ECL tester makes it easier to find out what is malfunctioning, and does the job faster.

Source record↗
NASA NTRS2002

Launch Vehicle Sizing Benefits Utilizing Main Propulsion System Crossfeed and Project Status

To meet the goals for a next generation Reusable Launch Vehicle (RLV), a unique propulsion feed system concept was identified using crossfeed between the booster and orbiter stages that could reduce the Two-Stage-to-Orbit (TSTO) vehicle weight and Design, Development, Test and Evaluation (DDT&E) costs by approximately 25%, while increasing safety and reliability. The Main Propulsion System (MPS) crossfeed water demonstration test program addresses all activities required to reduce the risks for the MPS crossfeed system from a Technology Readiness Level (TRL) of 2 to 4 by the completion of testing and analysis by June 2003. During the initial period, that ended in March 2002, a subscale water flow test article was defined. Procurement of a subscale crossfeed check valve was initiated and the specifications for the various components were developed. The fluid transient and pressurization analytical models were developed separately and successfully integrated. The test matrix for the water flow test was developed to correlate the integrated model. A computational fluid dynamics (CFD) model of the crossfeed check valve was developed to assess flow disturbances and internal flow dynamics. Based on the results, the passive crossfeed system concept was very feasible and offered a safe system to be used in an RLV architecture. A water flow test article was designed to accommodate a wide range of flows simulating a number of different types of propellant systems. During the follow-on period, the crossfeed system model will be further refined, the test article will be completed, the water flow test will be performed, and finally the crossfeed system model will be correlated with the test data. This validated computer model will be used to predict the full-scale vehicle crossfeed system performance.

Chandler, Frank↗
NASA NTRS2002

An Overview of the Runtime Verification Tool Java PathExplorer

We present an overview of the Java PathExplorer runtime verification tool, in short referred to as JPAX. JPAX can monitor the execution of a Java program and check that it conforms with a set of user provided properties formulated in temporal logic. JPAX can in addition analyze the program for concurrency errors such as deadlocks and data races. The concurrency analysis requires no user provided specification. The tool facilitates automated instrumentation of a program's bytecode, which when executed will emit an event stream, the execution trace, to an observer. The observer dispatches the incoming event stream to a set of observer processes, each performing a specialized analysis, such as the temporal logic verification, the deadlock analysis and the data race analysis. Temporal logic specifications can be formulated by the user in the Maude rewriting logic, where Maude is a high-speed rewriting system for equational logic, but here extended with executable temporal logic. The Maude rewriting engine is then activated as an event driven monitoring process. Alternatively, temporal specifications can be translated into efficient automata, which check the event stream. 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.

Havelund, Klaus↗
NASA NTRS2002

Program Instrumentation and Trace Analysis

Several attempts have been made recently to apply techniques such as model checking and theorem proving to the analysis of programs. This shall be seen as a current trend to analyze real software systems instead of just their designs. This includes our own effort to develop a model checker for Java, the Java PathFinder 1, one of the very first of its kind in 1998. However, model checking cannot handle very large programs without some kind of abstraction of the program. This paper describes a complementary scalable technique to handle such large programs. Our interest is turned on the observation part of the equation: How much information can be extracted about a program from observing a single execution trace? It is our intention to develop a technology that can be applied automatically and to large full-size applications, with minimal modification to the code. We present a tool, Java PathExplorer (JPaX), for exploring execution traces of Java programs. The tool prioritizes scalability for completeness, and is directed towards detecting errors in programs, not to prove correctness. One core element in JPaX is an instrumentation package that allows to instrument Java byte code files to log various events when executed. The instrumentation is driven by a user provided script that specifies what information to log. Examples of instructions that such a script can contain are: 'report name and arguments of all called methods defined in class C, together with a timestamp'; 'report all updates to all variables'; and 'report all acquisitions and releases of locks'. In more complex instructions one can specify that certain expressions should be evaluated and even that certain code should be executed under various conditions. The instrumentation package can hence be seen as implementing Aspect Oriented Programming for Java in the sense that one can add functionality to a Java program without explicitly changing the code of the original program, but one rather writes an aspect and compiles it into the original program using the instrumentation. Another core element of JPaX is an observation package that supports the analysis of the generated event stream. Two kinds of analysis are currently supported. In temporal analysis the execution trace is evaluated against formulae written in temporal logic. We have implemented a temporal logic evaluator on finite traces using the Maude rewriting system from SRI International, USA. Temporal logic is defined in Maude by giving its syntax as a signature and its semantics as rewrite equations. The resulting semantics is extremely efficient and can handle event streams of hundreds of millions events in few minutes. Furthermore, the implementation is very succinct. The second form of even stream analysis supported is error pattern analysis where an execution trace is analyzed using various error detection algorithms that can identify error-prone programming practices that may potentially lead to errors in some different executions. Two such algorithms focusing on concurrency errors have been implemented in JPaX, one for deadlocks and the other for data races. It is important to note, that a deadlock or data race potential does not need to occur in order for its potential to be detected with these algorithms. This is what makes them very scalable in practice. The data race algorithm implemented is the Eraser algorithm from Compaq, however adopted to Java. The tool is currently being applied to a code base for controlling a spacecraft by the developers of that software in order to evaluate its applicability.

Havelund, Klaus↗
NASA NTRS2001

Runtime Analysis of Linear Temporal Logic Specifications

This report presents an approach to checking a running program against its Linear Temporal Logic (LTL) specifications. LTL is a widely used logic for expressing properties of programs viewed as sets of executions. Our approach consists of translating LTL formulae to finite-state automata, which are used as observers of the program behavior. The translation algorithm we propose modifies standard LTL to B chi automata conversion techniques to generate automata that check finite program traces. The algorithm has been implemented in a tool, which has been integrated with the generic JPaX framework for runtime analysis of Java programs.

Giannakopoulou, Dimitra↗
NASA NTRS2002

What Went Wrong: Explaining Counterexamples

Model checking, initially successful in the field of hardware design, has recently been applied to software. One of the chief advantages of model checking is the production of counterexamples demonstrating that a system does not satisfy a speci cation. However, it may require a great deal of human effort to extract the essence of an error from even a detailed source-level trace of a failing run. We use an automated method for nding multiple versions of an error (and similar executions that do not produce an error), and analyze these executions to produce a more succinct description of the key elements of the error. The description produced includes identi cation of portions of the source code crucial to distinguishing failing and succeeding runs, di erences in invariants between failing and non-failing runs, and information on the necessary changes in scheduling and environmental actions needed to cause suc- cessful runs to fail. In addition, this analysis allows a classi cation of errors by features such as whether they are purely concurrent (i.e. can be induced by changing only thread scheduling).

Groce, Alex↗
NASA NTRS2002

Pressure-Application Device for Testing Pressure Sensors

A portable pressure-application device has been designed and built for use in testing and calibrating piezoelectric pressure transducers in the field. The device generates pressure pulses of known amplitude. A pressure pulse (in contradistinction to a steady pressure) is needed because in the presence of a steady pressure, the electrical output of a piezoelectric pressure transducer decays rapidly with time. The device includes a stainless- steel compressed-air-storage cylinder of 500 cu cm volume. A manual hand pump with check valves and a pressure gauge are located at one end of the cylinder. A three-way solenoid valve that controls the release of pressurized air is located at the other end of the cylinder. Power for the device is provided by a 3.7-V cordless-telephone battery. The valve is controlled by means of a pushbutton switch, which activates a 5 V to +/-15 V DC-to-DC converter that powers the solenoid. The outlet of the solenoid valve is connected to the pressure transducer to be tested. Before the solenoid is energized, the transducer to be tested is at atmospheric pressure. When the solenoid is actuated by the push button, pressurized air from inside the cylinder is applied to the transducer. Once the pushbutton is released, the cylinder pressure is removed from the transducer and the pressurized air applied to the transducer is vented, bringing the transducer back to atmospheric pressure. Before this device was used for actual calibration, its accuracy was checked with a NIST (National Institute of Standards and Technology) traceable calibrator and commercially calibrated pressure transducers. This work was done by Wanda Solano of Stennis Space Center and Greg Richardson of Lockheed Martin Corp.

Source record↗
NASA NTRS2004

Applying Jlint to Space Exploration Software

Java is a very successful programming language which is also becoming widespread in embedded systems, where software correctness is critical. Jlint is a simple but highly efficient static analyzer that checks a Java program for several common errors, such as null pointer exceptions, and overflow errors. It also includes checks for multi-threading problems, such as deadlocks and data races. The case study described here shows the effectiveness of Jlint in find-false positives in the multi-threading warnings gives an insight into design patterns commonly used in multi-threaded code. The results show that a few analysis techniques are sufficient to avoid almost all false positives. These techniques include investigating all possible callers and a few code idioms. Verifying the correct application of these patterns is still crucial, because their correct usage is not trivial.

Artho, Cyrille↗
NASA NTRS2003

Teaching Cockpit Automation in the Classroom

This study explores the idea of teaching fundamental cockpit automation concepts and skills to aspiring professional pilots in a classroom setting, without the use of sophisticated aircraft or equipment simulators. Pilot participants from a local professional pilot academy completed eighteen hours of classroom instruction that placed a strong emphasis on understanding the underlying principles of cockpit automation systems and their use in a multi-crew cockpit. The instructional materials consisted solely of a single textbook. Pilots received no hands-on instruction or practice during their training. At the conclusion of the classroom instruction, pilots completed a written examination testing their mastery of what had been taught during the classroom meetings. Following the written exam, each pilot was given a check flight in a full-mission Level D simulator of a Boeing 747-400 aircraft. Pilots were given the opportunity to fly one practice leg, and were then tested on all concepts and skills covered in the class during a second leg. The results of the written exam and simulator checks strongly suggest that instruction delivered in a traditional classroom setting can lead to high levels of preparation without the need for expensive airplane or equipment simulators.

Casner, Stephen M.↗