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

A rigorous approach to self-checking programming

Self-checking programming is shown to be an effective concurrent error detection technique. The reliability of a self-checking program however relies on the quality of its assertion statements. A self-checking program written without formal guidelines could provide a poor coverage of the errors. A constructive technique for self-checking programming is presented. A Structured Program Design Language (SPDL) suitable for self-checking software development is defined. A set of formal rules, was also developed, that allows the transfromation of SPDL designs into self-checking designs to be done in a systematic manner.

Hua, Kien A.↗
NASA NTRS2003

Propel: Tools and Methods for Practical Source Code Model Checking

The work reported here is an overview and snapshot of a project to develop practical model checking tools for in-the-loop verification of NASA s mission-critical, multithreaded programs in Java and C++. Our strategy is to develop and evaluate both a design concept that enables the application of model checking technology to C++ and Java, and a model checking toolset for C++ and Java. The design concept and the associated model checking toolset is called Propel. It builds upon the Java PathFinder (JPF) tool, an explicit state model checker for Java applications developed by the Automated Software Engineering group at NASA Ames Research Center. The design concept that we are developing is Design for Verification (D4V). This is an adaption of existing best design practices that has the desired side-effect of enhancing verifiability by improving modularity and decreasing accidental complexity. D4V, we believe, enhances the applicability of a variety of V&V approaches; we are developing the concept in the context of model checking. The model checking toolset, Propel, is based on extending JPF to handle C++. Our principal tasks in developing the toolset are to build a translator from C++ to Java, productize JPF, and evaluate the toolset in the context of D4V. Through all these tasks we are testing Propel capabilities on customer applications.

Mansouri-Samani, Massoud↗
NASA NTRS2003

Execution-Based Model Checking of Interrupt-Based Systems

Execution-based model checking (EMC) is a verification technique based on executing a multi-threaded/multiprocess program repeatedly in a systematic manner in order to explore the different interleavings of the program. This is in contrast to traditional model checking, where a model of a system is analyzed Several execution-based model-checking tools exist at this point, such as for example Verisoft and Java PathFinder. The most common formal specification languages used by EMC tools are un- timed, either just assertions, or linear-time temporal logic (LTL). An alternative verification technique is Runtime Execution Monitoring (REM), which is based on monitor- ing the execution of a program, checking that the execution trace conforms to a requirement specification. The Temporal Rover and DBRover are such tools. They provide a very rich specification language, being an extension of LTL with real-time constraints and time-series. We show how execution-based model checking, combined with runtime execution monitoring, can be used for the verification of a large class of safety critical systems commonly known as interrupt-based systems. The proposed approach is novel in that: (i) it supports model checking of a large class of applications not practically verifiable using conventional EMC tools, (ii) it supports verification of LTL assertions extended with real-time and time-series constraints, and (iii) it supports the verification of custom schedulers.

Drusinsky, Doron↗
NASA NTRS2004

FPGA-Based, Self-Checking, Fault-Tolerant Computers

A proposed computer architecture would exploit the capabilities of commercially available field-programmable gate arrays (FPGAs) to enable computers to detect and recover from bit errors. The main purpose of the proposed architecture is to enable fault-tolerant computing in the presence of single-event upsets (SEUs). [An SEU is a spurious bit flip (also called a soft error) caused by a single impact of ionizing radiation.] The architecture would also enable recovery from some soft errors caused by electrical transients and, to some extent, from intermittent and permanent (hard) errors caused by aging of electronic components. A typical FPGA of the current generation contains one or more complete processor cores, memories, and highspeed serial input/output (I/O) channels, making it possible to shrink a board-level processor node to a single integrated-circuit chip. Custom, highly efficient microcontrollers, general-purpose computers, custom I/O processors, and signal processors can be rapidly and efficiently implemented by use of FPGAs. Unfortunately, FPGAs are susceptible to SEUs. Prior efforts to mitigate the effects of SEUs have yielded solutions that degrade performance of the system and require support from external hardware and software. In comparison with other fault-tolerant- computing architectures (e.g., triple modular redundancy), the proposed architecture could be implemented with less circuitry and lower power demand. Moreover, the fault-tolerant computing functions would require only minimal support from circuitry outside the central processing units (CPUs) of computers, would not require any software support, and would be largely transparent to software and to other computer hardware. There would be two types of modules: a self-checking processor module and a memory system (see figure). The self-checking processor module would be implemented on a single FPGA and would be capable of detecting its own internal errors. It would contain two CPUs executing identical programs in lock step, with comparison of their outputs to detect errors. It would also contain various cache local memory circuits, communication circuits, and configurable special-purpose processors that would use self-checking checkers. (The basic principle of the self-checking checker method is to utilize logic circuitry that generates error signals whenever there is an error in either the checker or the circuit being checked.) The memory system would comprise a main memory and a hardware-controlled check-pointing system (CPS) based on a buffer memory denoted the recovery cache. The main memory would contain random-access memory (RAM) chips and FPGAs that would, in addition to everything else, implement double-error-detecting and single-error-correcting memory functions to enable recovery from single-bit errors.

