Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “implementation decisions”

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 505 records · Page 28
All sourcesNASA NTRSDOE OSTI
NASA NTRS2007

Panel Resource Management (PRM) Implementation and Effects within Safety Review Panel Settings and Dynamics

While technical training and advanced degree's assure proficiency at specific tasks within engineering disciplines, they fail to address the potential for communication breakdown and decision making errors familiar to multicultural environments where language barriers, intimidating personalities and interdisciplinary misconceptions exist. In an effort to minimize these pitfalls to effective panel review, NASA's lead safety engineers to the ISS Safety Review Panel (SRP), and Payload Safety Review Panel (PSRP) initiated training with their engineers, in conjunction with the panel chairs, and began a Panel Resource Management (PRM) program. The intent of this program focuses on the ability to reduce the barriers inhibiting effective participation from all panel attendees by bolstering participants confidence levels through increased communication skills, situational awareness, debriefing, and a better technical understanding of requirements and systems.

Taylor, Robert W.↗
NASA NTRS1998

Interfacing with Legacy using Remote Method Invocation

The assignment described was enough to make a neophyte Java developer bolt for the door: provide a remote method for use by an applet which invokes a native method that wraps a function in an existing legacy library. The purpose of the remote method is to return an instance of a class object whose contents reflect the data structure returned by the legacy function. While embroiled in implementation, I would have spent the time wading through their JNI use group archive as well, but I couldn't seem to locate one. Subsequently, I made the decision to try to document my findings in order to assist others. Before we start on the class design, let's look at what the existing legacy code does. The C function to be called, Get-Legacy-Data, consists of two steps: an ASII file is read from the local disk and its contents are parsed into a Legacy_Type structure whose address is passed as an argument by the caller. The legacy code was compiled into a shared object library, legacy. so, using the IRIX 6.2 compiler and then loaded onto the Web server, a Silicon Graphics Indy station loaded with the IRIX 6.4 operating system. As far as the class design is concerned, the first thing required is a class to act as a template for the data structure returned by the legacy function. This class, JLegacy, declares a series of public instance variables which correspond to the members of Legacy_Type and provides a parameterless constructor. This constructor is never called, not even by the native method which allocates the object for return to the remote method. Next, the remote interface declaration for the remote object must be defined. In order for JLegacyRO to implement getJLegacy, JLegacyRO must interface with the existing legacy code through a native method, getn. getn is declared in the JLegacyRO class but implemented in C, just like the legacy code. getn returns a JLegacy instance and is declared static since its implementation is the same for all instances of the JLegacyRO class.

Howard, Scott M.↗
NASA NTRS1998

Trellises and Trellis-Based Decoding Algorithms for Linear Block Codes: An Iterative Decoding Algorithm for Linear Block Codes Based on a Low-Weight Trellis Search - Part 3

For long linear block codes, maximum likelihood decoding based on full code trellises would be very hard to implement if not impossible. In this case, we may wish to trade error performance for the reduction in decoding complexity. Sub-optimum soft-decision decoding of a linear block code based on a low-weight sub-trellis can be devised to provide an effective trade-off between error performance and decoding complexity. This chapter presents such a suboptimal decoding algorithm for linear block codes. This decoding algorithm is iterative in nature and based on an optimality test. It has the following important features: (1) a simple method to generate a sequence of candidate code-words, one at a time, for test; (2) a sufficient condition for testing a candidate code-word for optimality; and (3) a low-weight sub-trellis search for finding the most likely (ML) code-word.

Lin, Shu↗
NASA NTRS2005

Trusted Autonomy for Space Flight Systems

NASA has long supported research on intelligent control technologies that could allow space systems to operate autonomously or with reduced human supervision. Proposed uses range from automated control of entire space vehicles to mobile robots that assist or substitute for astronauts to vehicle systems such as life support that interact with other systems in complex ways and require constant vigilance. The potential for pervasive use of such technology to extend the kinds of missions that are possible in practice is well understood, as is its potential to radically improve the robustness, safety and productivity of diverse mission systems. Despite its acknowledged potential, intelligent control capabilities are rarely used in space flight systems. Perhaps the most famous example of intelligent control on a spacecraft is the Remote Agent system flown on the Deep Space One mission (1998 - 2001). However, even in this case, the role of the intelligent control element, originally intended to have full control of the spacecraft for the duration of the mission, was reduced to having partial control for a two-week non-critical period. Even this level of mission acceptance was exceptional. In most cases, mission managers consider intelligent control systems an unacceptable source of risk and elect not to fly them. Overall, the technology is not trusted. From the standpoint of those who need to decide whether to incorporate this technology, lack of trust is easy to understand. Intelligent high-level control means allowing software io make decisions that are too complex for conventional software. The decision-making behavior of these systems is often hard to understand and inspect, and thus hard to evaluate. Moreover, such software is typically designed and implemented either as a research product or custom-built for a particular mission. In the former case, software quality is unlikely to be adequate for flight qualification and the functionality provided by the system is likely driven largely by the need to publish innovative work. In the latter case, the mission represents the first use of the system, a risky proposition even for relatively simple software.

