SEARCH · Engineering Papers

Results for “Implementation”

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 55 records · Page 3

All sources NASA NTRS DOE OSTI

NASA NTRS1991

The effects of long delay and transmission errors on the performance of TP-4 implementations

A set of tools that allows us to measure and examine the effects of transmission delay and errors on the performance of TP-4 implementations has been developed. The tools give insight into both the large- and small-scale behaviors of an implementation. These tools have been systematically applied to a commercial implementation of TP-4. Measurements show, among other things, that a 2-second one-way transmission delay and an effective bit-error rate of 1 error per 100,000 bits can result in a 95 percent reduction in TP-4 throughput. The detailed statistics give insight into why transmission delay and errors affect this implementations so significantly and support a number of 'lessons learned' that could be applied to TP-4 implementations that operate more robustly across networks with long transmission delays and transmission errors.

Durst, Robert C.↗

NASA NTRS1993

Implementation of ADI: Schemes on MIMD parallel computers

In order to simulate the effects of the impingement of hot exhaust jets of High Performance Aircraft on landing surfaces a multi-disciplinary computation coupling flow dynamics to heat conduction in the runway needs to be carried out. Such simulations, which are essentially unsteady, require very large computational power in order to be completed within a reasonable time frame of the order of an hour. Such power can be furnished by the latest generation of massively parallel computers. These remove the bottleneck of ever more congested data paths to one or a few highly specialized central processing units (CPU's) by having many off-the-shelf CPU's work independently on their own data, and exchange information only when needed. During the past year the first phase of this project was completed, in which the optimal strategy for mapping an ADI-algorithm for the three dimensional unsteady heat equation to a MIMD parallel computer was identified. This was done by implementing and comparing three different domain decomposition techniques that define the tasks for the CPU's in the parallel machine. These implementations were done for a Cartesian grid and Dirichlet boundary conditions. The most promising technique was then used to implement the heat equation solver on a general curvilinear grid with a suite of nontrivial boundary conditions. Finally, this technique was also used to implement the Scalar Penta-diagonal (SP) benchmark, which was taken from the NAS Parallel Benchmarks report. All implementations were done in the programming language C on the Intel iPSC/860 computer.

Vanderwijngaart, Rob F.↗

NASA NTRS1993

Study of the Alsys implementation of the Catalogue of Interface Features and Options for the Ada language for 80386 Unix

A set of programs was written to test the functionality and performance of the Alsys Ada implementation of the Catalogue of Interface Features and Options (CIFO), a set of optional Ada packages for real-time applications. No problems were found with the task id, preemption control, or shared-data packages. Minor problems were found with the dispatching control, dynamic priority, events, non-waiting entry call, semaphore, and scheduling packages. The Alsys implementation is derived mostly from Release 2 of the CIFO standard, but includes some of the features of Release 3 and some modifications unique to Alsys. Performance measurements show that the semaphore and shared-data features are an order-of-magnitude faster than the same mechanisms using an Ada rendezvous. The non-waiting entry call is slightly faster than a standard rendezvous. The existence of errors in the implementation, the incompleteness of the documentation from the published standard impair the usefulness of this implementation. Despite those short-comings, the Alsys CIFO implementation might be of value in the development of real-time applications.

Gibson, James S.↗

NASA NTRS1995

Design, Implementation, and Verification of the Reliable Multicast Protocol

This document describes the Reliable Multicast Protocol (RMP) design, first implementation, and formal verification. RMP provides a totally ordered, reliable, atomic multicast service on top of an unreliable multicast datagram service. RMP is fully and symmetrically distributed so that no site bears an undue portion of the communications load. RMP provides a wide range of guarantees, from unreliable delivery to totally ordered delivery, to K-resilient, majority resilient, and totally resilient atomic delivery. These guarantees are selectable on a per message basis. RMP provides many communication options, including virtual synchrony, a publisher/subscriber model of message delivery, a client/server model of delivery, mutually exclusive handlers for messages, and mutually exclusive locks. It has been commonly believed that total ordering of messages can only be achieved at great performance expense. RMP discounts this. The first implementation of RMP has been shown to provide high throughput performance on Local Area Networks (LAN). For two or more destinations a single LAN, RMP provides higher throughput than any other protocol that does not use multicast or broadcast technology. The design, implementation, and verification activities of RMP have occurred concurrently. This has allowed the verification to maintain a high fidelity between design model, implementation model, and the verification model. The restrictions of implementation have influenced the design earlier than in normal sequential approaches. The protocol as a whole has matured smoother by the inclusion of several different perspectives into the product development.

Montgomery, Todd L.↗

NASA NTRS1995

Performance Comparison of a Matrix Solver on a Heterogeneous Network Using Two Implementations of MPI: MPICH and LAM

Two of the current and most popular implementations of the Message-Passing Standard, Message Passing Interface (MPI), were contrasted: MPICH by Argonne National Laboratory, and LAM by the Ohio Supercomputer Center at Ohio State University. A parallel skyline matrix solver was adapted to be run in a heterogeneous environment using MPI. The Message-Passing Interface Forum was held in May 1994 which lead to a specification of library functions that implement the message-passing model of parallel communication. LAM, which creates it's own environment, is more robust in a highly heterogeneous network. MPICH uses the environment native to the machine architecture. While neither of these free-ware implementations provides the performance of native message-passing or vendor's implementations, MPICH begins to approach that performance on the SP-2. The machines used in this study were: IBM RS6000, 3 Sun4, SGI, and the IBM SP-2. Each machine is unique and a few machines required specific modifications during the installation. When installed correctly, both implementations worked well with only minor problems.

Phillips, Jennifer K.↗

NASA NTRS1999

System Issues Related to Implementing on the Internet

Implementing capabilities on the World Wide Web should never be taken lightly. A good systems engineer is able to examine such implementations from all points of view, including political, legal, security, access, technical deployment, and quality. The evacuation discussed in this paper was conducted to ensure that the National Aeronautics and Space Administration (NASA) was proceeding in a correct direction by implementing RECALL a Lessons Learned System on the Web and, subsequently, did so successfully. The systems approach extended well beyond technical implementation to several issue that are not often addressed by an implementation team. The resulting evaluation increased the team's sensitivity to such issues and, in fact, the authors believe that the evaluation provided as much benefit as the system itself.

Mackey, William↗

NASA NTRS1999

Implementation of Multispectral Image Classification on a Remote Adaptive Computer

As the demand for higher performance computers for the processing of remote sensing science algorithms increases, the need to investigate new computing paradigms its justified. Field Programmable Gate Arrays enable the implementation of algorithms at the hardware gate level, leading to orders of m a,gnitude performance increase over microprocessor based systems. The automatic classification of spaceborne multispectral images is an example of a computation intensive application, that, can benefit from implementation on an FPGA - based custom computing machine (adaptive or reconfigurable computer). A probabilistic neural network is used here to classify pixels of of a multispectral LANDSAT-2 image. The implementation described utilizes Java client/server application programs to access the adaptive computer from a remote site. Results verify that a remote hardware version of the algorithm (implemented on an adaptive computer) is significantly faster than a local software version of the same algorithm implemented on a typical general - purpose computer).