Some, Raphael↗
NASA NTRS2019

Integrating Realizability Checking in FRET

Realizability (alternatively referred to as relative consistency or implementability) - checking whether a specification can be implemented by an open system - has been the subject of extensive study. Realizability can be viewed as a stronger analysis method when compared to consistency checking in that it does not only check whether the system works in some environment, but instead whether the system works in all environments. In this report, we experiment and build on the approach presented by Gacek et al. that supports checking realizability of contracts involving infinite theories using SMT solvers. In particular, we 1) extend the Formal Requirements Elicitation Tool (FRET) to support generation of Lustre contracts that can be checked for realizability with the JKind k-induction and fix point generation engines; 2) study a compositional way for checking realizability based on the notion of connected components; and 3) test our approach and the capabilities of the JKind realizability engines on a large subset of the Lockheed Martin Cyber Physical System Challenge Problems.

Kooi, David↗
DOE OSTI2018

Validation of Spawn Checks and Saltwater Age Assignments Based on Scales from Known Repeat-Spawning Steelhead

Abstract It is critical to resolve the effects of regeneration, false annuli, and resorption on interpretation of scale patterns. We used scales collected from known repeat-spawning steelhead Oncorhynchus mykiss from the Snake River to (1) determine the accuracy of spawn check identification and (2) investigate errors in assignment of saltwater ages before and after spawn checks. Scale readers (n = 4) accurately identified over 96% of known repeat spawners (n = 107) and did not identify spawn checks in known first-time spawners (n = 197). Scale resorption associated with the spawn check caused an obscured or lost saltwater annulus in 66% of samples, most frequently in fish that spent 2 years versus 1 year in saltwater. Presence or absence of an annulus after the spawn check was accurately assigned in 86% of samples (n = 100). The potential for scale resorption to affect interpretation of the life history of iteroparous anadromous salmonids is significant. We supply two examples of how circulus counts can provide guidance to scale readers, but this analysis should be customized to the growth characteristics of each stock of interest.

Copeland, Timothy↗
DOE OSTI2013

Determination of monitor unit check tolerances based on a comparison with measurement and treatment planning system data

ABSTRACT: This work describes the experimental validation of treatment planning system monitor unit (MU) calculations against measurement for a range of scenarios. This, together with a comparison of treatment planning system MUs and an independent MU check method, allows the derivation of confidence intervals for the check process. Data were collected for open and 60° motorized wedge fields using an Elekta Synergy linac at 6 and 8 MV using homogeneous and heterogeneous phantoms. Masterplan (Version 4.0) pencil-beam and collapsed cone algorithms were used for the primary MU calculations with full inhomogeneity correction. Results show that both algorithms agree with measurement to acceptable tolerance levels in the majority of the cases studied. The confidence interval for the pencil-beam algorithm MU against an independent check was determined as + 1.6% to −3.4%. This is modified to + 2.3% to −2.5% when data collected with low-density heterogeneities are removed as this algorithm is not used clinically for these cases. The corresponding interval for the collapsed cone algorithm was + 1.2% to −4.3%, indicating that an offset tolerance for the independent check is appropriate. Analysis of clinical conformal treatment plan data generated using the pencil-beam algorithm (1393 beams) returned 93% of beams within the independent check tolerance. Similarly, using the collapsed cone algorithm as the primary MU calculation, 77% (of 1434 beams) were within the confidence interval.

61 RADIATION PROTECTION AND DOSIMETRY↗
DOE OSTI2014

