Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “execution architecture”

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 415 records · Page 23
All sourcesNASA NTRSDOE OSTI
NASA NTRS2019

James Webb Space Telescope Optical Telescope Element / Integrated Science Instrument Module (OTIS) Cryogenic Vacuum Test Part II: Thermal Analysis

The James Webb Space Telescope (JWST), set to launch in early 2019, is currently undergoing a series of system-level environmental tests to verify its workmanship and end-to-end functionality. As part of this series, the Optical Telescope Element and Integrated Science Instrument Module (OTIS) Cryo-Vacuum (CV) test, the most complex cryogenic test executed to date by NASA, was completed in 2017 at the Johnson Space Center's Chamber A facility. The OTIS CV test was intended as a comprehensive test of the integrated instrument and telescope systems to fully understand its optical, structural, and thermal performance within its intended flight environment. Due to its complexity, extensive pre-test planning was required to ensure payload safety and compliance with all limits and constraints. A comprehensive thermal analysis campaign was undertaken to predict the behavior of the test payload during its transition to cryogenic temperatures and back to ambient, and exhaustive preparations for off-nominal scenarios were studied due to the increased possibility of unanticipated events during the 100-day test length. This current four-part online course for the NASA Engineering and Safety Center (NESC) Academy gives a thorough overview of the multiple years of preparation executed by hundreds of individuals to ensure the success of the JWST OTIS CV Test. Part I will introduce the major components of James Webb and specifically the OTIS CV Test thermal architecture. Part II will encompass the extensive thermal analysis performed to prepare for the test. Part III will talk about the preparations for off-nominal events: what analysis was done, and how steps were taken pre-test to anticipate unexpected circumstances and mitigate their impacts to hardware and test timeline. Part IV is a recap of the lessons learned from the thermal perspective for both the payload and ground support equipment (GSE) test conductors. It is hoped that the insight gained from the OTIS CV test campaign will benefit planning and execution for upcoming large cryogenic missions.

Testing↗
NASA NTRS1991

Requirements analysis notebook for the flight data systems definition in the Real-Time Systems Engineering Laboratory (RSEL)

A hybrid requirements analysis methodology was developed, based on the practices actually used in developing a Space Generic Open Avionics Architecture. During the development of this avionics architecture, a method of analysis able to effectively define the requirements for this space avionics architecture was developed. In this methodology, external interfaces and relationships are defined, a static analysis resulting in a static avionics model was developed, operating concepts for simulating the requirements were put together, and a dynamic analysis of the execution needs for the dynamic model operation was planned. The systems engineering approach was used to perform a top down modified structured analysis of a generic space avionics system and to convert actual program results into generic requirements. CASE tools were used to model the analyzed system and automatically generate specifications describing the model's requirements. Lessons learned in the use of CASE tools, the architecture, and the design of the Space Generic Avionics model were established, and a methodology notebook was prepared for NASA. The weaknesses of standard real-time methodologies for practicing systems engineering, such as Structured Analysis and Object Oriented Analysis, were identified.

Wray, Richard B.↗
NASA NTRS1991

Architecture For Intelligent Control Of Robotic Tasks

Proposed architecture for control of such robotic devices as artificial hands calls for data-abstracting hierarchies of processing, controlling, and sensing equipment that plans, executes, and corrects movements of devices at acceptably high rates. Combines features developed in research on artificial intelligence and control theory. Characterized by casual connections between layers of hierarchy, approximately equal complexities of layers, and directed focus of attention.

Fiorini, Paolo↗
NASA NTRS1992

Electrostatic Particle-In-Cell Code For Hypercube Computer

Code simulates two-dimensional motions of plasma particles in self-consistent electrostatic field and externally applied magnetic field developed for execution on Mark IIIfp hypercube computer. Based on generalization of one-dimensional particle-in-cell algorithm applicable to many different parallel computing architectures. Intermediate product of continuing effort to speed particle-in-cell computations by taking advantage of distributed-memory parallel computers like those of hypercube class.

Ferraro, Robert D.↗
NASA NTRSDate not supplied

Initial Validation of a Simulation System for Studying Interoperability in Future Air Traffic Management Systems