Figueiredo, Marco A.↗

NASA NTRS2002

Engineering Management Capstone Project EM 697: Compare and Contrast Risk Management Implementation at NASA and the US Army

NASA at Marshall Space Flight Center (MSFC) and the U.S. Army at Redstone Arsenal were analyzed to determine whether they were successful in implementing their risk management program. Risk management implementation surveys were distributed to aid in this analysis. The scope is limited to NASA S&MA (Safety and Mission Assurance) at MSFC, including applicable support contractors, and the US Army Engineering Directorate, including applicable contractors, located at Redstone Arsenal. NASA has moderately higher risk management implementation survey scores than the Army. Accordingly, the implementation of the risk management program at NASA is considered good while only two of five of the survey categories indicated that the risk management implementation is good at the Army.

Brothers, Mary Ann↗

NASA NTRS2004

Risk Management Implementation Tool

Continuous Risk Management (CM) is a software engineering practice with processes, methods, and tools for managing risk in a project. It provides a controlled environment for practical decision making, in order to assess continually what could go wrong, determine which risk are important to deal with, implement strategies to deal with those risk and assure the measure effectiveness of the implemented strategies. Continuous Risk Management provides many training workshops and courses to teach the staff how to implement risk management to their various experiments and projects. The steps of the CRM process are identification, analysis, planning, tracking, and control. These steps and the various methods and tools that go along with them, identification, and dealing with risk is clear-cut. The office that I worked in was the Risk Management Office (RMO). The RMO at NASA works hard to uphold NASA s mission of exploration and advancement of scientific knowledge and technology by defining and reducing program risk. The RMO is one of the divisions that fall under the Safety and Assurance Directorate (SAAD). I worked under Cynthia Calhoun, Flight Software Systems Engineer. My task was to develop a help screen for the Continuous Risk Management Implementation Tool (RMIT). The Risk Management Implementation Tool will be used by many NASA managers to identify, analyze, track, control, and communicate risks in their programs and projects. The RMIT will provide a means for NASA to continuously assess risks. The goals and purposes for this tool is to provide a simple means to manage risks, be used by program and project managers throughout NASA for managing risk, and to take an aggressive approach to advertise and advocate the use of RMIT at each NASA center.