SU-D-BRD-07: Automatic Patient Data Audit and Plan Quality Check to Support ARIA and Eclipse

Purpose: To ensure patient safety and treatment quality in RT departments that use Varian ARIA and Eclipse, we developed a computer software system and interface functions that allow previously developed electron chart checking (EcCk) methodologies to support these Varian systems. Methods: ARIA and Eclipse store most patient information in its MSSQL database. We studied the contents in the hundreds database tables and identified the data elements used for patient treatment management and treatment planning. Interface functions were developed in both c-sharp and MATLAB to support data access from ARIA and Eclipse servers using SQL queries. These functions and additional data processing functions allowed the existing rules and logics from EcCk to support ARIA and Eclipse. Dose and structure information are important for plan quality check, however they are not stored in the MSSQL database but as files in Varian private formats, and cannot be processed by external programs. We have therefore implemented a service program, which uses the DB Daemon and File Daemon services on ARIA server to automatically and seamlessly retrieve dose and structure data as DICOM files. This service was designed to 1) consistently monitor the data access requests from EcCk programs, 2) translate the requests for ARIA daemon services to obtain dose and structure DICOM files, and 3) monitor the process and return the obtained DICOM files back to EcCk programs for plan quality check purposes. Results: EcCk, which was previously designed to only support MOSAIQ TMS and Pinnacle TPS, can now support Varian ARIA and Eclipse. The new EcCk software has been tested and worked well in physics new start plan check, IMRT plan integrity and plan quality checks. Conclusion: Methods and computer programs have been implemented to allow EcCk to support Varian ARIA and Eclipse systems. This project was supported by a research grant from Varian Medical System.

60 APPLIED LIFE SCIENCES↗
DOE OSTI2015

SU-E-T-601: Patient Specific QA Check for Radiotherapy with Carbon Beam at SAGA HIMAT

Purpose: To verify a patient specific QA for a prescribed dose per monitor unit (MU) and range check of carbon ion radiotherapy with a beam wobbling method at SAGA HIMAT. Methods: The dose distribution in a water phantom was recalculated with a treatment plan made by XiO-N (Mitsubishi Electric Corporation, Tokyo). The depth dose distributions at central axis were compared with measurements using pinpoint ionization chamber (PTW31014). Measured data were analyzed for dose and distance difference with criteria of 3% and 2mm. To check for the MU and range, analysis data were used at center and distal end of a spread out bragg peak (SOBP) depth, respectively. Results: Treatment plan of 1400 beams in 500 patients were used for analysis. The pass rate of the MU and range was about 98% and 74%, respectively. The rate of both was 73%. The plan data passed only the MU check were verified depth dose profile. The data passed only the range and failed of both were compared depth dose distributions at off axis. If it was failed, we discussed with physicians. Conclusion: Most of patient specific QA check for a prescribed MU and range check at SAGA HIMAT were passed.

61 RADIATION PROTECTION AND DOSIMETRY↗
NASA NTRS1989

A voice-actuated wind tunnel model leak checking system

A computer program has been developed that improves the efficiency of wind tunnel model leak checking. The program uses a voice recognition unit to relay a technician's commands to the computer. The computer, after receiving a command, can respond to the technician via a voice response unit. Information about the model pressure orifice being checked is displayed on a gas-plasma terminal. On command, the program records up to 30 seconds of pressure data. After the recording is complete, the raw data and a straight line fit of the data are plotted on the terminal. This allows the technician to make a decision on the integrity of the orifice being checked. All results of the leak check program are stored in a database file that can be listed on the line printer for record keeping purposes or displayed on the terminal to help the technician find unchecked orifices. This program allows one technician to check a model for leaks instead of the two or three previously required.

Larson, William E.↗
NASA NTRS2001

Addressing Dynamic Issues of Program Model Checking

Model checking real programs has recently become an active research area. Programs however exhibit two characteristics that make model checking difficult: the complexity of their state and the dynamic nature of many programs. Here we address both these issues within the context of the Java PathFinder (JPF) model checker. Firstly, we will show how the state of a Java program can be encoded efficiently and how this encoding can be exploited to improve model checking. Next we show how to use symmetry reductions to alleviate some of the problems introduced by the dynamic nature of Java programs. Lastly, we show how distributed model checking of a dynamic program can be achieved, and furthermore, how dynamic partitions of the state space can improve model checking. We support all our findings with results from applying these techniques within the JPF model checker.