Future air traffic management systems will need to accommodate large numbers of increasingly diverse air vehicles with different operating paradigms. To support this trend, they will digitally share copious amounts of information via a common communication architecture. Operators will deploy programs that create and negotiate flight plans via the architecture’s communication protocols. These programs will autonomously make decisions that must be arbitrated by the architecture and robust to uncertainty. To study interoperability in air traffic management, a new airspace simulation system was composed by integrating a legacy airspace simulation, an air traffic control model, and a new research communication architecture. It was used to evaluate air traffic management concepts by adapting it to handle congested arrival traffic at Newark Liberty International Airport and executing simulations. Results demonstrated the ability of the simulation system to model in detail strategic traffic flow management, predeparture flight planning, and air traffic control working in concert. Subsequent studies can use the simulation system to study interoperability, autonomy, digital communication, and uncertainty in future air traffic management systems.

aircraft scheduling,traffic flow management,autono↗
NASA NTRSDate not supplied

Initial Validation of a Simulation System for Studying Interoperability in Future Air Traffic Management Systems

Future air traffic management systems will need to accommodate large numbers of increasingly diverse air vehicles with different operating paradigms. To support this trend, they will digitally share copious amounts of information via a common communication architecture. Operators will deploy programs that create and negotiate flight plans via the architecture’s communication protocols. These programs will autonomously make decisions that must be arbitrated by the architecture and robust to uncertainty. To study interoperability in air traffic management, a new airspace simulation system was composed by integrating a legacy airspace simulation, an air traffic control model, and a new research communication architecture. It was used to evaluate air traffic management concepts by adapting it to handle congested arrival traffic at Newark Liberty International Airport and executing simulations. Results demonstrated the ability of the simulation system to model in detail strategic traffic flow management, predeparture flight planning, and air traffic control working in concert. Subsequent studies can use the simulation system to study interoperability, autonomy, digital communication, and uncertainty in future air traffic management systems.

air traffic control↗
NASA NTRS2021

Initial Validation of a Simulation System for Studying Interoperability in Future Air Traffic Management Systems

Future air traffic management systems will need to accommodate large numbers of increasingly diverse air vehicles with different operating paradigms. To support this trend, they will digitally share copious amounts of information via a common communication architecture. Operators will deploy programs that create and negotiate flight plans via the architecture’s communication protocols. These programs will autonomously make decisions that must be arbitrated by the architecture and robust to uncertainty. To study interoperability in air traffic management, a new airspace simulation system was composed by integrating a legacy airspace simulation, an air traffic control model, and a new research communication architecture. It was used to evaluate air traffic management concepts by adapting it to handle congested arrival traffic at Newark Liberty International Airport and executing simulations. Results demonstrated the ability of the simulation system to model in detail strategic traffic flow management, predeparture flight planning, and air traffic control working in concert. Subsequent studies can use the simulation system to study interoperability, autonomy, digital communication, and uncertainty in future air traffic management systems.

air traffic control↗
NASA NTRSDate not supplied

Updated Human Mars Ascent Vehicle Concept in Support of NASA’s Strategic Analysis Cycle 2021

The NASA Artemis program has brought significant change to the agency’s human exploration strategy over the last several years. The human exploration of Mars remains an ultimate objective of the overall human exploration strategy. However, how the agency intends to execute initial human exploration of Mars has shifted to better align with current policy. These changes find their way into the design of key architecture elements, such as the Mars Ascent Vehicle (MAV). Of the numerous changes in the conceptual human Mars architecture, two in particular have had significant impact on the design of the human MAV: the desire for minimal surface infrastructure for initial human Mars missions, and technology investment timelines in support of initial human missions to Mars. The first leads to a surface mission architecture targeting a 30-day surface duration with two crewmembers. The second drives out in-situ resource utilization (ISRU) from the initial sortie. As a result, the reference MAV design for initial human Mars missions in the Human Exploration and Operations Mission Directorate’s Strategic Analysis Cycle 2021 (SAC21) is based around supporting the return of 2 crew from the surface of Mars, without surface ISRU. This has led to several design changes since 2019, when details of a reference human MAV were last published. The MAV concept for SAC21 consists of a two-stage vehicle capable of supporting two crew for 84 hours. This duration is derived from a baseline ascent trajectory targeting an apoapsis rendezvous with the habitation element in a nominal 5-sol Mars aggregation orbit. With the goal of minimizing technology investments for the initial surface sortie removing ISRU from the trade space, the MAV must now be landed either fully loaded with propellant, or with some portion of the propellant off-loaded. Landing a partially-fueled MAV will require additional surface assets to perform robotic propellant transfer on the surface of Mars from a pre-emplaced propellant depot. Furthermore, cryogenic fluid management and storage for extended duration with no losses represents additional technology investment that would have to be made to support cryogenic-based propellant concepts that have been the baseline in past architectures. As a result, the SAC21 architecture utilizes a storable propellant-based MAV propulsion system to minimize these potential technology investments incurred by cryogenic-based propulsion systems. Recent efforts also focused on evaluating the sensitivity of key design parameters, such as landing site latitude, elevation, and local atmospheric conditions. All play a large role in determining the predicted propellant requirements of the MAV. Understanding their potential impacts is important because of the rippling effects of changes to the MAV design on other architecture elements, such as entry, descent, landing, and transportation systems. Results indicate up to +2% to -4% wet mass variation due to landing site latitude, with higher latitudes greater than 70 degrees North resulting in greater than 6% wet mass increases. The MAV saw reduced impact due to atmospheric design parameters, which only accounting for -0.6% to +0.4% wet mass variation.

