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.

SourceResearch connectionFrom yearThrough year

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 1,081 records · Page 60

All sources NASA NTRS DOE OSTI

NASA NTRS2011

Coded Modulation in C and MATLAB

This software, written separately in C and MATLAB as stand-alone packages with equivalent functionality, implements encoders and decoders for a set of nine error-correcting codes and modulators and demodulators for five modulation types. The software can be used as a single program to simulate the performance of such coded modulation. The error-correcting codes implemented are the nine accumulate repeat-4 jagged accumulate (AR4JA) low-density parity-check (LDPC) codes, which have been approved for international standardization by the Consultative Committee for Space Data Systems, and which are scheduled to fly on a series of NASA missions in the Constellation Program. The software implements the encoder and decoder functions, and contains compressed versions of generator and parity-check matrices used in these operations.

Hamkins, Jon↗

NASA NTRS2011

Automated Verification of Specifications with Typestates and Access Permissions

We propose an approach to formally verify Plural specifications based on access permissions and typestates, by model-checking automatically generated abstract state-machines. Our exhaustive approach captures all the possible behaviors of abstract concurrent programs implementing the specification. We describe the formal methodology employed by our technique and provide an example as proof of concept for the state-machine construction rules. The implementation of a fully automated algorithm to generate and verify models, currently underway, provides model checking support for the Plural tool, which currently supports only program verification via data flow analysis (DFA).

Siminiceanu, Radu I.↗

NASA NTRS2011

Validating LES for Jet Aeroacoustics

Engineers charged with making jet aircraft quieter have long dreamed of being able to see exactly how turbulent eddies produce sound and this dream is now coming true with the advent of large eddy simulation (LES). Two obvious challenges remain: validating the LES codes at the resolution required to see the fluid-acoustic coupling, and the interpretation of the massive datasets that are produced. This paper addresses the former, the use of advanced experimental techniques such as particle image velocimetry (PIV) and Raman and Rayleigh scattering, to validate the computer codes and procedures used to create LES solutions. This paper argues that the issue of accuracy of the experimental measurements be addressed by cross-facility and cross-disciplinary examination of modern datasets along with increased reporting of internal quality checks in PIV analysis. Further, it argues that the appropriate validation metrics for aeroacoustic applications are increasingly complicated statistics that have been shown in aeroacoustic theory to be critical to flow-generated sound, such as two-point space-time velocity correlations. A brief review of data sources available is presented along with examples illustrating cross-facility and internal quality checks required of the data before it should be accepted for validation of LES.

Bridges, James↗

NASA NTRS2005

Oscillating-Linear-Drive Vacuum Compressor for CO2

A vacuum compressor has been designed to compress CO2 from approximately equal to 1 psia (approximately equal to 6.9 kPa absolute pressure) to approximately equal to 75 psia (approximately equal to 0.52 MPa), to be insensitive to moisture, to have a long operational life, and to be lightweight, compact, and efficient. The compressor consists mainly of (1) a compression head that includes hydraulic diaphragms, a gas-compression diaphragm, and check valves; and (2) oscillating linear drive that includes a linear motor and a drive spring, through which compression force is applied to the hydraulic diaphragms. The motor is driven at the resonance vibrational frequency of the motor/spring/compression-head system, the compression head acting as a damper that takes energy out of the oscillation. The net effect of the oscillation is to cause cyclic expansion and contraction of the gas-compression diaphragm, and, hence, of the volume bounded by this diaphragm. One-way check valves admit gas into this volume from the low-pressure side during expansion and allow the gas to flow out to the high-pressure side during contraction. Fatigue data and the results of diaphragm stress calculations have been interpreted as signifying that the compressor can be expected to have an operational life of greater than 30 years with a confidence level of 99.9 percent.

Izenson, Michael G.↗

NASA NTRS2011

Common Bolted Joint Analysis Tool

