SEARCH · Search NASA

Results for “Coding Standard”

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 343 records · Page 19

All sources NASA NTRS DOE OSTI

NASA NTRS1993

Comparison of FDNS liquid rocket engine plume computations with SPF/2

Prediction of a plume's shape and structure is essential to the evaluation of base region environments. The JANNAF standard plume flowfield analysis code SPF/2 predicts plumes well, but cannot analyze base regions. Full Navier-Stokes CFD codes can calculate both zones; however, before they can be used, they must be validated. The CFD code FDNS3D (Finite Difference Navier-Stokes Solver) was used to analyze the single plume of a Space Transportation Main Engine (STME) and comparisons were made with SPF/2 computations. Both frozen and finite rate chemistry models were employed as well as two turbulence models in SPF/2. The results indicate that FDNS3D plume computations agree well with SPF/2 predictions for liquid rocket engine plumes.

Kumar, G. N.↗

NASA NTRS1994

Portable Software For Numerically Controlled Machining

P-APT, Portable APT, is revised version of APT written to conform to FORTRAN 77 standard. Machine-dependent code replaced or isolated and documented.

Poland, J.↗

NASA NTRS2006

Analysis of a Cylindrical Specimen Heated by an Impinging Hot Hydrogen Jet

A computational conjugate heat transfer methodology was developed, as a first step towards an efficient and accurate multiphysics, thermo-fluid computational methodology to predict environments for hypothetical solid-core, nuclear thermal engine thrust chamber and components. A solid conduction heat transfer procedure was implemented onto a pressure-based, multidimensional, finite-volume, turbulent, chemically reacting, thermally radiating, and unstructured grid computational fluid dynamics formulation. The conjugate heat transfer of a cylindrical material specimen heated by an impinging hot hydrogen jet inside an enclosed test fixture was simulated and analyzed. The solid conduction heat transfer procedure was anchored with a standard solid heat transfer code. Transient analyses were then performed with ,variable thermal conductivities representing three composites of a material utilized as flow element in a legacy engine test. It was found that material thermal conductivity strongly influences the transient heat conduction characteristics. In addition, it was observed that high thermal gradient occur inside the cylindrical specimen during an impulsive or a 10 s ramp start sequence, but not during steady-state operations.

Wang, Ten-See↗

NASA NTRS2006

Influence of Finite Element Software on Energy Release Rates Computed Using the Virtual Crack Closure Technique

Strain energy release rates were computed along straight delamination fronts of Double Cantilever Beam, End-Notched Flexure and Single Leg Bending specimens using the Virtual Crack Closure Technique (VCCT). Th e results were based on finite element analyses using ABAQUS# and ANSYS# and were calculated from the finite element results using the same post-processing routine to assure a consistent procedure. Mixed-mode strain energy release rates obtained from post-processing finite elem ent results were in good agreement for all element types used and all specimens modeled. Compared to previous studies, the models made of s olid twenty-node hexahedral elements and solid eight-node incompatible mode elements yielded excellent results. For both codes, models made of standard brick elements and elements with reduced integration did not correctly capture the distribution of the energy release rate acr oss the width of the specimens for the models chosen. The results suggested that element types with similar formulation yield matching results independent of the finite element software used. For comparison, m ixed-mode strain energy release rates were also calculated within ABAQUS#/Standard using the VCCT for ABAQUS# add on. For all specimens mod eled, mixed-mode strain energy release rates obtained from ABAQUS# finite element results using post-processing were almost identical to re sults calculated using the VCCT for ABAQUS# add on.

Krueger, Ronald↗

NASA NTRS1988

Method and apparatus for implementing a maximum-likelihood decoder in a hypercube network

Pollara-Bozzola, Fabrizio↗

NASA NTRS1989

Method and apparatus for implementing a traceback maximum-likelihood decoder in a hypercube network

A method and a structure to implement maximum-likelihood decoding of convolutional codes on a network of microprocessors interconnected as an n-dimensional cube (hypercube). By proper reordering of states in the decoder, only communication between adjacent processors is required. Communication time is limited to that required for communication only of the accumulated metrics and not the survivor parameters of a Viterbi decoding algorithm. The survivor parameters are stored at a local processor's memory and a trace-back method is employed to ascertain the decoding result. Faster and more efficient operation is enabled, and decoding of large constraint length codes is feasible using standard VLSI technology.

Pollara-Bozzola, Fabrizio↗

NASA NTRS2006

Rotating-Pump Design Code

