Search NASA⌕ Search

SEARCH · Search NASA

Results for “code generation”

Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.

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

At least 451 records · Page 25
All sourcesNASA NTRSDOE OSTI
NASA NTRS2007

An Attempt to Observe Debris from the Breakup of a Titan 3C-4 Transtage

In February 2007 dedicated observations were made of the orbital space predicted to contain debris from the breakup of the Titan 3C-4 transtage back on February 21, 1992. These observations were carried out on the Michigan Orbital DEbris Survey Telescope (MODEST) in Chile with its 1.3deg field of view. The search region or orbital space (inclination and right ascension of the ascending node (RAAN) was predicted using NASA#s LEGEND (LEO-to-GEO Environment Debris) code to generate a Titan debris cloud. Breakup fragments are created based on the NASA Standard Breakup Model (including fragment size, area-to-mass (A/M), and delta-V distributions). Once fragments are created, they are propagated forward in time with a subroutine GEOPROP. Perturbations included in GEOPROP are those due to solar/lunar gravity, radiation pressure, and major geopotential terms. Barker, et. al, (AMOS Conference Proceedings, 2006, pp. 596-604) used similar LEGEND predictions to correlate survey observations made by MODEST (February 2002) and found several possible night-to-night correlations in the limited survey dataset. One conc lusion of the survey search was to dedicate a MODEST run to observing a GEO region predicted to contain debris fragments and actual Titan debris objects (SSN 25000, 25001 and 30000). Such a dedicated run was undertaken with MODEST between February 17 and 23, 2007 (UT dates). MODEST#s limiting magnitude of 18.0 (S\N approx.10) corresponds to a size of 22cm assuming a diffuse Lambertian albedo of 0.2. However, based on observed break-up data, we expect most debris fragments to be smaller than 22cm which implies a need to increase the effective sensitivity of MODEST for smaller objects. MODEST#s limiting size can be lowered by increasing the exposure time (20 instead of 5 seconds) and applying special image processing. The special processing combines individual CCD images to detect faint objects that are invisible on a single CCD image. Sub-images are cropped from six consecutive CCD images with pixel shifts between images being consistent with the predicted movement of a Titan object. A median image of all the sub-images is then created leaving only those objects with the proper Titan motion. Limiting the median image in this manner brings the needed computer time to process all images taken on one night down to about 50 hours of CPU time.

Barker, E. S.↗
NASA NTRS2004

Development of a State Machine Sequencer for the Keck Interferometer: Evolution, Development and Lessons Learned using a CASE Tool Approach

This paper presents a discussion of the evolution of a sequencer from a simple EPICS (Experimental Physics and Industrial Control System) based sequencer into a complex implementation designed utilizing UML (Unified Modeling Language) methodologies and a CASE (Computer Aided Software Engineering) tool approach. The main purpose of the sequencer (called the IF Sequencer) is to provide overall control of the Keck Interferometer to enable science operations be carried out by a single operator (and/or observer). The interferometer links the two 10m telescopes of the W. M. Keck Observatory at Mauna Kea, Hawaii. The IF Sequencer is a high-level, multi-threaded, Hare1 finite state machine, software program designed to orchestrate several lower-level hardware and software hard real time subsystems that must perform their work in a specific and sequential order. The sequencing need not be done in hard real-time. Each state machine thread commands either a high-speed real-time multiple mode embedded controller via CORB A, or slower controllers via EPICS Channel Access interfaces. The overall operation of the system is simplified by the automation. The UML is discussed and our use of it to implement the sequencer is presented. The decision to use the Rhapsody product as our CASE tool is explained and reflected upon. Most importantly, a section on lessons learned is presented and the difficulty of integrating CASE tool automatically generated C++ code into a large control system consisting of multiple infrastructures is presented.

interferometer↗
NASA NTRS1988

Staging memory for massively parallel processor

The invention herein relates to a computer organization capable of rapidly processing extremely large volumes of data. A staging memory is provided having a main stager portion consisting of a large number of memory banks which are accessed in parallel to receive, store, and transfer data words simultaneous with each other. Substager portions interconnect with the main stager portion to match input and output data formats with the data format of the main stager portion. An address generator is coded for accessing the data banks for receiving or transferring the appropriate words. Input and output permutation networks arrange the lineal order of data into and out of the memory banks.

Batcher, Kenneth E.↗
NASA NTRS2009

System and method for deriving a process-based specification

A system and method for deriving a process-based specification for a system is disclosed. The process-based specification is mathematically inferred from a trace-based specification. The trace-based specification is derived from a non-empty set of traces or natural language scenarios. The process-based specification is mathematically equivalent to the trace-based specification. Code is generated, if applicable, from the process-based specification. A process, or phases of a process, using the features disclosed can be reversed and repeated to allow for an interactive development and modification of legacy systems. The process is applicable to any class of system, including, but not limited to, biological and physical systems, electrical and electro-mechanical systems in addition to software, hardware and hybrid hardware-software systems.

Hinchey, Michael Gerard↗
NASA NTRS2003

The X-38 Spacecraft Fault-Tolerant Avionics System

In 1995 NASA began an experimental program to develop a reusable crew return vehicle (CRV) for the International Space Station. The purpose of the CRV was threefold: (i) to bring home an injured or ill crewmember; (ii) to bring home the entire crew if the Shuttle fleet was grounded; and (iii) to evacuate the crew in the case of an imminent Station threat (i.e., fire, decompression, etc). Built at the Johnson Space Center, were two approach and landing prototypes and one spacecraft demonstrator (called V201). A series of increasingly complex ground subsystem tests were completed, and eight successful high-altitude drop tests were achieved to prove the design concept. In this program, an unprecedented amount of commercial-off-the-shelf technology was utilized in this first crewed spacecraft NASA has built since the Shuttle program. Unfortunately, in 2002 the program was canceled due to changing Agency priorities. The vehicle was 80% complete and the program was shut down in such a manner as to preserve design, development, test and engineering data. This paper describes the X-38 V201 fault-tolerant avionics system. Based on Draper Laboratory's Byzantine-resilient fault-tolerant parallel processing system and their "network element" hardware, each flight computer exchanges information on a strict timescale to process input data, compare results, and issue voted vehicle output commands. Major accomplishments achieved in this development include: (i) a space qualified two-fault tolerant design using mostly COTS (hardware and operating system); (ii) a single event upset tolerant network element board, (iii) on-the-fly recovery of a failed processor; (iv) use of synched cache; (v) realignment of memory to bring back a failed channel; (vi) flight code automatically generated from the master measurement list; and (vii) built in-house by a team of civil servants and support contractors. This paper will present an overview of the avionics system and the hardware implementation, as well as the system software and vehicle command & telemetry functions. Potential improvements and lessons learned on this program are also discussed.

Kouba,Coy↗
NASA NTRS2011

Numerical Relativity for Space-Based Gravitational Wave Astronomy

In the next decade, gravitational wave instruments in space may provide high-precision measurements of gravitational-wave signals from strong sources, such as black holes. Currently variations on the original Laser Interferometer Space Antenna mission concepts are under study in the hope of reducing costs. Even the observations of a reduced instrument may place strong demands on numerical relativity capabilities. Possible advances in the coming years may fuel a new generation of codes ready to confront these challenges.

Baker, John G.↗
NASA NTRS2011

Assessment of the Draft AIAA S-119 Flight Dynamic Model Exchange Standard

An assessment of a draft AIAA standard for flight dynamics model exchange, ANSI/AIAA S-119-2011, was conducted on behalf of NASA by a team from the NASA Engineering and Safety Center. The assessment included adding the capability of importing standard models into real-time simulation facilities at several NASA Centers as well as into analysis simulation tools. All participants were successful at importing two example models into their respective simulation frameworks by using existing software libraries or by writing new import tools. Deficiencies in the libraries and format documentation were identified and fixed; suggestions for improvements to the standard were provided to the AIAA. An innovative tool to generate C code directly from such a model was developed. Performance of the software libraries compared favorably with compiled code. As a result of this assessment, several NASA Centers can now import standard models directly into their simulations. NASA is considering adopting the now-published S-119 standard as an internal recommended practice.

Jackson, E. Bruce↗
NASA NTRS2009

A General Tool for Evaluating High-Contrast Coronagraphic Telescope Performance Error Budgets

This paper describes a general purpose Coronagraph Performance Error Budget (CPEB) tool that we have developed under the NASA Exoplanet Exploration Program. The CPEB automates many of the key steps required to evaluate the scattered starlight contrast in the dark hole of a space-based coronagraph. It operates in 3 steps: first, a CodeV or Zemax prescription is converted into a MACOS optical prescription. Second, a Matlab program calls ray-trace code that generates linear beam-walk and aberration sensitivity matrices for motions of the optical elements and line-of-sight pointing, with and without controlled coarse and fine-steering mirrors. Third, the sensitivity matrices are imported by macros into Excel 2007 where the error budget is created. Once created, the user specifies the quality of each optic from a predefined set of PSDs. The spreadsheet creates a nominal set of thermal and jitter motions and combines them with the sensitivity matrices to generate an error budget for the system. The user can easily modify the motion allocations to perform trade studies.

Terrestrial Planet Finder↗
NASA NTRS2017

A Methane Lidar for Greenhouse Gas Measurements

Atmospheric methane is the second most important greenhouse gas with 25 times the radiativeforcing of carbon dioxide. We will present results from an airborne campaign using a lidar at1.65m using optical parametric generation. OCIS codes: ((280.1910) DIAL, differential absorption lidar; (120.0280) Remote sensing and sensors; (010.1280) Atmospheric composition.

Remote Sensin↗
NASA NTRS2014

Interpreting the Helioseismic and Magnetic Imager (HMI) Multi-Height Velocity Measurements

The Solar Dynamics Observatory Helioseismic and Magnetic Imager (SDOHMI) filtergrams, taken at six wavelengths around the Fe I 6173.3 Å line, contain information about the line-of-sight velocity over a range of heights in the solar atmosphere. Multiheight velocity inferences from these observations can be exploited to study wave motions and energy transport in the atmosphere. Using realistic convection-simulation datasets provided by the STAGGER and MURaM codes, we generate synthetic filtergrams and explore several methods for estimating Dopplergrams.We investigate at which height each synthetic Dopplergram correlates most strongly with the vertical velocity in the model atmospheres. On the basis of the investigation, we propose two Dopplergrams other than the standard HMI-algorithm Dopplergram produced from HMI filtergrams: a line-center Dopplergram and an average-wing Dopplergram. These two Dopplergrams correlate most strongly with vertical velocities at the heights of 30 40 km above (line center) and 30 40 km below (average wing) the effective height of the HMI-algorithm Dopplergram. Therefore, we can obtain velocity information from two layers separated by about a half of a scale height in the atmosphere, at best. The phase shifts between these multi-height Dopplergrams from observational data as well as those from the simulated data are also consistent with the height-difference estimates in the frequency range above the photospheric acoustic-cutoff frequency.

velocity fields↗
NASA NTRS2020

Formal Requirements Elicitation with FRET

FRET is a tool for writing, understanding, formalizing and analyzing requirements. Users write requirements in an intuitive, restricted natural language, called FRETISH, with precise, unambiguous meaning. For a FRETISH requirement, FRET: 1) produces natural language and diagrammatic explanations of its exact meaning, 2) formalizes the requirement in logics, and 3) supports interactive simulation of produced logic formulas to ensure that they capture user intentions. FRET connects to analysis tools by facilitating the mapping between requirements and models/code, and by generating verification code. FRET is available open source at https://github.com/NASA-SW-VnV/fret; a video can be accessed at : https://tinyurl.com/fretForREFSQ.