Common Bolted Joint Analysis Tool (comBAT) is an Excel/VB-based bolted joint analysis/optimization program that lays out a systematic foundation for an inexperienced or seasoned analyst to determine fastener size, material, and assembly torque for a given design. Analysts are able to perform numerous what-if scenarios within minutes to arrive at an optimal solution. The program evaluates input design parameters, performs joint assembly checks, and steps through numerous calculations to arrive at several key margins of safety for each member in a joint. It also checks for joint gapping, provides fatigue calculations, and generates joint diagrams for a visual reference. Optimum fastener size and material, as well as correct torque, can then be provided. Analysis methodology, equations, and guidelines are provided throughout the solution sequence so that this program does not become a "black box:" for the analyst. There are built-in databases that reduce the legwork required by the analyst. Each step is clearly identified and results are provided in number format, as well as color-coded spelled-out words to draw user attention. The three key features of the software are robust technical content, innovative and user friendly I/O, and a large database. The program addresses every aspect of bolted joint analysis and proves to be an instructional tool at the same time. It saves analysis time, has intelligent messaging features, and catches operator errors in real time.

Imtiaz, Kauser↗

NASA NTRS2012

Advisory Systems Save Time, Fuel for Airlines

Heinz Erzberger never thought the sky was falling, but he knew it could benefit from enhanced traffic control. Throughout the 1990s, Erzberger led a team at Ames Research Center to develop a suite of automated tools to reduce restrictions and improve the efficiency of air traffic control operations. Called CTAS, or Center-TRACON (Terminal Radar Approach Control) Automation System, the software won NASA s Software of the Year award in 1998, and one of the tools in the suite - the traffic management advisor - was adopted by the Federal Aviation Administration and implemented at traffic control centers across the United States. Another one of the tools, Direct-To, has followed a different path. The idea behind Direct-To, explains Erzberger, a senior scientist at Ames, was that airlines could save fuel and money by shortening the routes they flew between take-off and landing. Aircraft are often limited to following established airways comprised of inefficient route segments. The routes are not easily adjusted because neither the pilot nor the aircraft controller can anticipate the constantly changing air traffic situation. To make the routes more direct while in flight, Erzberger came up with an idea for a software algorithm that could automatically examine air traffic in real-time, check to see if a shortcut was available, and then check for conflicts. If there were no conflicts and the shortcut saved more than 1 minute of flight time, the controller could be notified. "I was trying to figure out what goes on in the pilot and controller s minds when they decide to guide the aircraft in a certain way. That resulted in a different kind analysis," Erzberger says. As the engineer s idea went from theory to practice, in 2001, NASA demonstrated Direct-To in the airspace of Dallas-Ft. Worth. Estimations based on the demonstration found the technology was capable of saving 900 flying minutes per day for the aircraft in the test area.

Source record↗

NASA NTRS2012

HyDE Framework for Stochastic and Hybrid Model-Based Diagnosis

Hybrid Diagnosis Engine (HyDE) is a general framework for stochastic and hybrid model-based diagnosis that offers flexibility to the diagnosis application designer. The HyDE architecture supports the use of multiple modeling paradigms at the component and system level. Several alternative algorithms are available for the various steps in diagnostic reasoning. This approach is extensible, with support for the addition of new modeling paradigms as well as diagnostic reasoning algorithms for existing or new modeling paradigms. HyDE is a general framework for stochastic hybrid model-based diagnosis of discrete faults; that is, spontaneous changes in operating modes of components. HyDE combines ideas from consistency-based and stochastic approaches to model- based diagnosis using discrete and continuous models to create a flexible and extensible architecture for stochastic and hybrid diagnosis. HyDE supports the use of multiple paradigms and is extensible to support new paradigms. HyDE generates candidate diagnoses and checks them for consistency with the observations. It uses hybrid models built by the users and sensor data from the system to deduce the state of the system over time, including changes in state indicative of faults. At each time step when observations are available, HyDE checks each existing candidate for continued consistency with the new observations. If the candidate is consistent, it continues to remain in the candidate set. If it is not consistent, then the information about the inconsistency is used to generate successor candidates while discarding the candidate that was inconsistent. The models used by HyDE are similar to simulation models. They describe the expected behavior of the system under nominal and fault conditions. The model can be constructed in modular and hierarchical fashion by building component/subsystem models (which may themselves contain component/ subsystem models) and linking them through shared variables/parameters. The component model is expressed as operating modes of the component and conditions for transitions between these various modes. Faults are modeled as transitions whose conditions for transitions are unknown (and have to be inferred through the reasoning process). Finally, the behavior of the components is expressed as a set of variables/ parameters and relations governing the interaction between the variables. The hybrid nature of the systems being modeled is captured by a combination of the above transitional model and behavioral model. Stochasticity is captured as probabilities associated with transitions (indicating the likelihood of that transition being taken), as well as noise on the sensed variables.