Lerda, Flavio↗
NASA NTRS1998

Pump, and earth-testable spacecraft capillary heat transport loop using augmentation pump and check valves

A spacecraft includes heat-generating payload equipment, and a heat transport system with a cold plate thermally coupled to the equipment and a capillary-wick evaporator, for evaporating coolant liquid to cool the equipment. The coolant vapor is coupled to a condenser and in a loop back to the evaporator. A heated coolant reservoir is coupled to the loop for pressure control. If the wick is not wetted, heat transfer will not begin or continue. A pair of check valves are coupled in the loop, and the heater is cycled for augmentation pumping of coolant to and from the reservoir. This augmentation pumping, in conjunction with the check valves, wets the wick. The wick liquid storage capacity allows the augmentation pump to provide continuous pulsed liquid flow to assure continuous vapor transport and a continuously operating heat transport system. The check valves are of the ball type to assure maximum reliability. However, any type of check valve can be used, including designs which are preloaded in the closed position. The check valve may use any ball or poppet material which resists corrosion. For optimum performance during testing on Earth, the ball or poppet would have neutral buoyancy or be configured in a closed position when the heat transport system is not operating. The ball may be porous to allow passage of coolant vapor.

Baker, David↗
NASA NTRS2008

Program Model Checking: A Practitioner's Guide

Program model checking is a verification technology that uses state-space exploration to evaluate large numbers of potential program executions. Program model checking provides improved coverage over testing by systematically evaluating all possible test inputs and all possible interleavings of threads in a multithreaded system. Model-checking algorithms use several classes of optimizations to reduce the time and memory requirements for analysis, as well as heuristics for meaningful analysis of partial areas of the state space Our goal in this guidebook is to assemble, distill, and demonstrate emerging best practices for applying program model checking. We offer it as a starting point and introduction for those who want to apply model checking to software verification and validation. The guidebook will not discuss any specific tool in great detail, but we provide references for specific tools.

Pressburger, Thomas T.↗
NASA NTRS2009

Model Checking - My 27-Year Quest to Overcome the State Explosion Problem

Model Checking is an automatic verification technique for state-transition systems that are finite=state or that have finite-state abstractions. In the early 1980 s in a series of joint papers with my graduate students E.A. Emerson and A.P. Sistla, we proposed that Model Checking could be used for verifying concurrent systems and gave algorithms for this purpose. At roughly the same time, Joseph Sifakis and his student J.P. Queille at the University of Grenoble independently developed a similar technique. Model Checking has been used successfully to reason about computer hardware and communication protocols and is beginning to be used for verifying computer software. Specifications are written in temporal logic, which is particularly valuable for expressing concurrency properties. An intelligent, exhaustive search is used to determine if the specification is true or not. If the specification is not true, the Model Checker will produce a counterexample execution trace that shows why the specification does not hold. This feature is extremely useful for finding obscure errors in complex systems. The main disadvantage of Model Checking is the state-explosion problem, which can occur if the system under verification has many processes or complex data structures. Although the state-explosion problem is inevitable in worst case, over the past 27 years considerable progress has been made on the problem for certain classes of state-transition systems that occur often in practice. In this talk, I will describe what Model Checking is, how it works, and the main techniques that have been developed for combating the state explosion problem.

Clarke, Ed↗
NASA NTRS2012

Intelligent Data Visualization for Cross-Checking Spacecraft System Diagnosis

Any reasoning system is fallible, so crew members and flight controllers must be able to cross-check automated diagnoses of spacecraft or habitat problems by considering alternate diagnoses and analyzing related evidence. Cross-checking improves diagnostic accuracy because people can apply information processing heuristics, pattern recognition techniques, and reasoning methods that the automated diagnostic system may not possess. Over time, cross-checking also enables crew members to become comfortable with how the diagnostic reasoning system performs, so the system can earn the crew s trust. We developed intelligent data visualization software that helps users cross-check automated diagnoses of system faults more effectively. The user interface displays scrollable arrays of timelines and time-series graphs, which are tightly integrated with an interactive, color-coded system schematic to show important spatial-temporal data patterns. Signal processing and rule-based diagnostic reasoning automatically identify alternate hypotheses and data patterns that support or rebut the original and alternate diagnoses. A color-coded matrix display summarizes the supporting or rebutting evidence for each diagnosis, and a drill-down capability enables crew members to quickly view graphs and timelines of the underlying data. This system demonstrates that modest amounts of diagnostic reasoning, combined with interactive, information-dense data visualizations, can accelerate system diagnosis and cross-checking.