Pump Design (PUMPDES) is a computer program for designing a rotating pump for liquid hydrogen, liquid oxygen, liquid nitrogen, water, methane, or ethane. Using realistic properties of these fluids provided by another program called GASPAK, this code performs a station-by-station, mean-line analysis along the pump flow path, obtaining thermodynamic properties of the pumped fluid at each station and evaluating hydraulic losses along the flow path. The variables at each station are obtained under constraints that are consistent with the underlying physical principles. The code evaluates the performance of each stage and the overall pump. In addition, by judiciously choosing the givens and the unknowns, the code can perform a geometric inverse design function: that is, it can compute a pump geometry that yields a closest approximation of given design point. The code contains two major parts: one for an axial-rotor/inducer and one for a multistage centrifugal pump. The inducer and the centrifugal pump are functionally integrated. The code can be used in designing and/or evaluating the inducer/centrifugal-pump combination or the centrifugal pump alone. The code is written in standard Fortran 77.

Walker, James F.↗

NASA NTRS2013

Mars Sample Return Landed with Red Dragon

A Mars Sample Return (MSR) mission is the highest priority science mission for the next decade as recommended by the recent Decadal Survey of Planetary Science. However, an affordable program to carry this out has not been defined. This paper describes a study that examined use of emerging commercial capabilities to land the sample return elements, with the goal of reducing mission cost. A team at NASA Ames examined the feasibility of the following scenario for MSR: A Falcon Heavy launcher injects a SpaceX Dragon crew capsule and trunk onto a Trans Mars Injection trajectory. The capsule is modified to carry all the hardware needed to return samples collected on Mars including a Mars Ascent Vehicle (MAV), an Earth Return Vehicle (ERV) and Sample Collection and Storage hardware. The Dragon descends to land on the surface of Mars using SuperSonic Retro Propulsion (SSRP) as described by Braun and Manning [IEEEAC paper 0076, 2005]. Samples are acquired and deliverd to the MAV by a prelanded asset, possibly the proposed 2020 rover. After samples are obtained and stored in the ERV, the MAV launches the sample-containing ERV from the surface of Mars. We examined cases where the ERV is delivered to either low Mars orbit (LMO), C3 = 0 (Mars escape), or an intermediate energy state. The ERV then provides the rest of the energy (delta V) required to perform trans-Earth injection (TEI), cruise, and insertion into a Moon-trailing Earth Orbit (MTEO). A later mission, possibly a crewed Dragon launched by a Falcon Heavy (not part of the current study) retrieves the sample container, packages the sample, and performs a controlled Earth re-entry to prevent Mars materials from accidentally contaminating Earth. The key analysis methods used in the study employed a set of parametric mass estimating relationships (MERs) and standard aerospace analysis software codes modified for the MAV class of launch vehicle to determine the range of performance parameters that produced converged spacecraft designs capable of meeting mission requirements. Subsystems modeled in this study included structures, power system, propulsion system, nose fairing, thermal insulation, actuation devices, and GN&C. Best practice application of loads and design margins for all resources were used. Both storable and cryogenic propellant systems were examined. The landed mass and lander capsule size provide boundary conditions for the MAV design and packaging. We estimated the maximum mass the Dragon capsule is capable of landing. This and the volume capability to store the MAV was deduced from publically available data from SpaceX as well as our own engineering and aerodynamic estimates. Minimum gross-liftoff mass (GLOM) for the MAV were obtained for configurations that used pump-fed storable bi-propellant rocket engines for both the MAV and the ERV stage. The GLOM required fits within our internal estimate of the mass that Dragon can land at low elevation/optimal seasons on Mars. Based on the analysis, we show that a single Mars launch sample return mission is feasible using current commercial capabilities to deliver the return spacecraft assets.

Mars Ascent Vehicle (MAV)↗

NASA NTRS2017

Software Verification of Orion Cockpit Displays

NASA's latest spacecraft Orion is in the development process of taking humans deeper into space. Orion is equipped with three main displays to monitor and control the spacecraft. To ensure the software behind the glass displays operates without faults, rigorous testing is needed. To conduct such testing, the Rapid Prototyping Lab at NASA's Johnson Space Center along with the University of Texas at Tyler employed a software verification tool, EggPlant Functional by TestPlant. It is an image based test automation tool that allows users to create scripts to verify the functionality within a program. A set of edge key framework and Common EggPlant Functions were developed to enable creation of scripts in an efficient fashion. This framework standardized the way to code and to simulate user inputs in the verification process. Moreover, the Common EggPlant Functions can be used repeatedly in verification of different displays.

Biswas, M. A. Rafe↗

NASA NTRS2020

Blackbird: Object-Oriented Planning, Simulation, and Sequencing Framework Used by Multiple Missions