Douglas J. Trent↗
NASA NTRS1991

Extensions to the Parallel Real-Time Artificial Intelligence System (PRAIS) for fault-tolerant heterogeneous cycle-stealing reasoning

Extensions to an architecture for real-time, distributed (parallel) knowledge-based systems called the Parallel Real-time Artificial Intelligence System (PRAIS) are discussed. PRAIS strives for transparently parallelizing production (rule-based) systems, even under real-time constraints. PRAIS accomplished these goals (presented at the first annual C Language Integrated Production System (CLIPS) conference) by incorporating a dynamic task scheduler, operating system extensions for fact handling, and message-passing among multiple copies of CLIPS executing on a virtual blackboard. This distributed knowledge-based system tool uses the portability of CLIPS and common message-passing protocols to operate over a heterogeneous network of processors. Results using the original PRAIS architecture over a network of Sun 3's, Sun 4's and VAX's are presented. Mechanisms using the producer-consumer model to extend the architecture for fault-tolerance and distributed truth maintenance initiation are also discussed.

Goldstein, David↗
NASA NTRS1976

Hardware additions to microprocessor architecture aid software development

An address trap (breakpoint) mechanism and last-in-first-out (LIFO) address stack are suggested as two additions to the basic microprocessor architecture whose functions are solely to aid the programmer. These devices provide the programmer with the ability to specify address breakpoints and to trace program execution back through N instructions, where N is the depth of the stack. Both devices, plus interface logic and buffering, have been designed for an INTEL 8080-based system using approximately 25 integrated-circuit packages.

Sievers, M. W.↗
NASA NTRS1987

Phase space simulation of collisionless stellar systems on the massively parallel processor

A numerical technique for solving the collisionless Boltzmann equation describing the time evolution of a self gravitating fluid in phase space was implemented on the Massively Parallel Processor (MPP). The code performs calculations for a two dimensional phase space grid (with one space and one velocity dimension). Some results from calculations are presented. The execution speed of the code is comparable to the speed of a single processor of a Cray-XMP. Advantages and disadvantages of the MPP architecture for this type of problem are discussed. The nearest neighbor connectivity of the MPP array does not pose a significant obstacle. Future MPP-like machines should have much more local memory and easier access to staging memory and disks in order to be effective for this type of problem.

White, Richard L.↗
NASA NTRS2003

Using SPEEDES to simulate the blue gene interconnect network

JPL and the Center for Advanced Computer Architecture (CACR) is conducting application and simulation analyses of BG/L in order to establish a range of effectiveness for the Blue Gene/L MPP architecture in performing important classes of computations and to determine the design sensitivity of the global interconnect network in support of real world ASCI application execution.

SPEEDES BlueGene/L BG/L system-on-a-chip↗
NASA NTRS2011

CoNNeCT Baseband Processor Module

A document describes the CoNNeCT Baseband Processor Module (BPM) based on an updated processor, memory technology, and field-programmable gate arrays (FPGAs). The BPM was developed from a requirement to provide sufficient computing power and memory storage to conduct experiments for a Software Defined Radio (SDR) to be implemented. The flight SDR uses the AT697 SPARC processor with on-chip data and instruction cache. The non-volatile memory has been increased from a 20-Mbit EEPROM (electrically erasable programmable read only memory) to a 4-Gbit Flash, managed by the RTAX2000 Housekeeper, allowing more programs and FPGA bit-files to be stored. The volatile memory has been increased from a 20-Mbit SRAM (static random access memory) to a 1.25-Gbit SDRAM (synchronous dynamic random access memory), providing additional memory space for more complex operating systems and programs to be executed on the SPARC. All memory is EDAC (error detection and correction) protected, while the SPARC processor implements fault protection via TMR (triple modular redundancy) architecture. Further capability over prior BPM designs includes the addition of a second FPGA to implement features beyond the resources of a single FPGA. Both FPGAs are implemented with Xilinx Virtex-II and are interconnected by a 96-bit bus to facilitate data exchange. Dedicated 1.25- Gbit SDRAMs are wired to each Xilinx FPGA to accommodate high rate data buffering for SDR applications as well as independent SpaceWire interfaces. The RTAX2000 manages scrub and configuration of each Xilinx.