Ong, James C.↗
NASA NTRS2014

Property Differencing for Incremental Checking

This paper introduces iProperty, a novel approach that facilitates incremental checking of programs based on a property di erencing technique. Speci cally, iProperty aims to reduce the cost of checking properties as they are initially developed and as they co-evolve with the program. The key novelty of iProperty is to compute the di erences between the new and old versions of expected properties to reduce the number and size of the properties that need to be checked during the initial development of the properties. Furthermore, property di erencing is used in synergy with program behavior di erencing techniques to optimize common regression scenarios, such as detecting regression errors or checking feature additions for conformance to new expected properties. Experimental results in the context of symbolic execution of Java programs annotated with properties written as assertions show the e ectiveness of iProperty in utilizing change information to enable more ecient checking.

Yang, Guowei↗
DOE OSTI2017

Practical applications of model checking in the finnish nuclear industry - 281

Model checking is a powerful, formal, computer-assisted verification method that can be used to prove that a model of a (hardware or software) system fulfills stated properties. When used right, model checking can prove the correctness of instrumentation and control (I and C) system application logic, be it a software or a field-programmable gate array (FPGA) based design. The verified properties can also address unwanted functionality, making model checking a very effective method for analyzing spurious actuation. Despite the benefits, model checking is still not widely adopted in the verification of I and C systems, one exception being the Finnish nuclear industry. Since 2008, VTT has applied model checking in practical customer work related to the Olkiluoto 3 EPR, Loviisa 1 and 2 VVER-440, and Hanhikivi 1 AES-2006 nuclear power plants, on commission from either the regulator or the utilities. In this paper, we look at how the method has been used in each of these three projects. We also introduce a user-friendly, graphical modelling tool called MODCHK. We then present an overall view of the design issues detected during nine years of customer work, and one practical example. The 100% coverage means that the design errors that are found often relate to scenarios that are otherwise hard to account for (e.g., exact timing of events, or improper operator actions). (authors)

21 SPECIFIC NUCLEAR REACTORS AND ASSOCIATED PLANTS↗
DOE OSTI2015

SU-E-T-372: Evaluation and Comparison of Second-Check Monitor Unit Calculation Software with Pinnacle Treatment Planning System

Purpose: The purpose of this study was to evaluate and compare the accuracy of dose calculation algorithms in the second check software programs Radcalc, Diamond, IMSure, and MUcheck, against the Pinnacle3 treatment planning system (TPS). Methods: Baseline accuracy of the second check software was established by comparison against Pinnacle TPS data using open square fields of 5, 10, 20, 30 and 40cm in a SAD setup. 18 previously treated patients’ files were exported from the Pinnacle3 TPS to each of the four second check softwares, consisting of 146 step and shoot intensity modulated radiotherapy (IMRT) beams and 60 Smart Arcs. Monitor unit (MU) calculated in each of the software were compared with the TPS and the values were represented as a percent difference. Open fields were calculated as a baseline for each software’s accuracy using 5×5, 10×10, 20×20, 30×30, and 40×40 fields. Box plots, Pearson correlation, and Bland-Altman analysis were used for comparison of the results. Results: The baseline accuracy was established to within 0.6%, −1.4%, −0.2%, and −1.0% for Diamond, IMSure,MUcheck, and Radcalc, respectively. In the clinical data, the dose difference represented as mean ± 1 standard deviation were 0.7%±0.1%, −0.3%±0.1%, −1.5%±0.1%, and 0.4%±0.0% for Diamond, IMSure, MUcheck, and Radcalc, respectively Conclusion: The implementation of Clarkson algorithm for the dose calculation between each of the software in question can vary considerably. The currently used second check software, Radcalc has shown the best agreement on average, variance, and smallest percent range from Pinnacle3 TPS values. The closest in average percent difference from the TPS data was the IMSure software, but has significantly larger variance and percent range. The mean percent differences in Diamond and MUcheck were significantly larger than Radcalc and IMSure.

60 APPLIED LIFE SCIENCES↗