SEARCH · Engineering Papers
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.
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.
Many models require specialized access and interpolation schemes to effectively extract and interpolate their outputs. In particular, the Block-Adaptive Tree Solarwind Roe Upwind Scheme (BATSRUS) component of the Space Weather Modeling Framework (SWMF) requires Kamodo to take advantage of its block-based adaptive grid structure, and the Lyon-Fedder Mobarry magnetosphere model (or its successor GAMERA) needs a scheme that appreciates the distorted spherical arrangement of grid vertices on a non-orthogonal grid. With the flythrough layer developed by Ringuette et al. (SH42E-2337), the underlying model readers have been adapted to use multiple time steps in a single Python session to perform 4- dimensional interpolations in time and space. Kamodo now utilizes lazy interpolation that loads data only when needed. We present the successful integration of SWMF/BATSRUS magnetosphere access and interpolation into the new 4D Kamodo framework utilizing an external library of C code. Through function composition, Kamodo facilitates the calculation of derived quantities and the transformation of positions and vectors into different coordinate systems. This work is a significant step towards performing field line tracing in Kamodo with SWMF magnetosphere outputs.
This presentation is a tutorial on RV using Copilot, a runtime verification framework for real-time embedded systems. Copilot monitors are written in a compositional, stream-based language with support for a variety of Temporal Logics (TL), which results in robust, high-level specifications that are easier to understand than their traditional counterparts. The framework translates monitor specifications into C code with static memory requirements, which can be compiled to run on embedded hardware.
As motor control algorithms become increasingly complex, traditional microcontroller-based implementations are reaching computational limits that prevent the controller from operating at the required speed. This paper presents a novel workflow leveraging High-Level Synthesis (HLS) to migrate motor control algorithms from a microcontroller implementation to a Field-Programmable Gate Array (FPGA) implementation. The proposed approach utilizes the free Vitis HLS software to automatically convert Embedded Coder-generated C code from a Simulink model into Hardware Description Language (HDL) code suitable for FPGA deployment.
As motor control algorithms become increasingly complex, traditional microcontroller-based implementations are reaching computational limits that prevent the controller from operating at the required speed. This paper presents a novel workflow leveraging High-Level Synthesis (HLS) to migrate motor control algorithms from a microcontroller implementation to a Field-Programmable Gate Array (FPGA) implementation. The proposed approach utilizes the free Vitis HLS software to automatically convert Embedded Coder-generated C code from a Simulink model into Hardware Description Language (HDL) code suitable for FPGA deployment.
As an intern project for NASA Johnson Space Center (JSC), my job was to familiarize myself and operate a Robotics Operating System (ROS). The project outcome converted existing software assets into ROS using nodes, enabling a robotic Hexapod to communicate to be functional and controlled by an existing PlayStation 3 (PS3) controller. Existing control algorithms and current libraries have no ROS capabilities within the Hexapod C++ source code when the internship started, but that has changed throughout my internship. Conversion of C++ codes to ROS enabled existing code to be compatible with ROS, and is now controlled using an existing PS3 controller. Furthermore, my job description was to design ROS messages and script programs that enabled assets to participate in the ROS ecosystem by subscribing and publishing messages. Software programming source code is written in directories using C++. Testing of software assets included compiling code within the Linux environment using a terminal. The terminal ran the code from a directory. Several problems occurred while compiling code and the code would not compile. So modifying code to where C++ can read the source code were made. Once the code was compiled and ran, the code was uploaded to Hexapod and then controlled by a PS3 controller. The project outcome has the Hexapod fully functional and compatible with ROS and operates using the PlayStation 3 controller. In addition, an open source software (IDE) Arduino board will be integrated into the ecosystem with designing circuitry on a breadboard to add additional behavior with push buttons, potentiometers and other simple elements in the electrical circuitry. Other projects with the Arduino will be a GPS module, digital clock that will run off 22 satellites to show accurate real time using a GPS signal and an internal patch antenna to communicate with satellites. In addition, this internship experience has led me to pursue myself to learn coding more efficiently and effectively to write, subscribe and publish my own source code in different programming languages. With some familiarity with software programming, it will enhance my skills in the electrical engineering field. In contrast, my experience here at JSC with the Simulation and Graphics Branch (ER7) has led me to take my coding skill to be more proficient to increase my knowledge in software programming, and also enhancing my skills in ROS. This knowledge will be taken back to my university to implement coding in a school project that will use source coding and ROS to work on the PR2 robot which is controlled by ROS software. My skills learned here will be used to integrate messages to subscribe and publish ROS messages to a PR2 robot. The PR2 robot will be controlled by an existing PS3 controller by changing C++ coding to subscribe and publish messages to ROS. Overall the skills that were obtained here will not be lost, but increased.
When data is transmitted through a noisy channel, errors are produced within the data rendering it indecipherable. Through the use of error control coding techniques, the bit error rate can be reduced to any desired level without sacrificing the transmission data rate. The Astrionics Laboratory at Marshall Space Flight Center has decided to use a modular, end-to-end telemetry data simulator to simulate the transmission of data from flight to ground and various methods of error control. The simulator includes modules for random data generation, data compression, Consultative Committee for Space Data Systems (CCSDS) transfer frame formation, error correction/detection, error generation and error statistics. The simulator utilizes a concatenated coding scheme which includes CCSDS standard (255,223) Reed-Solomon (RS) code over GF(2(exp 8)) with interleave depth of 5 as the outermost code, (7, 1/2) convolutional code as an inner code and CCSDS recommended (n, n-16) cyclic redundancy check (CRC) code as the innermost code, where n is the number of information bits plus 16 parity bits. The received signal-to-noise for a desired bit error rate is greatly reduced through the use of forward error correction techniques. Even greater coding gain is provided through the use of a concatenated coding scheme. Interleaving/deinterleaving is necessary to randomize burst errors which may appear at the input of the RS decoder. The burst correction capability length is increased in proportion to the interleave depth. The modular nature of the simulator allows for inclusion or exclusion of modules as needed. This paper describes the development and operation of the simulator, the verification of a C-language Reed-Solomon code, and the possibility of using Comdisco SPW(tm) as a tool for determining optimal error control schemes.
Model based program design is the most clear and direct way to develop algorithms and programs for interfacing with hardware. While coding "by hand" results in a more tailored product, the ever-growing size and complexity of modern-day applications can cause the project work load to quickly become unreasonable for one programmer. This has generally been addressed by splitting the product into separate modules to allow multiple developers to work in parallel on the same project, however this introduces new potentials for errors in the process. The fluidity, reliability and robustness of the code relies on the abilities of the programmers to communicate their methods to one another; furthermore, multiple programmers invites multiple potentially differing coding styles into the same product, which can cause a loss of readability or even module incompatibility. Fortunately, Mathworks has implemented an auto-coding feature that allows programmers to design their algorithms through the use of models and diagrams in the graphical programming environment Simulink, allowing the designer to visually determine what the hardware is to do. From here, the auto-coding feature handles converting the project into another programming language. This type of approach allows the designer to clearly see how the software will be directing the hardware without the need to try and interpret large amounts of code. In addition, it speeds up the programming process, minimizing the amount of man-hours spent on a single project, thus reducing the chance of human error as well as project turnover time. One such project that has benefited from the auto-coding procedure is Ramses, a portion of the GNC flight software on-board Orion that has been implemented primarily in Simulink. Currently, however, auto-coding Ramses into C++ requires 5 hours of code generation time. This causes issues if the tool ever needs to be debugged, as this code generation will need to occur with each edit to any part of the program; additionally, this is lost time that could be spent testing and analyzing the code. This is one of the more prominent issues with the auto-coding process, and while much information is available with regard to optimizing Simulink designs to produce efficient and reliable C++ code, not much research has been made public on how to reduce the code generation time. It is of interest to develop some insight as to what causes code generation times to be so significant, and determine if there are architecture guidelines or a desirable auto-coding configuration set to assist in streamlining this step of the design process for particular applications. To address the issue at hand, the Simulink coder was studied at a foundational level. For each different component type made available by the software, the features, auto-code generation time, and the format of the generated code were analyzed and documented. Tools were developed and documented to expedite these studies, particularly in the area of automating sequential builds to ensure accurate data was obtained. Next, the Ramses model was examined in an attempt to determine the composition and the types of technologies used in the model. This enabled the development of a model that uses similar technologies, but takes a fraction of the time to auto-code to reduce the turnaround time for experimentation. Lastly, the model was used to run a wide array of experiments and collect data to obtain knowledge about where to search for bottlenecks in the Ramses model. The resulting contributions of the overall effort consist of an experimental model for further investigation into the subject, as well as several automation tools to assist in analyzing the model, and a reference document offering insight to the auto-coding process, including documentation of the tools used in the model analysis, data illustrating some potential problem areas in the auto-coding process, and recommendations on areas or practices in the current Ramses model that should be further investigated. Several skills were required to be built up over the course of the internship project. First and foremost, my Simulink skills have improved drastically, as much of my experience had been modeling electronic circuits as opposed to software models. Furthermore, I am now comfortable working with the Simulink Auto-coder, a tool I had never used until this summer; this tool also tested my critical thinking and C++ knowledge as I had to interpret the C++ code it was generating and attempt to understand how the Simulink model affected the generated code. I had come into the internship with a solid understanding of Matlab code, but had done very little in using it to automate tasks, particularly Simulink tasks; along the same lines, I had rarely used shell script to automate and interface with programs, which I gained a fair amount of experience with this summer, including how to use regular expression. Lastly, soft-skills are an area everyone can continuously improve on; having never worked with NASA engineers, which to me seem to be a completely different breed than what I am used to (commercial electronic engineers), I learned to utilize the wealth of knowledge present at JSC. I wish I had come into the internship knowing exactly how helpful everyone in my branch would be, as I would have picked up on this sooner. I hope that having gained such a strong foundation in Simulink over this summer will open the opportunity to return to work on this project, or potentially other opportunities within the division. The idea of leaving a project I devoted ten weeks to is a hard one to cope with, so having the chance to pick up where I left off sounds appealing; alternatively, I am interested to see if there are any opening in the future that would allow me to work on a project that is more in-line with my research in estimation algorithms. Regardless, this summer has been a milestone in my professional career, and I hope this has started a long-term relationship between JSC and myself. I really enjoy the thought of building on my experience here over future summers while I work to complete my PhD at Missouri University of Science and Technology.
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.
It is often thought that translation of one programming language to another is a simple solution that can be used to extend the software life span or in rehosting software to another environment. The possible problems are examined as are the advantages and disadvantages of direct machine or human code translation versus that of redesign and rewrite of the software. The translation of the expert system language called C Language Integrated Production System (CLIPS) which is written in C, to Ada, will be used as a case study of the problems that are encountered.
Pulse code modulation telemetry encoder used in united kingdom satellite-c experiments
The technique of Pressure-Sensitive Paint (PSP) is commonly used in the aerospace industry to measure surface pressures on the model of launch vehicles and airplanes in the wind tunnel test. Recent research has demonstrated that Unsteady Pressure-Sensitive Paint (uPSP) can be an essential tool for the assessment of the unsteady, aerodynamic phenomena. The work described in this paper is a part of NASA’s development of a new state-of-the-art uPSP capability in production wind tunnels. This paper describes the spectral analysis of integrated pressures on patches of the scale model of the Space Launch System (SLS) Block 1 cargo vehicle with the uPSP measurements, which were collected in the Ascent Transient Aerodynamics Test (ATAT) with the Unitary Plan Wind Tunnel 11-by-11-foot Transonic Wind Tunnel in September 2019 at NASA Ames Research Center. The patches are defined with x station values, indicating the position along length of the SLS vehicle, and azimuth angles of the scale model. For each patch, the polygons are determined from the surface cells of the grid of the model, clipped with the edges of the patch, and each of the polygons is divided into triangles. The integrated pressure of the patch is determined as the ratio of the sum of the forces on the triangles over the sum of the areas of the triangles. For each run of the test, the Cross Power Spectral Density (CPSD) and magnitude squared coherence are computed from the time series of the integrated pressures on the patches. The pressure integration is coded in C++ and the spectral analysis is coded in MATLAB. The results were generated with the execution of the compiled C++ and MATLAB codes in parallel on the NASA Pleiades supercomputer. The results of pressure integration and spectral analysis are presented in this paper, and the data consistency of the test is also demonstrated. Funding for this research was provided by the NASA Aerosciences Evaluation and Test Capabilities Project.
Many turbomachinery CFD codes use second-order central-difference (C-D) schemes with artificial viscosity to control point decoupling and to capture shocks. While C-D schemes generally give accurate results, they can also exhibit minor numerical problems including overshoots at shocks and at the edges of viscous layers, and smearing of shocks and other flow features. In an effort to improve predictive capability for turbomachinery problems, two C-D codes developed by Chima, RVCQ3D and Swift, were modified by the addition of two upwind schemes: the AUSM+ scheme developed by Liou, et al., and the H-CUSP scheme developed by Tatsumi, et al. Details of the C-D scheme and the two upwind schemes are described, and results of three test cases are shown. Results for a 2-D transonic turbine vane showed that the upwind schemes eliminated viscous layer overshoots. Results for a 3-D turbine vane showed that the upwind schemes gave improved predictions of exit flow angles and losses, although the HCUSP scheme predicted slightly higher losses than the other schemes. Results for a 3-D supersonic compressor (NASA rotor 37) showed that the AUSM+ scheme predicted exit distributions of total pressure and temperature that are not generally captured by C-D codes. All schemes showed similar convergence rates, but the upwind schemes required considerably more CPU time per iteration.
Parallelization of Rocket Engine System Software (PRESS) project is part of a collaborative effort with Southern University at Baton Rouge (SUBR), University of West Florida (UWF), and Jackson State University (JSU). The second-year funding, which supports two graduate students enrolled in our new Master's program in Computer Science at Hampton University and the principal investigator, have been obtained for the period from October 19, 1996 through October 18, 1997. The key part of the interim report was new directions for the second year funding. This came about from discussions during Rocket Engine Numeric Simulator (RENS) project meeting in Pensacola on January 17-18, 1997. At that time, a software agreement between Hampton University and NASA Lewis Research Center had already been concluded. That agreement concerns off-NASA-site experimentation with PUMPDES/TURBDES software. Before this agreement, during the first year of the project, another large-scale FORTRAN-based software, Two-Dimensional Kinetics (TDK), was being used for translation to an object-oriented language and parallelization experiments. However, that package proved to be too complex and lacking sufficient documentation for effective translation effort to the object-oriented C + + source code. The focus, this time with better documented and more manageable PUMPDES/TURBDES package, was still on translation to C + + with design improvements. At the RENS Meeting, however, the new impetus for the RENS projects in general, and PRESS in particular, has shifted in two important ways. One was closer alignment with the work on Numerical Propulsion System Simulator (NPSS) through cooperation and collaboration with LERC ACLU organization. The other was to see whether and how NASA's various rocket design software can be run over local and intra nets without any radical efforts for redesign and translation into object-oriented source code. There were also suggestions that the Fortran based code be encapsulated in C + + code thereby facilitating reuse without undue development effort. The details are covered in the aforementioned section of the interim report filed on April 28, 1997.
Program synthesis is a technique for automatically deriving programs from specifications of their behavior. One of the arguments made in favour of program synthesis is that it allows one to trace from the specification to the program. One way in which traceability information can be derived is to augment the program synthesis system so that manipulations and calculations it carries out during the synthesis process are annotated with information on what the manipulations and calculations were and why they were made. This information is then accumulated throughout the synthesis process, at the end of which, every artifact produced by the synthesis is annotated with a complete history relating it to every other artifact (including the source specification) which influenced its construction. This approach requires modification of the entire synthesis system - which is labor-intensive and hard to do without influencing its behavior. In this paper, we introduce a novel, lightweight technique for deriving traceability from a program specification to the corresponding synthesized code. Once a program has been successfully synthesized from a specification, small changes are systematically made to the specification and the effects on the synthesized program observed. We have partially automated the technique and applied it in an experiment to one of our program synthesis systems, AUTOFILTER, and to the GNU C compiler, GCC. The results are promising: 1. Manual inspection of the results indicates that most of the connections derived from the source (a specification in the case of AUTOFILTER, C source code in the case of GCC) to its generated target (C source code in the case of AUTOFILTER, assembly language code in the case of GCC) are correct. 2. Around half of the lines in the target can be traced to at least one line of the source. 3. Small changes in the source often induce only small changes in the target.
Transportable Applications Environment Plus (TAE+) computer program providing integrated, portable programming environment for developing and running application programs based on interactive windows, text, and graphical objects. Enables both programmers and nonprogrammers to construct own custom application interfaces easily and to move interfaces and application programs to different computers. Used to define corporate user interface, with noticeable improvements in application developer's and end user's learning curves. Main components are; WorkBench, What You See Is What You Get (WYSIWYG) software tool for design and layout of user interface; and WPT (Window Programming Tools) Package, set of callable subroutines controlling user interface of application program. WorkBench and WPT's written in C++, and remaining code written in C.
We plan to perform the following sets of computations on unadapted (fixed) grids: 1) Structured RANS set 1 (Code: CFL3D, Grid: Str-OnetoOne-A-v1 (supplied by HiLiftPW-1 committee), Turbulence model: Spalart-Allmaras), 2) Structured RANS set 2 (Code: CFL3D, Grid: Str-OnetoOne-A-v1 (supplied by HiLiftPW-1 committee), Turbulence model: Menter SST), 3) Structured RANS set 3 (time permitting) (Code: CFL3D, Grid: Str-OnetoOne-B-v1 (supplied by HiLiftPW-1 committee), Turbulence model: Menter SST), 4) Unstructured RANS set 1 (Code: FUN3D, Grid: Unst-Mixed-FromTet-Nodecentered-A-v1 (supplied by HiLiftPW-1 committee), Turbulence model: Spalart-Allmaras), and 5) Unstructured RANS set 2 (time permitting) (Code: FUN3D, Grid: Unst-Hex-FromOnetoOne-A-v1 (supplied by HiLiftPW-1 committee), Turbulence model: Spalart-Allmaras),. Optional case 3 is not being computed. CFL3D is a structured upwind-biased cell-centered RANS code,1 and FUN3D is an unstructured upwind-biased node-centered RANS code
Communication systems development - minimizing range code acquisition time