Wright, Shayla L.↗

NASA NTRS1999

Method and apparatus for controlling an earthworking implement to preserve a crown on a road surface

A method and apparatus for controlling an earthworking implement on an earthworking machine to preserve a crown on the surface of a road, including determining the position of the crown on the road surface, choosing a sloped grade on one side of the crown, positioning the earthworking implement on the sloped grade so that a first end of the earthworking implement is on the road surface. The processor determines a desired position of a second end of the earthworking implement so that the second end overlaps the crown and the earthworking implement does not cut the crown.

Staub, Michael D.↗

NASA NTRS2009

Integrated System Health Management: Foundational Concepts, Approach, and Implementation

Implementation of integrated system health management (ISHM) capability is fundamentally linked to the management of data, information, and knowledge (DIaK) with the purposeful objective of determining the health of a system. It is akin to having a team of experts who are all individually and collectively observing and analyzing a complex system, and communicating effectively with each other in order to arrive to an accurate and reliable assessment of its health. This paper presents concepts, procedures, and a specific approach as a foundation for implementing a credible ISHM capability. The capability stresses integration of DIaK from all elements of a subsystem. The intent is also to make possible implementation of on-board ISHM capability, in contrast to a remote capability. The information presented is the result of many years of research, development, and maturation of technologies, and of prototype implementations in operational systems (rocket engine test facilities). The paper will address the following topics: ISHM Model of a system; detection of anomaly indicators; determination and confirmation of anomalies; diagnostic of causes and determination of effects; consistency checking cycle; sharing of health information; sharing of display information; storage and retrieval of health information; and example implementation.

Figueroa, Fernando↗

NASA NTRS2011

Multi-Center Implementation of NPR 7123.1A: A Collaborative Effort