Narasimhan, Sriram↗

NASA NTRS2012

Experience Report: A Do-It-Yourself High-Assurance Compiler

Embedded domain-specific languages (EDSLs) are an approach for quickly building new languages while maintaining the advantages of a rich metalanguage. We argue in this experience report that the "EDSL approach" can surprisingly ease the task of building a high-assurance compiler.We do not strive to build a fully formally-verified tool-chain, but take a "do-it-yourself" approach to increase our confidence in compiler-correctness without too much effort. Copilot is an EDSL developed by Galois, Inc. and the National Institute of Aerospace under contract to NASA for the purpose of runtime monitoring of flight-critical avionics. We report our experience in using type-checking, QuickCheck, and model-checking "off-the-shelf" to quickly increase confidence in our EDSL tool-chain.

Pike, Lee↗

NASA NTRS2012

Memoized Symbolic Execution

This paper introduces memoized symbolic execution (Memoise), a novel approach for more efficient application of forward symbolic execution, which is a well-studied technique for systematic exploration of program behaviors based on bounded execution paths. Our key insight is that application of symbolic execution often requires several successive runs of the technique on largely similar underlying problems, e.g., running it once to check a program to find a bug, fixing the bug, and running it again to check the modified program. Memoise introduces a trie-based data structure that stores the key elements of a run of symbolic execution. Maintenance of the trie during successive runs allows re-use of previously computed results of symbolic execution without the need for re-computing them as is traditionally done. Experiments using our prototype embodiment of Memoise show the benefits it holds in various standard scenarios of using symbolic execution, e.g., with iterative deepening of exploration depth, to perform regression analysis, or to enhance coverage.

Yang, Guowei↗

NASA NTRS2013

Detectors Ensure Function, Safety of Aircraft Wiring

Pedro Medelius waited patiently in his lab at Kennedy Space Center. He had just received word that a colleague was bringing over a cable from a Space Shuttle solid rocket booster to test Medelius new invention. Medelius was calm until his colleague arrived, with about 30 other people. "Talk about testing under pressure," says Medelius. "There were people there from the Navy, the Air Force, and the Federal Aviation Administration." After the group s arrival, Medelius took a deep breath and connected his Standing Wave Reflectometer (SWR) to the cable. He wiggled the cable around, and the display showed a fault (a short or open circuit in wire) about an inch and a half inside the connector on the cable. His colleague questioned the results, because he had already checked that area on the cable. Medelius used the SWR to check again but got the same result. "That is when we took the cable apart and looked inside," Medelius says. "Lo and behold, that was exactly where the fault was." The impetus for Medelius new wire inspection technology came about in 1999 when one of the space shuttles lost power due to a fault somewhere in its more than 200 miles of electrical wiring. "The backup circuit was activated and prevented a major dysfunction, but nevertheless, there was a problem with the wiring," Medelius describes. Even though technicians used a device called a multimeter to measure the electrical current to find which wire had a fault, it could not pinpoint exactly where on the wire the fault was located. For that, technicians had to visually inspect the wire. "Sometimes they would have to remove the whole wire assembly and visually inspect every single wire. It was a very tedious operation because the wires are behind cabinets. They go all over the place in the shuttle," says Medelius. "NASA needed an instrument capable of telling them exactly where the faults were occurring." To meet NASA s needs for a highly precise device to inspect electrical power bundles, wires, and connectors, Medelius devised the SWR. "It came down to what was affected when a wire is short circuited or opened," he says. "We worked out a few equations based on physical principles." The SWR proved very sensitive, and the technology was patented.