Giannakopoulou, Dimitra↗
NASA NTRSDate not supplied

The Ten Lockheed Martin Cyber-Physical Challenges: Formalized, Analyzed, and Explained

Capturing and analyzing requirements of Cyber-Physical Systems (CPS) can be challenging, since CPS models typically involve time-varying and real-valued variables, physical system dynamics, or even adaptive behavior. MATLAB/Simulinkis a development and simulation framework that is widely used in industry to capture such systems. In this paper, we report on the application of NASA Ames tools to perform end-to-end analysis of the Ten Lockheed Martin Challenge Problems (LMCPS). LMCPS is a set of industrial Simulink model benchmarks and natural language requirements developed by domain experts. Our framework, which integrates the tools FRET and COCOSIM, is used to: 1) elicit, explain, and formalize the semantics of the given natural language requirements; 2) generate verification code and monitors that can be automatically attached to the Simulink models; 3) perform verification by using SMT-based model checkers. FRET and COCOSIM are open source, and can be used by other researchers and practitioners to replicate our case study. We provide a categorization of recurring patterns in the formalization of the requirements and discuss the strengths and weaknesses of our automated verification approach.

Anastasia Mavridou↗
NASA NTRS1999

A Flexible Statechart-to-model-checker Translator

Many current-day software design tools offer some variant of statechart notation for system specification. We, like others, have built an automatic translator from (a subset of) statecharts to a model checker, for use to validate behavioral requirements.

statecharts↗
NASA NTRSDate not supplied

PRECiSA: a static analysis tool for floating-point programs

This presentation introduces PRECiSA, a static analysis framework for analyzing floating-point programs. PRECiSA computes round-off error bounds for a class of floating-point programs, and produces a formal proof certificate of the correctness of these bounds. PRECiSA also has the capability of generating C code which is instrumented to detect unstable branching conditions from a real-number algorithm specification.

Floating-point↗