Freed, Michael↗
NASA NTRS2016

Considerations for the Next Revision of NASA's Space Telecommunications Radio System Architecture

Development of NASA's Software Defined Radio architecture, the Space Telecommunication Radio System (STRS), was initiated in 2004 with a goal of reducing the cost, risk and schedule when implementing Software Defined Radios (SDR) for National Aeronautics and Space Administration (NASA) space missions. Since STRS was first flown in 2012 on three Software Defined Radios on the Space Communication and Navigation (SCaN) Testbed, only minor changes have been made to the architecture. Multiple entities have since implemented the architecture and provided significant feedback for consideration for the next revision of the standard. The focus for the first set of updates to the architecture is items that enhance application portability. Items that require modifications to existing applications before migrating to the updated architecture will only be considered if there is compelling reasons to make the change. The significant suggestions that were further evaluated for consideration include expanding and clarifying the timing Application Programming Interfaces (APIs), improving handle name and identification (ID) definitions and use, and multiple items related to implementation of STRS Devices. In addition to ideas suggested while implementing STRS, SDR technology has evolved significantly and this impact to the architecture needs to be considered. These include incorporating cognitive concepts - learning from past decisions and making new decisions that the radio can act upon. SDRs are also being developed that do not contain a General Purpose Module - which is currently required for the platform to be STRS compliant. The purpose of this paper is to discuss the comments received, provide a summary of the evaluation considerations, and examine planned dispositions.

transmitters receivers↗
NASA NTRS2016

Considerations for the Next Revision of STRS

Development of NASAs Software Defined Radio architecture, the Space Telecommunication Radio System (STRS), was initiated in 2004 with a goal of reducing the cost, risk and schedule when implementing Software Defined Radios (SDR) for NASA space missions. Since STRS was first flown in 2012 on three Software Defined Radios on the Space Communication and Navigation (SCaN) Testbed, only minor changes have been made to the architecture. Multiple entities have since implemented the architecture and have provided significant feedback for consideration for the next revision of the standard. The focus for the first set of updates to the architecture is items that enhance application portability. Items that require modifications to existing applications before migrating to the updated architecture will only be considered if there is compelling reasons to make the change. The significant suggestions that were further evaluated for consideration include expanding and clarifying the timing Application Programming Interfaces (APIs), improving handle name and identification (ID) definitions and use, and multiple items related to implementation of STRS Devices. In addition to ideas suggested while implementing STRS, SDR technology has evolved significantly and this impact to the architecture needs to be considered. These include incorporating cognitive concepts - learning from past decisions and making new decisions that the radio can act upon. SDRs are also being developed that do not contain a General Purpose Module which is currently required for the platform to be STRS compliant. The purpose of this paper is to discuss the comments received, provide a summary of the evaluation considerations, and examine planned dispositions

waveforms↗
NASA NTRS2020

PACE Technical Report Series, Volume 9: PACE Applications Plan