Source record↗

NASA NTRS2012

Automated Sequence Processor: Something Old, Something New

High productivity required for operations teams to meet schedules Risk must be minimized. Scripting used to automate processes. Scripts perform essential operations functions. Automated Sequence Processor (ASP) was a grass-roots task built to automate the command uplink process System engineering task for ASP revitalization organized. ASP is a set of approximately 200 scripts written in Perl, C Shell, AWK and other scripting languages.. ASP processes/checks/packages non-interactive commands automatically.. Non-interactive commands are guaranteed to be safe and have been checked by hardware or software simulators.. ASP checks that commands are non-interactive.. ASP processes the commands through a command. simulator and then packages them if there are no errors.. ASP must be active 24 hours/day, 7 days/week..

Automated↗

NASA NTRS2013

Support Routines for In Situ Image Processing

This software consists of a set of application programs that support ground-based image processing for in situ missions. These programs represent a collection of utility routines that perform miscellaneous functions in the context of the ground data system. Each one fulfills some specific need as determined via operational experience. The most unique aspect to these programs is that they are integrated into the large, in situ image processing system via the PIG (Planetary Image Geometry) library. They work directly with space in situ data, understanding the appropriate image meta-data fields and updating them properly. The programs themselves are completely multimission; all mission dependencies are handled by PIG. This suite of programs consists of: (1)marscahv: Generates a linearized, epi-polar aligned image given a stereo pair of images. These images are optimized for 1-D stereo correlations, (2) marscheckcm: Compares the camera model in an image label with one derived via kinematics modeling on the ground, (3) marschkovl: Checks the overlaps between a list of images in order to determine which might be stereo pairs. This is useful for non-traditional stereo images like long-baseline or those from an articulating arm camera, (4) marscoordtrans: Translates mosaic coordinates from one form into another, (5) marsdispcompare: Checks a Left Right stereo disparity image against a Right Left disparity image to ensure they are consistent with each other, (6) marsdispwarp: Takes one image of a stereo pair and warps it through a disparity map to create a synthetic opposite- eye image. For example, a right eye image could be transformed to look like it was taken from the left eye via this program, (7) marsfidfinder: Finds fiducial markers in an image by projecting their approximate location and then using correlation to locate the markers to subpixel accuracy. These fiducial markets are small targets attached to the spacecraft surface. This helps verify, or improve, the pointing of in situ cameras, (8) marsinvrange: Inverse of marsrange . given a range file, re-computes an XYZ file that closely matches the original. . marsproj: Projects an XYZ coordinate through the camera model, and reports the line/sample coordinates of the point in the image, (9) marsprojfid: Given the output of marsfidfinder, projects the XYZ locations and compares them to the found locations, creating a report showing the fiducial errors in each image. marsrad: Radiometrically corrects an image, (10) marsrelabel: Updates coordinate system or camera model labels in an image, (11) marstiexyz: Given a stereo pair, allows the user to interactively pick a point in each image and reports the XYZ value corresponding to that pair of locations. marsunmosaic: Extracts a single frame from a mosaic, which will be created such that it could have been an input to the original mosaic. Useful for creating simulated input frames using different camera models than the original mosaic used, and (12) merinverter: Uses an inverse lookup table to convert 8-bit telemetered data to its 12-bit original form. Can be used in other missions despite the name.

Deen, Robert G.↗

NASA NTRS2013

Science Opportunity Analyzer (SOA) Version 8