Yamamoto, Clifford K↗
NASA NTRS2015

Finalizing the CCSDS Space-Data Link Layer Security Protocol: Setup and Execution of the Interoperability Testing

The protection of data transmitted over the space-link is an issue of growing importance also for civilian space missions. Through the Consultative Committee for Space Data Systems (CCSDS), space agencies have reacted to this need by specifying the Space Data-Link Layer Security (SDLS) protocol which provides confidentiality and integrity services for the CCSDS Telemetry (TM), Telecommand (TC) and Advanced Orbiting Services (AOS) space data-link protocols. This paper describes the approach of the CCSDS SDLS working group to specify and execute the necessary interoperability tests. It first details the individual SDLS implementations that have been produced by ESA, NASA, and CNES and then the overall architecture that allows the interoperability tests between them. The paper reports on the results of the interoperability tests and identifies relevant aspects for the evolution of the test environment.

Fischer, Daniel↗
NASA NTRS2010

AutoGNC Testbed

A simulation testbed architecture was developed and implemented for the integration, test, and development of a TRL-6 flight software set called Auto- GNC. The AutoGNC software will combine the TRL-9 Deep Impact AutoNAV flight software suite, the TRL-9 Virtual Machine Language (VML) executive, and the TRL-3 G-REX guidance, estimation, and control algorithms. The Auto- GNC testbed was architected to provide software interface connections among the AutoNAV and VML flight code written in C, the G-REX algorithms in MATLAB and C, stand-alone image rendering algorithms in C, and other Fortran algorithms, such as the OBIRON landmark tracking suite. The testbed architecture incorporates software components for propagating a high-fidelity truth model of the environment and the spacecraft dynamics, along with the flight software components for onboard guidance, navigation, and control (GN&C). The interface allows for the rapid integration and testing of new algorithms prior to development of the C code for implementation in flight software. This testbed is designed to test autonomous spacecraft proximity operations around small celestial bodies, moons, or other spacecraft. The software is baselined for upcoming comet and asteroid sample return missions. This architecture and testbed will provide a direct improvement upon the onboard flight software utilized for missions such as Deep Impact, Stardust, and Deep Space 1.

Carson, John M., III↗
NASA NTRS2022

The Cooling Loop A Anomaly of 2013: A Case Study in Human-Systems Resilience

Throughout the history of human spaceflight, NASA has employed an operational paradigm of 24/7 dependence on experts in Mission Control Center (MCC). In addition to nominal flight control and mission operations, these 85+ experts per shift manage anomaly detection, diagnosis, and response, and support the crew in real-time in performing maintenance and repair, procedure execution, and other complex mission operations. Future long-duration exploration missions (LDEMs) beyond low-Earth orbit (LEO) will not operate successfully using this same Human-Systems Integration Architecture (HSIA) where crew rely on ground controllers, have ready access to resupply, and have a fallback plan of evacuation. As distance from Earth increases and the communication delay grows, crews will need to respond independently and adequately to time-critical vehicle malfunctions. It will not always be sufficient or even possible to ‘safe the system’ and then wait upon ground intervention. A new and radically different HSIA is needed to accommodate the paradigm shift of deep-space travel. Historical International Space Station (ISS) data show that for a 30-day mission, the likelihood of a high-consequence vehicle anomaly of uncertain origin that requires rapid response is greater than 10%. The likelihood of such an event is 50% by the fourth month of the mission, and it grows exponentially with time. Our team has conducted in-depth investigations into these events and their corresponding anomaly resolution activities. Using MCC and Mission Evaluation Room (MER) anomaly resolution artifacts (including meeting summaries, caution and warning data, and ISS daily summaries), we created timelines detailing ground actions and in-orbit events for two significant anomalies. We then mapped these timelines onto Mars transit conditions, introducing a ground-crew communications time delay and shifting immediate response, time-critical task execution, and vehicle commanding to the crew. In detailing successful anomaly resolution in transit to Mars, the timelines highlight where effective resolution requires drastically evolved onboard capabilities. Though this research has yielded a rich data set based on ground response in past missions, there is still insufficient knowledge to assess the potential impact of inflight anomalies on a small autonomous crew on future LDEMs beyond LEO. To begin building an evidence base that will inform future HSIA standards and requirements, we are developing an approach to systematically capture crew anomaly response and procedure execution during early Artemis missions. Being the first human spaceflight beyond LEO since Apollo, early Artemis missions provide a rare and unique opportunity to serve as a testbed for Mars missions. Our work aims to capitalize on planned data collection to derive crew operational responses to anomalous events in real-time. Our team is also researching the level of simulation fidelity required for empirically validating proposed HSIA standards and evaluating HSIA implementations for LDEMs beyond LEO. This work will produce a trade space study of HSIA simulation objectives and fidelity requirements. Ultimately, these research efforts will assist in developing the standards and technologies needed to build a next-generation HSIA for LDEMs beyond LEO.