Collaboration efforts between MSFC and GRC Engineering Directorates to implement the NASA Systems Engineering (SE) Engine have expanded over the past year to include other NASA Centers. Sharing information on designing, developing, and deploying SE processes has sparked further interest based on the realization that there is relative consistency in implementing SE processes at the institutional level. This presentation will provide a status on the ongoing multi-center collaboration and provide insight into how these NPR 7123.1A SE-aligned directives are being implemented and managed to better support the needs of NASA programs and projects. NPR 7123.1A, NASA Systems Engineering Processes and Requirements, was released on March 26, 2007 to clearly articulate and establish the requirements on the implementing organization for performing, supporting, and evaluating SE activities. In early 2009, MSFC and GRC Engineering Directorates undertook a collaborative opportunity to share their research and work associated with developing, updating and revising their SE process policy to comply and align with NPR 7123.1A. The goal is to develop instructions, checklists, templates, and procedures for each of the 17 SE process requirements so that systems engineers will be a position to define work that is process-driven. Greater efficiency and more effective technical management will be achieved due to consistency and repeatability of SE process implementation across and throughout each of the NASA centers. An added benefit will be to encourage NASA centers to pursue and collaborate on joint projects as a result of using common or similar processes, methods, tools, and techniques.

Hall, Phillip B.↗

NASA NTRS2011

Axisymmetric Implementation for 3D-Based DSMC Codes

The primary objective in developing NASA s DSMC Analysis Code (DAC) was to provide a high fidelity modeling tool for 3D rarefied flows such as vacuum plume impingement and hypersonic re-entry flows [1]. The initial implementation has been expanded over time to offer other capabilities including a novel axisymmetric implementation. Because of the inherently 3D nature of DAC, this axisymmetric implementation uses a 3D Cartesian domain and 3D surfaces. Molecules are moved in all three dimensions but their movements are limited by physical walls to a small wedge centered on the plane of symmetry (Figure 1). Unfortunately, far from the axis of symmetry, the cell size in the direction perpendicular to the plane of symmetry (the Z-direction) may become large compared to the flow mean free path. This frequently results in inaccuracies in these regions of the domain. A new axisymmetric implementation is presented which aims to solve this issue by using Bird s approach for the molecular movement while preserving the 3D nature of the DAC software [2]. First, the computational domain is similar to that previously used such that a wedge must still be used to define the inflow surface and solid walls within the domain. As before molecules are created inside the inflow wedge triangles but they are now rotated back to the symmetry plane. During the move step, molecules are moved in 3D but instead of interacting with the wedge walls, the molecules are rotated back to the plane of symmetry at the end of the move step. This new implementation was tested for multiple flows over axisymmetric shapes, including a sphere, a cone, a double cone and a hollow cylinder. Comparisons to previous DSMC solutions and experiments, when available, are made.

Stewart, Benedicte↗

NASA NTRS2013

Implementation of a Goal-Based Systems Engineering Process Using the Systems Modeling Language (SysML)

Building upon the purpose, theoretical approach, and use of a Goal-Function Tree (GFT) being presented by Dr. Stephen B. Johnson, described in a related Infotech 2013 ISHM abstract titled "Goal-Function Tree Modeling for Systems Engineering and Fault Management", this paper will describe the core framework used to implement the GFTbased systems engineering process using the Systems Modeling Language (SysML). These two papers are ideally accepted and presented together in the same Infotech session. Statement of problem: SysML, as a tool, is currently not capable of implementing the theoretical approach described within the "Goal-Function Tree Modeling for Systems Engineering and Fault Management" paper cited above. More generally, SysML's current capabilities to model functional decompositions in the rigorous manner required in the GFT approach are limited. The GFT is a new Model-Based Systems Engineering (MBSE) approach to the development of goals and requirements, functions, and its linkage to design. As a growing standard for systems engineering, it is important to develop methods to implement GFT in SysML. Proposed Method of Solution: Many of the central concepts of the SysML language are needed to implement a GFT for large complex systems. In the implementation of those central concepts, the following will be described in detail: changes to the nominal SysML process, model view definitions and examples, diagram definitions and examples, and detailed SysML construct and stereotype definitions.

Patterson, Jonathan D.↗

NASA NTRS2013

Implementation of a Goal-Based Systems Engineering Process Using the Systems Modeling Language (SysML)

Breckenridge, Jonathan T.↗

NASA NTRSDate not supplied