SOA allows scientists to plan spacecraft observations. It facilitates the identification of geometrically interesting times in a spacecraft s orbit that a user can use to plan observations or instrument-driven spacecraft maneuvers. These observations can then be visualized multiple ways in both two- and three-dimensional views. When observations have been optimized within a spacecraft's flight rules, the resulting plans can be output for use by other JPL uplink tools. Now in its eighth major version, SOA improves on these capabilities in a modern and integrated fashion. SOA consists of five major functions: Opportunity Search, Visualization, Observation Design, Constraint Checking, and Data Output. Opportunity Search is a GUI-driven interface to existing search engines that can be used to identify times when a spacecraft is in a specific geometrical relationship with other bodies in the solar system. This function can be used for advanced mission planning as well as for making last-minute adjustments to mission sequences in response to trajectory modifications. Visualization is a key aspect of SOA. The user can view observation opportunities in either a 3D representation or as a 2D map projection. Observation Design allows the user to orient the spacecraft and visualize the projection of the instrument field of view for that orientation using the same views as Opportunity Search. Constraint Checking is provided to validate various geometrical and physical aspects of an observation design. The user has the ability to easily create custom rules or to use official project-generated flight rules. This capability may also allow scientists to easily assess the cost to science if flight rule changes occur. Data Output allows the user to compute ancillary data related to an observation or to a given position of the spacecraft along its trajectory. The data can be saved as a tab-delimited text file or viewed as a graph. SOA combines science planning functionality unique to both JPL and the sponsoring spacecraft. SOA is able to ingest JPL SPICE Kernels that are used to drive the tool and its computations. A Percy search engine is then included that identifies interesting time periods for the user to build observations. When observations are then built, flight-like orientation algorithms replicate spacecraft dynamics to closely simulate the flight spacecraft s dynamics. SOA v8 represents large steps forward from SOA v7 in terms of quality, reliability, maintainability, efficiency, and user experience. A tailored agile development environment has been built around SOA that provides automated unit testing, continuous build and integration, a consolidated Web-based code and documentation storage environment, modern Java enhancements, and a focus on usability

Witoff, Robert J.↗

NASA NTRS2013

Differential Muon Tomography to Continuously Monitor Changes in the Composition of Subsurface Fluids

Muon tomography has been used to seek hidden chambers in Egyptian pyramids and image subsurface features in volcanoes. It seemed likely that it could be used to image injected, supercritical carbon dioxide as it is emplaced in porous geological structures being used for carbon sequestration, and also to check on subsequent leakage. It should work equally well in any other application where there are two fluids of different densities, such as water and oil, or carbon dioxide and heavy oil in oil reservoirs. Continuous monitoring of movement of oil and/or flood fluid during enhanced oil recovery activities for managing injection is important for economic reasons. Checking on leakage for geological carbon storage is essential both for safety and for economic purposes. Current technology (for example, repeat 3D seismic surveys) is expensive and episodic. Muons are generated by high- energy cosmic rays resulting from supernova explosions, and interact with gas molecules in the atmosphere. This innovation has produced a theoretical model of muon attenuation in the thickness of rock above and within a typical sandstone reservoir at a depth of between 1.00 and 1.25 km. Because this first simulation was focused on carbon sequestration, the innovators chose depths sufficient for the pressure there to ensure that the carbon dioxide would be supercritical. This innovation demonstrates for the first time the feasibility of using the natural cosmic-ray muon flux to generate continuous tomographic images of carbon dioxide in a storage site. The muon flux is attenuated to an extent dependent on, amongst other things, the density of the materials through which it passes. The density of supercritical carbon dioxide is only three quarters that of the brine in the reservoir that it displaces. The first realistic simulations indicate that changes as small as 0.4% in the storage site bulk density could be detected (equivalent to 7% of the porosity, in this specific case). The initial muon flux is effectively constant at the surface of the Earth. Sensitivity of the method would be decreased with increasing depth. However, sensitivity can be improved by emplacing a greater array of particle detectors at the base of the reservoir.

Coleman, Max↗

NASA NTRS2009

Proceedings of the Third International Workshop on Proof-Carrying Code and Software Certification