human-systems integration architecture↗
NASA NTRS2017

Reconfigurable Model Execution in the OpenMDAO Framework

NASA's OpenMDAO framework facilitates constructing complex models and computing their derivatives for multidisciplinary design optimization. Decomposing a model into components that follow a prescribed interface enables OpenMDAO to assemble multidisciplinary derivatives from the component derivatives using what amounts to the adjoint method, direct method, chain rule, global sensitivity equations, or any combination thereof, using the MAUD architecture. OpenMDAO also handles the distribution of processors among the disciplines by hierarchically grouping the components, and it automates the data transfer between components that are on different processors. These features have made OpenMDAO useful for applications in aircraft design, satellite design, wind turbine design, and aircraft engine design, among others. This paper presents new algorithms for OpenMDAO that enable reconfigurable model execution. This concept refers to dynamically changing, during execution, one or more of: the variable sizes, solution algorithm, parallel load balancing, or set of variables-i.e., adding and removing components, perhaps to switch to a higher-fidelity sub-model. Any component can reconfigure at any point, even when running in parallel with other components, and the reconfiguration algorithm presented here performs the synchronized updates to all other components that are affected. A reconfigurable software framework for multidisciplinary design optimization enables new adaptive solvers, adaptive parallelization, and new applications such as gradient-based optimization with overset flow solvers and adaptive mesh refinement. Benchmarking results demonstrate the time savings for reconfiguration compared to setting up the model again from scratch, which can be significant in large-scale problems. Additionally, the new reconfigurability feature is applied to a mission profile optimization problem for commercial aircraft where both the parametrization of the mission profile and the time discretization are adaptively refined, resulting in computational savings of roughly 10% and the elimination of oscillations in the optimized altitude profile.

Hwang, John T.↗
NASA NTRS2011

Framework for Integrating Science Data Processing Algorithms Into Process Control Systems

A software framework called PCS Task Wrapper is responsible for standardizing the setup, process initiation, execution, and file management tasks surrounding the execution of science data algorithms, which are referred to by NASA as Product Generation Executives (PGEs). PGEs codify a scientific algorithm, some step in the overall scientific process involved in a mission science workflow. The PCS Task Wrapper provides a stable operating environment to the underlying PGE during its execution lifecycle. If the PGE requires a file, or metadata regarding the file, the PCS Task Wrapper is responsible for delivering that information to the PGE in a manner that meets its requirements. If the PGE requires knowledge of upstream or downstream PGEs in a sequence of executions, that information is also made available. Finally, if information regarding disk space, or node information such as CPU availability, etc., is required, the PCS Task Wrapper provides this information to the underlying PGE. After this information is collected, the PGE is executed, and its output Product file and Metadata generation is managed via the PCS Task Wrapper framework. The innovation is responsible for marshalling output Products and Metadata back to a PCS File Management component for use in downstream data processing and pedigree. In support of this, the PCS Task Wrapper leverages the PCS Crawler Framework to ingest (during pipeline processing) the output Product files and Metadata produced by the PGE. The architectural components of the PCS Task Wrapper framework include PGE Task Instance, PGE Config File Builder, Config File Property Adder, Science PGE Config File Writer, and PCS Met file Writer. This innovative framework is really the unifying bridge between the execution of a step in the overall processing pipeline, and the available PCS component services as well as the information that they collectively manage.

Mattmann, Chris A.↗