Developing Procedures to Implement Geometric Imperfections Beyond Right Circular Cylindrical Shells in Finite Element Method Models

Analysis of aerospace structures is frequently conducted using nominal dimensions and frequently assumes ideal conditions in loading, contact, constraints, et cetera. Off-nominal dimensions and nonideal conditions, however, are present in all structures. These are the result of widely ranging causes from coefficient of thermal expansion mismatches, manufacturing tooling anomalies, to assembly procedures that inadvertently alter the structure. Specifically, geometric imperfections can have potentially significant influence on the response of a structural test article observed in an experiment versus the response given by a numerical simulation. The Python Tool for Implementing Geometric Imperfections in Reduced Structures (Py_TIGIRS) was previously presented as a set of Python scripts to calculate and implement as-manufactured geometric midsurface and thickness imperfections into finite element method (FEM) shell models of nominally right circular cylinders. By taking advantage of the simple shape of a right circular cylinder, interpolations of the measured data points were able to be performed along directions that aligned to the cylindrical coordinate system axes of the entire structure. By taking advantage of the shell representation of the real structure as opposed to modeling using a continuum representation, the thickness variation was able to be implemented by shell section definitions instead of having to modify the position of multiple nodes in the thickness direction. Py_TIGIRS is a useful tool that established a procedural example on how to implement geometric imperfections in right circular cylindrical shell structures. Three new procedures, each expanded from concepts established in Py_TIGIRS, are proposed for various test-article designs and are intended to broaden the range of structures that can be modeled with measured geometric imperfections in the structural analysis community. Each test-article design introduces new challenges to successfully implement geometric imperfections into a FEM model. The first test-article design consists of a carbon fiber reinforced polymer square plate with a hat-shaped stiffener co-cured on one side. This test-article design was for a novel seven-point bend test that was also previously presented. Manufacturing and cure-cycle imperfections are observed using digital image correlation (DIC) techniques. As thermal expansion coefficient mismatches between the plate and stiffener materials were anticipated, a thermal analysis study with continuum shell and solid elements was conducted to capture the global shape observed prior to testing. The second test-article design is of a similar hat-stiffened plate configuration, but with a side length ratio near 3:1 with elongation in the stiffener direction. The test article was used to characterize the response to uniaxial compressive loading in the direction of the stiffener. Due to differing manufacturing steps, a thermal analysis like the one developed for the seven-point bend configuration was unable to mimic the observed geometric imperfections. Instead, a strategy based on applying deformations directly to the structure during analysis was developed for continuum shell and solid element representation of a stiffened panel.

Geometric imperfections↗

NASA NTRSDate not supplied

Risk-Reduction Autonomy Implementation to Enable NASA Artemis Missions