This NASA conference publication contains the proceedings of the Third International Workshop on Proof-Carrying Code and Software Certification, held as part of LICS in Los Angeles, CA, USA, on August 15, 2009. Software certification demonstrates the reliability, safety, or security of software systems in such a way that it can be checked by an independent authority with minimal trust in the techniques and tools used in the certification process itself. It can build on existing validation and verification (V&V) techniques but introduces the notion of explicit software certificates, Vvilich contain all the information necessary for an independent assessment of the demonstrated properties. One such example is proof-carrying code (PCC) which is an important and distinctive approach to enhancing trust in programs. It provides a practical framework for independent assurance of program behavior; especially where source code is not available, or the code author and user are unknown to each other. The workshop wiII address theoretical foundations of logic-based software certification as well as practical examples and work on alternative application domains. Here "certificate" is construed broadly, to include not just mathematical derivations and proofs but also safety and assurance cases, or any fonnal evidence that supports the semantic analysis of programs: that is, evidence about an intrinsic property of code and its behaviour that can be independently checked by any user, intermediary, or third party. These guarantees mean that software certificates raise trust in the code itself, distinct from and complementary to any existing trust in the creator of the code, the process used to produce it, or its distributor. In addition to the contributed talks, the workshop featured two invited talks, by Kelly Hayhurst and Andrew Appel. The PCC 2009 website can be found at http://ti.arc.nasa.gov /event/pcc 091.

Ewen, Denney, W.↗

NASA NTRS2013

Rewriting Modulo SMT

Combining symbolic techniques such as: (i) SMT solving, (ii) rewriting modulo theories, and (iii) model checking can enable the analysis of infinite-state systems outside the scope of each such technique. This paper proposes rewriting modulo SMT as a new technique combining the powers of (i)-(iii) and ideally suited to model and analyze infinite-state open systems; that is, systems that interact with a non-deterministic environment. Such systems exhibit both internal non-determinism due to the system, and external non-determinism due to the environment. They are not amenable to finite-state model checking analysis because they typically are infinite-state. By being reducible to standard rewriting using reflective techniques, rewriting modulo SMT can both naturally model and analyze open systems without requiring any changes to rewriting-based reachability analysis techniques for closed systems. This is illustrated by the analysis of a real-time system beyond the scope of timed automata methods.

Rocha, Camilo↗

NASA NTRS2013

Verification of the H2O Linelists with Theoretically Developed Tools

Two basic rules (i.e., the pair identity and the smooth variation rules) resulting from the properties of the energy levels and wave functions of H2O states govern how the spectroscopic parameters vary with the H2O lines within the individually defined groups of lines. With these rules, for those lines involving high j states in the same groups, variations of all their spectroscopic parameters (i.e., the transition frequency, intensity, pressure broadened half-width, pressure-induced shift, and temperature exponent) can be well monitored. Thus, the rules can serve as simple and effective tools to screen the H2O spectroscopic data listed in the HITRAN database and verify the latter's accuracies. By checking violations of the rules occurring among the data within the individual groups, possible errors can be picked up and also possible missing lines in the linelist whose intensities are above the threshold can be identified. We have used these rules to check the accuracies of the spectroscopic parameters and the completeness of the linelists for several important H2O vibrational bands. Based on our results, the accuracy of the line frequencies in HITRAN 2008 is consistent. For the line intensity, we have found that there are a substantial number of lines whose intensity values are questionable. With respect to other parameters, many mistakes have been found. The above claims are consistent with a well known fact that values of these parameters in HITRAN contain larger uncertainties. Furthermore, supplements of the missing line list consisting of line assignments and positions can be developed from the screening results.

spectroscopy↗

NASA NTRS2014

The Fleet Application for Scheduling and Tracking (FAST) Management Website

The FAST application was designed to replace the paper and pen method of checking out and checking in GSA Vehicles at KSC. By innovating from a paper and pen based checkout system to a fully digital one, not only the resources wasted by printing the checkout forms have been reduced, but it also reduces significantly the time that users and fleet managers need to interact with the system as well as improving the record accuracy for each vehicle. The vehicle information is pulled from a centralized database server in the SPSDL. In an attempt to add a new feature to the FAST application, the author of this report (alongside the FAST developers) has been designing and developing the FAST Management Website. The GSA fleet managers had to rely on the FAST developers in order to add new vehicles, edit vehicles and previous transactions, or for generating vehicles reports. By providing an easy-to-use FAST Management Website portal, the GSA fleet managers are now able to easily move vehicles, edit records, and print reports.

Object-Oriented Programming↗