This volume presents PACE mission’s plan for development and execution of a PACE Applications Program. NASA maintains an Applied Sciences Program (https://appliedsciences.nasa.gov) to help institutions and individuals make better decisions about our environment, food, water, health and safety through the use of NASA data. In 2016, NASA Headquarters began requiring all flight projects to implement a Project Applications Program with the purpose of: (a) scoping and developing applied research and applications as part of the overall mission concept; (b) demonstrating the project’s benefit to society and contributions to the achievement of societal outcomes; (c) identifying specific product applications and Communities of Potential to better understand the impacts and benefit from using project products and models; (d) increasing the utility of data products; and (e) fostering a Community of Practice who can work with the project throughout the emission life cycle. In response to and in support of this NASA Headquarters directive, the PACE mission developed this PACE Applications Program Plan. While consideration of applications and applied sciences has always been embedded into PACE, the Applications Program truly kicked into high gear in December 2019 (see https://pace.gsfc.nasa.gov). At the time of this writing, the number of PACE Early Adopters has already reached 20. And, the first PACE Applications Workshop will be held (virtually) in late September 2020, with 500 attendees registered. My congratulations and thanks to the PACE Applications Program team for a tremendous first year.

Maria Tzortziou↗
NASA NTRSDate not supplied

Preliminary Development of Multi-Vehicle (m:N) Operations with NASA Langley’s Remote Vehicle Operations Center

To achieve the vision of Advanced Air Mobility (AAM), a transition from localized operations of aircraft to remote operations is being pursued across many use cases. This transition will allow fewer human operators to manage more increasingly autonomous aircraft (i.e., m operators managing N vehicles, or m:N). To study this operational concept, the National Aeronautics and Space Administration (NASA) Langley Research Center (LaRC) has developed a prototype remote vehicle operations center and ground control station (GCS) software to conduct research with simulated and real flight operations. To date, flight operations at LaRC have been limited to one vehicle per operator. However, the current paper describes initial development and considerations for enabling m:N flight operations at LaRC. Further, the research described in this paper provides the foundation for a concept of operations (ConOps) that will be developed to support remote operators managing multiple increasingly autonomous vehicles, with the goal of exploring human-autonomy teaming (HAT) concepts that enable more advanced m:N operations. Two key enablers have been identified to facilitate successful m:N operations: GCS software updates for multi-vehicle management and procedural updates for vehicle handoffs during off-nominal events. Additionally, specific modifications were identified across five key areas: technology and software, team structure, inter-team communication, contingency plans, and operator decision flows. Next steps in forming the LaRC m:N ConOps will include working with subject-matter experts to identify off-nominal scenarios, implementing the recommended GCS functionality for m:N operations, and performing integration testing of facility capabilities and new operational procedures. Although the future m:N ConOps will be tailored to the NASA LaRC remote operations facility and flight range, it is intended to be a transparent, accessible, and reality-based exemplar for external organizations seeking to create or evaluate their own m:N operational concepts.

m:N↗
NASA NTRS2024

Decision Space Modeling: Trade Space Ontology

As the National Aeronautics and Space Administration (NASA) works to develop a crewed Moon to Mars Architecture, it is dealing with a large decision space consisting of the overlay of human exploration architectures for both the Moon and for Mars. Efforts are underway to enable reasoning, analysis, and deliberation on this decision space. A critical first step is to develop a model of the decision space, which will then allow for various methods and techniques to be applied in support of the larger architecture decision-making process. The Trade Space Ontology consists of a set of terminologies and relations (an ontology) and a MagicDraw resource that enables documentation of decisions and alternatives. It also provides a means by which decisions and alternatives can be traced to other Systems Engineering artifacts. For documenting alternatives, the Trade Space Ontology adapts the Morphological Matrix methodology to The Systems Modeling Language (SysML) through a profile; custom diagrams are also implemented to simplify the profile's use. With the profile and custom diagrams, system architects can specify options for architecture attributes, as well as compatibility between them, in a compact visual format. While the approach shares similarities to a trade tree, the emphasis at this stage is less on enumerating specific combinations of options and instead on specifying the options and their compatibility. Enumeration of alternatives is performed by an external analysis that operates on an output file from a model constructed using the Trade Space Ontology. For decisions, the Trade Space Ontology provides a way to model generic precedence relationships as well as documenting inputs and outputs. These may include what alternatives, criteria, and rationale are understood to be relevant for each decision. Importantly, the decision-making side of the Trade Space Ontology is defined at a more general level, such that it can be adapted to the specific terms in use by projects and programs at NASA. However, this adaptability also means that less capability is provided ``out-of-the-box'' from installation. Currently the resource includes plugin functionality to enumerate paths through generic precedence relationships between decisions and to export these paths to a spreadsheet. Custom dependency stereotypes are included in the profile to indicate the cross-cutting relationships between the trade space and the architecture decisions, providing a means to map which parts of the trade space enumerate alternatives for a decision, and to identify how the output of a decision may modify the trade space through pruning or down-selection. While the motivating use case for this resource is in human exploration architectures, the broad applicability of the Morphological Matrix methodology indicates that the Trade Space Ontology should also be useful for other activities and tasks at the agency.

Trade Tree↗
NASA NTRS2007

Determining a Method of Enabling and Disabling the Integral Torque in the SDO Science and Inertial Mode Controllers

During design of the SDO Science and Inertial mode PID controllers, the decision was made to disable the integral torque whenever system stability was in question. Three different schemes were developed to determine when to disable or enable the integral torque, and a trade study was performed to determine which scheme to implement. The trade study compared complexity of the control logic, risk of not reenabling the integral gain in time to reject steady-state error, and the amount of integral torque space used. The first scheme calculated a simplified Routh criterion to determine when to disable the integral torque. The second scheme calculates the PD part of the torque and looked to see if that torque would cause actuator saturation. If so, only the PD torque is used. If not, the integral torque is added. Finally, the third scheme compares the attitude and rate errors to limits and disables the integral torque if either of the errors is greater than the limit. Based on the trade study results, the third scheme was selected. Once it was decided when to disable the integral torque, analysis was performed to determine how to disable the integral torque and whether or not to reset the integrator once the integral torque was reenabled. Three ways to disable the integral torque were investigated: zero the input into the integrator, which causes the integral part of the PID control torque to be held constant; zero the integral torque directly but allow the integrator to continue integrating; or zero the integral torque directly and reset the integrator on integral torque reactivation. The analysis looked at complexity of the control logic, slew time plus settling time between each calibration maneuver step, and ability to reject steady-state error. Based on the results of the analysis, the decision was made to zero the input into the integrator without resetting it. Throughout the analysis, a high fidelity simulation was used to test the various implementation methods.

Vess, Melissa F.↗
NASA NTRS1994

SCOS 2: An object oriented software development approach

The Spacecraft Control and Operations System 2 (SCOS 2), is intended to provide the generic mission control system infrastructure for future ESA missions. It represents a bold step forward in order to take advantage of state-of-the-art technology and current practices in the area of software engineering. Key features include: (1) use of object oriented analysis and design techniques; (2) use of UNIX, C++ and a distributed architecture as the enabling implementation technology; (3) goal of re-use for development, maintenance and mission specific software implementation; and (4) introduction of the concept of a spacecraft control model. This paper touches upon some of the traditional beliefs surrounding Object Oriented development and describes their relevance to SCOS 2. It gives rationale for why particular approaches were adopted and others not, and describes the impact of these decisions. The development approach followed is discussed, highlighting the evolutionary nature of the overall process and the iterative nature of the various tasks carried out. The emphasis of this paper is on the process of the development with the following being covered: (1) the three phases of the SCOS 2 project - prototyping & analysis, design & implementation and configuration / delivery of mission specific systems; (2) the close cooperation and continual interaction with the users during the development; (3) the management approach - the split between client staff, industry and some of the required project management activities; (4) the lifecycle adopted being an enhancement of the ESA PSS-05 standard with SCOS 2 specific activities and approaches defined; and (5) an examination of some of the difficulties encountered and the solutions adopted. Finally, the lessons learned from the SCOS 2 experience are highlighted, identifying those issues to be used as feedback into future developments of this nature. This paper does not intend to describe the finished product and its operation, but focusing on the journey to arrive there, concentrating therefore on the process and not the products of the SCOS 2 software development.

Symonds, Martin↗
NASA NTRS1986

Software fault-tolerance by design diversity DEDIX: A tool for experiments

The use of multiple versions of a computer program, independently designed from a common specification, to reduce the effects of an error is discussed. If these versions are designed by independent programming teams, it is expected that a fault in one version will not have the same behavior as any fault in the other versions. Since the errors in the output of the versions are different and uncorrelated, it is possible to run the versions concurrently, cross-check their results at prespecified points, and mask errors. A DEsign DIversity eXperiments (DEDIX) testbed was implemented to study the influence of common mode errors which can result in a failure of the entire system. The layered design of DEDIX and its decision algorithm are described.

Avizienis, A.↗
NASA NTRS1990

Large-Constraint-Length, Fast Viterbi Decoder

Scheme for efficient interconnection makes VLSI design feasible. Concept for fast Viterbi decoder provides for processing of convolutional codes of constraint length K up to 15 and rates of 1/2 to 1/6. Fully parallel (but bit-serial) architecture developed for decoder of K = 7 implemented in single dedicated VLSI circuit chip. Contains six major functional blocks. VLSI circuits perform branch metric computations, add-compare-select operations, and then store decisions in traceback memory. Traceback processor reads appropriate memory locations and puts out decoded bits. Used as building block for decoders of larger K.

Collins, O.↗
NASA NTRS1990

JESNET Expert Assistant

The Johnson Space Center Engineering and Science Network (JESNET) supports the JSC Engineering and Space and Life Sciences Directorates by providing a network of interconnected ETHERNETS with a wide diversity of processing and routing nodes throughout the Johnson Space Center and off-site contractor locations. The JESNET provides the primary method of communication between the various computers that support the Directorates. Lockheed Engineering and Sciences Co. (LESC) is tasked with the operation and maintenance of certain primary portions of this network. Since maintenance of this network depends on the timely identification and subsequent repair of problems on the network, the decision was made to develop a JESNET Expert Assistant (JEA) to assist LESC personnel in the operation and maintenance of the JESNET. The JEA is being implemented in CLIPS, DEC Graphical Kernal System (GKS(TM)) and C on a DEC MicroVAX(TM) with VMS(TM).

Hansen, Roger F.↗
NASA NTRS1999

Measuring Tropospheric Winds from Space Using a Coherent Doppler Lidar Technique

The global measurement of tropospheric wind profiles has been cited by the operational meteorological community as the most important missing element in the present and planned observing system. The most practical and economical method for obtaining this measurement is from low earth orbit, utilizing a Doppler lidar (laser radar) technique. Specifically, this paper will describe the coherent Doppler wind lidar (CDWL) technique, the design and progress of a current space flight project to fly such a system on the Space Shuttle, and plans for future flights of similar instruments. The SPARCLE (SPAce Readiness Coherent Lidar Experiment) is a Shuttle-based instrument whose flight is targeted for March, 2001. The objectives of SPARCLE are three-fold: Confirm that the coherent Doppler lidar technique can measure line-of-sight winds to within 1-2 m/s accuracy; Collect data to permit validation and improvement of instrument performance models to enable better design of future missions; and Collect wind and backscatter data for future mission optimization and for atmospheric studies. These objectives reflect the nature of the experiment and its program sponsor, NASA's New Millennium Program. The experiment is a technology validation mission whose primary purpose is to provide a space flight validation of this particular technology. (It should be noted that the CDWL technique has successfully been implemented from ground-based and aircraft-based platforms for a number of years.) Since the conduct of the SPARCLE mission is tied to future decisions on the choice of technology for free-flying, operational missions, the collection of data is intrinsically tied to the validation and improvement of instrument performance models that predict the sensitivity and accuracy of any particular present or future instrument system. The challenges unique to space flight for an instrument such as SPARCLE and follow-ons include: Obtaining the required lidar sensitivity from the long distance of orbit height to the lower atmosphere; Maintaining optical alignments after launch to orbit, and during operations in "microgravity"; Obtaining pointing knowledge of sufficient accuracy to remove the speed of the spacecraft (and the rotating Earth) from the measurements; Providing sufficient power (not a problem on the Shuttle) and cooling to the instrument. The paper will describe the status and challenges of the SPARCLE project, the value of obtaining wind data from orbit, and will present a roadmap to future instruments for scientific research and operational meteorology.

Miller, Timothy L.↗
NASA NTRS1999

HEDS Goals

In November of 1996, NASA made the decision to fully integrate several areas of robotic and human Mars exploration study and planning. As a result of this decision, requirements for unmanned robotic missions to support human Mars exploration were identified and a plan to meet these requirements was developed. Concrete progress in the implementation of this plan has been made. Three experiments have been selected and are in development for the Mars Surveyor Program 2001 Orbiter and Lander missions which will provide critical data for the planning of human missions to Mars. An Announcement of Opportunity for the Mars Surveyor Program 2003 Lander mission has recently been released which solicited proposals related to planning for a human mission. In order to define HEDS objectives for Mars robotic missions, it is important to understand what information is required as a foundation for mounting a program of exploration of this magnitude. We identify areas of research on robotic missions that will enable future human missions. These areas include Site Selection for Human Missions, Hazards to Human Explorers, Living off the Land, and Testing Critical Technologies in the Mars Environment.

Pline, A.↗
NASA NTRS1990

A Concurrent Distributed System for Aircraft Tactical Decision Generation

A research program investigating the use of artificial intelligence (AI) techniques to aid in the development of a Tactical Decision Generator (TDG) for Within Visual Range (WVR) air combat engagements is discussed. The application of AI programming and problem solving methods in the development and implementation of a concurrent version of the Computerized Logic For Air-to-Air Warfare Simulations (CLAWS) program, a second generation TDG, is presented. Concurrent computing environments and programming approaches are discussed and the design and performance of a prototype concurrent TDG system are presented.

McManus, John W.↗