Every JPL flight mission relies on activity planning and sequence generation software to perform operations. Most such tools in use at JPL and elsewhere use attribute-based schemas or domain-specific languages (DSLs) to define activities. This reliance poses user training, software maintenance, performance, and other challenges. To solve this problem for future missions, a new software called Blackbird was developed which allows engineers to specify behavior in standard Java. The new code base has over an order of magnitude fewer lines of code than other JPL planning software, since no DSL or schema interpreter is needed. The use of Java for defining activities also allows mission adapters to debug their code in an integrated development environment, seamlessly call external libraries, and set up truly multimission models. These efficiency gains have significantly reduced the amount of development effort required to support the software. This paper discusses Blackbird’s design, principles, and use cases.

Lawler, Christopher↗

DOE OSTI2024

Detection and Quantitation of Hydrogen Emissions Role and Status of Detection Technology

Hydrogen is a critical strategy to decarbonize energy and manufacturing industries. Hydrogen is nontoxic and can be handled safely, but potential for secondary greenhouse impacts. Hydrogen releases arise from a variety of mechanisms (process, design features, "leaks") that contribute to total hydrogen releases. Detection methodologies will be critical to detect and quantify hydrogen emissions. Detection is to be integrated with advanced analytics (AI) and behavior modelling to effectively identify, quantify, and source locate hydrogen releases. Modelling of emissions will contribute to facility safety and reliability. DOE is committed to develop the tools to model and mitigate the impact of hydrogen releases which include: Support modeling to elucidate released hydrogen degradation; Support the development of tools for emissions quantitation; and Support engineering advancements to minimize hydrogen losses along the value chain (including process, design features, and leaks).

detection↗

NASA NTRS1984

Reed Solomon codes for error control in byte organized computer memory systems

A problem in designing semiconductor memories is to provide some measure of error control without requiring excessive coding overhead or decoding time. In LSI and VLSI technology, memories are often organized on a multiple bit (or byte) per chip basis. For example, some 256K-bit DRAM's are organized in 32Kx8 bit-bytes. Byte oriented codes such as Reed Solomon (RS) codes can provide efficient low overhead error control for such memories. However, the standard iterative algorithm for decoding RS codes is too slow for these applications. Some special decoding techniques for extended single-and-double-error-correcting RS codes which are capable of high speed operation are presented. These techniques are designed to find the error locations and the error values directly from the syndrome without having to use the iterative algorithm to find the error locator polynomial.

Lin, S.↗

NASA NTRS1985

Error control for reliable digital data transmission and storage systems

A problem in designing semiconductor memories is to provide some measure of error control without requiring excessive coding overhead or decoding time. In LSI and VLSI technology, memories are often organized on a multiple bit (or byte) per chip basis. For example, some 256K-bit DRAM's are organized in 32Kx8 bit-bytes. Byte oriented codes such as Reed Solomon (RS) codes can provide efficient low overhead error control for such memories. However, the standard iterative algorithm for decoding RS codes is too slow for these applications. In this paper we present some special decoding techniques for extended single-and-double-error-correcting RS codes which are capable of high speed operation. These techniques are designed to find the error locations and the error values directly from the syndrome without having to use the iterative alorithm to find the error locator polynomial. Two codes are considered: (1) a d sub min = 4 single-byte-error-correcting (SBEC), double-byte-error-detecting (DBED) RS code; and (2) a d sub min = 6 double-byte-error-correcting (DBEC), triple-byte-error-detecting (TBED) RS code.

Costello, D. J., Jr.↗

NASA NTRS1987

Decoding of DBEC-TBED Reed-Solomon codes

A problem in designing semiconductor memories is to provide some measure of error control without requiring excessive coding overhead or decoding time. In LSI and VLSI technology, memories are often organized on a multiple bit (or byte) per chip basis. For example, some 256 K bit DRAM's are organized in 32 K x 8 bit-bytes. Byte-oriented codes such as Reed-Solomon (RS) codes can provide efficient low overhead error control for such memories. However, the standard iterative algorithm for decoding RS codes is too slow for these applications. The paper presents a special decoding technique for double-byte-error-correcting, triple-byte-error-detecting RS codes which is capable of high-speed operation. This technique is designed to find the error locations and the error values directly from the syndrome without having to use the iterative algorithm to find the error locator polynomial.

Deng, Robert H.↗

NASA NTRS2015

The Role of Margin in Link Design and Optimization