To achieve NASA’s Artemis program mission objectives a high level of autonomy and ubiquitous autonomy throughout the systems that are being developed will be necessary. The autonomous systems of Artemis will require a distributed autonomy capability, with autonomous systems organized functionally in a hierarchical architecture, where systems at higher levels of the hierarchy have authority over systems at lower levels. The challenge of developing autonomy technologies and concepts of operations for Artemis has been undertaken by the NASA Gateway Working Group. This group has developed requirements, architectures, concepts of operations, and interface control documents, in the context of a hierarchical distributed architecture that includes the following: a Vehicle System Manager (VSM) that autonomously manages the entire Gateway; Module System Managers (MSMs) that autonomously manage each module; and System Managers (SMs) that autonomously manage systems within a module(i.e. ECLSS).A substantially high level of autonomy needs to be achieved by each element of the hierarchy (VSM, MSM, SM)to meet requirements for uncrewed operations; this includes conditions that will have minimal and/or delayed ground intervention (i.e. requirements for sustainability for months of operation without crew or ground support). To advance an implementation of this autonomy design (Gateway Autonomy Design –GAD), a collaboration was established between the Autonomous Systems Laboratory (ASL) at NASA Stennis Space Center and Lockheed Martin. The objectives of this partnership were the following: (1)to implement autonomy at the VSM, MSM, and SM levels;(2) to implement communications among a VSM, 2 MSMs, ORION (a visiting vehicle somewhat equivalent to a module) and 1 SM (a power system), and (3) test autonomous operations with representative use cases. A SM backed by a high-fidelity simulation was created to facilitate demonstrations of use cases that originated in a system of a module. Communication between the VSM and MSMs was implemented according to Concepts of Operations and Interface Control Documents (ICDs). Demonstrations were conducted to address nominal and off-nominal operations and multi-module interactions with VSM. Additionally, user interfaces were created to provide awareness about ongoing processes and results while enhancing the demonstration. Demonstrations included the following use cases: (1)Orion as visiting vehicle registers with VSM;(2) VSM reschedules a module’s timelines when another module’s MSM task fails; and (3) a module’s Power System Manager (PSM) standalone demonstration that included component failure diagnostics, tracing component failure to effected components, which in turn, reports failure information up to the VSM for acknowledgement and display. This paper will describe the detailed technology and autonomous systems developed, and the integrated multi-module demonstrations conducted. Also, challenges that must be met to fully implement the GAD defined by Gateway will be addressed.

Autonomous Systems↗

NASA NTRSDate not supplied

Risk-Reduction Autonomy Implementation to Enable NASA Artemis Missions

To achieve NASA’s Artemis program mission objectives a high level of autonomy that is ubiquitous throughout the systems that are being developed will be necessary. The autonomous systems of Artemis will require a distributed autonomy capability, with autonomous systems organized functionally in a hierarchical architecture, where systems at higher levels of the hierarchy have authority over systems at lower levels. The challenge of developing autonomy technologies and Concepts of Operations (ConOps) for Artemis has been undertaken by the NASA Gateway Working Group. This group has developed requirements, architectures, ConOps, and interface control documents (ICDs), in the context of a hierarchical distributed architecture that includes the following: a Vehicle System Manager (VSM) that autonomously manages the entire Gateway; Module System Managers (MSMs) that autonomously manage each module; and System Managers (SMs) that autonomously manage systems within a module (i.e. ECLSS). A substantially high level of autonomy needs to be achieved by each element of the hierarchy (VSM, MSM, SM) to meet requirements for uncrewed operations; this includes conditions that will have minimal and/or delayed ground intervention (i.e. requirements for sustainability for months of operation without crew or ground support). To advance an implementation of this autonomy design (Gateway Autonomy Design – GAD), a collaboration was established between the Autonomous Systems Laboratory (ASL) at NASA Stennis Space Center and Lockheed Martin. The objectives of this partnership were the following: (1) to implement autonomy at the VSM, MSM, and SM levels; (2) to implement communications among a VSM, 2 MSMs, ORION (a visiting vehicle somewhat equivalent to a module) and 1 SM (a power system), and (3) test autonomous operations with representative use cases. A SM backed by a high-fidelity simulation was created to facilitate demonstrations of use cases that originated in a system of a module. Communication between the VSM and MSMs was implemented according to Concepts of Operations and Interface Control Documents (ICDs). Demonstrations were conducted to address nominal and off-nominal operations and multi-module interactions with the VSM. Additionally, user interfaces were created to provide awareness about ongoing processes and results while enhancing the demonstration. Demonstrations included the following use cases: (1) Orion as visiting vehicle registers with VSM; (2) VSM reschedules a module’s timelines when another module’s MSM task fails; and (3) a module’s Power System Manager (PSM) demonstration that included component failure diagnostics, tracing component failure to effected components, which in turn, reports failure information up to the VSM for acknowledgement and display. This paper will describe the detailed technology and autonomous systems developed, and the integrated multi-module demonstrations conducted. Also, challenges that must be met to fully implement the GAD defined by Gateway will be addressed.

Fernando Figueroa↗