Link analysis is a system engineering process in the design, development, and operation of communication systems and networks. Link models that are mathematical abstractions representing the useful signal power and the undesirable noise and attenuation effects (including weather effects if the signal path transverses through the atmosphere) that are integrated into the link budget calculation that provides the estimates of signal power and noise power at the receiver. Then the link margin is applied which attempts to counteract the fluctuations of the signal and noise power to ensure reliable data delivery from transmitter to receiver. (Link margin is dictated by the link margin policy or requirements.) A simple link budgeting approach assumes link parameters to be deterministic values typically adopted a rule-of-thumb policy of 3 dB link margin. This policy works for most S- and X-band links due to their insensitivity to weather effects. But for higher frequency links like Ka-band, Ku-band, and optical communication links, it is unclear if a 3 dB link margin would guarantee link closure. Statistical link analysis that adopted the 2-sigma or 3-sigma link margin incorporates link uncertainties in the sigma calculation. (The Deep Space Network (DSN) link margin policies are 2-sigma for downlink and 3-sigma for uplink.) The link reliability can therefore be quantified statistically even for higher frequency links. However in the current statistical link analysis approach, link reliability is only expressed as the likelihood of exceeding the signal-to-noise ratio (SNR) threshold that corresponds to a given bit-error-rate (BER) or frame-error-rate (FER) requirement. The method does not provide the true BER or FER estimate of the link with margin, or the required signalto-noise ratio (SNR) that would meet the BER or FER requirement in the statistical sense. In this paper, we perform in-depth analysis on the relationship between BER/FER requirement, operating SNR, and coding performance curve, in the case when the channel coherence time of link fluctuation is comparable or larger than the time duration of a codeword. We compute the "true" SNR design point that would meet the BER/FER requirement by taking into account the fluctuation of signal power and noise power at the receiver, and the shape of the coding performance curve. This analysis yields a number of valuable insights on the design choices of coding scheme and link margin for the reliable data delivery of a communication system - space and ground. We illustrate the aforementioned analysis using a number of standard NASA error-correcting codes.

Cheung, K.↗

NASA NTRS1990

CCSDS Reed Solomon VLSI chip set

A highly efficient error correcting code has been selected by NASA as a CCSDS standard: the 16 symbol error correcting Reed Solomon code. A VLSI implementation of this decoder is described in this paper. A total of 4 full custom VLSI chips are needed that correct data in real time at an sustained rate of up to 80 Mbits/second.

Cameron, K.↗

NASA NTRS2012

Auto Code Generation for Simulink-Based Attitude Determination Control System

This paper details the work done to auto generate C code from a Simulink-Based Attitude Determination Control System (ADCS) to be used in target platforms. NASA Marshall Engineers have developed an ADCS Simulink simulation to be used as a component for the flight software of a satellite. This generated code can be used for carrying out Hardware in the loop testing of components for a satellite in a convenient manner with easily tunable parameters. Due to the nature of the embedded hardware components such as microcontrollers, this simulation code cannot be used directly, as it is, on the target platform and must first be converted into C code; this process is known as auto code generation. In order to generate C code from this simulation; it must be modified to follow specific standards set in place by the auto code generation process. Some of these modifications include changing certain simulation models into their atomic representations which can bring new complications into the simulation. The execution order of these models can change based on these modifications. Great care must be taken in order to maintain a working simulation that can also be used for auto code generation. After modifying the ADCS simulation for the auto code generation process, it is shown that the difference between the output data of the former and that of the latter is between acceptable bounds. Thus, it can be said that the process is a success since all the output requirements are met. Based on these results, it can be argued that this generated C code can be effectively used by any desired platform as long as it follows the specific memory requirements established in the Simulink Model.

MolinaFraticelli, Jose Carlos↗

NASA NTRS2020

Julia Programming Language Benchmark Using a Flight Simulation

Julia’s goal to provide scripting language ease-of-coding with compiled language speed is explored. The runtime speed of the relatively new Julia programming language is assessed against other commonly used languages including Python, Java, and C++. An industry-standard missile and rocket simulation, coded in multiple languages, was used as a test bench for runtime speed. All language versions of the simulation, including Julia, were coded to a highly-developed object-oriented simulation architecture tailored specifically for time-domain flight simulation. A “speed-of-coding” second-dimension is plotted against runtime for each language to portray a space that characterizes Julia’s scripting language efficiencies in the context of the other languages. With caveats, Julia runtime speed was found to be in the class of compiled or semi-compiled languages. However, some factors that affect runtime speed at the cost of ease-of-coding are shown. Julia’s built-in functionality for multi-core processing is briefly examined as a means for obtaining even faster runtime speed. The major contribution of this research to the extensive language benchmarking body-of-work is comparing Julia to other mainstream languages using a complex flight simulation as opposed to benchmarking with single algorithms.

Sells, Ray↗