Search NASA⌕ Search

SEARCH · Search NASA

Results for “Emerging 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 19 records
All sourcesNASA NTRSDOE OSTI
NASA NTRSDate not supplied

Performance and Portability of a Linear Solver Across Emerging Architectures

A linear solver algorithm used by a large-scale unstructured-grid computational fluid dynamics application is examined for a broad range of familiar and emerging architectures. Efficient implementation of a linear solver is challenging on recent CPUs offering vector architectures. Vector loads and stores are essential to effectively utilize available memory bandwidth on CPUs, and maintaining performance across different CPUs can be difficult in the face of varying vector lengths offered by each. A similar challenge occurs on GPU architectures, where it is essential to have coalesced memory accesses to utilize memory bandwidth effectively. In this work, we demonstrate that restructuring a computation, and possibly data layout, with regard to architecture is essential to achieve optimal performance by establishing a performance benchmark for each target architecture in a low level language such as vector intrinsics or CUDA. In doing so, we demonstrate how a linear solver kernel can be mapped to Intel® Xeon™ and Xeon Phi™, Marvell® ThunderX2®, NEC® SX-Aurora™ TSUBASA Vector Engine, and NVIDIA® and AMD® GPUs. We further demonstrate that the required code restructuring can be achieved in higher level programming environments such as OpenACC, OCCA, and Intel® OneAPI™/SYCL, and that each generally results in optimal performance on the target architecture. Relative performance metrics for all implementations are shown, and subjective ratings for ease of implementation and optimization are suggested.

Programming models↗
NASA NTRS2011

A Risk Management Architecture for Emergency Integrated Aircraft Control

Enhanced engine operation--operation that is beyond normal limits--has the potential to improve the adaptability and safety of aircraft in emergency situations. Intelligent use of enhanced engine operation to improve the handling qualities of the aircraft requires sophisticated risk estimation techniques and a risk management system that spans the flight and propulsion controllers. In this paper, an architecture that weighs the risks of the emergency and of possible engine performance enhancements to reduce overall risk to the aircraft is described. Two examples of emergency situations are presented to demonstrate the interaction between the flight and propulsion controllers to facilitate the enhanced operation.

McGlynn, Gregory E.↗
NASA NTRSDate not supplied

Impact of Emerging Computing Architectures and Opportunities for Process Systems Engineering Applications

Moore’s “law” was the observation that the number of transistors in an integrated circuit doubled approximately every two years. This trend has distinctly failed to hold in recent years. The death of Moore’s law has left researchers and practitioners in the computational sciences searching for technologies to provide the speedups formerly supported by Moore’s law. Previously overlooked chip architectures and other computing technologies are now receiving more development resources. Critically, these technologies are gaining more mature software support, opening their adoption by researchers in algorithms and applications. In this article, we review some of these computing technologies, their relationship with various algorithms and applications, and their potential benefits (or pitfalls). We close with recommendations for future work by the process systems engineering community specifically.

Emerging hardware↗
NASA NTRS2011

Jupiter Europa Orbiter Architecture Definition Process

The proposed Jupiter Europa Orbiter mission, planned for launch in 2020, is using a new architectural process and framework tool to drive its model-based systems engineering effort. The process focuses on getting the architecture right before writing requirements and developing a point design. A new architecture framework tool provides for the structured entry and retrieval of architecture artifacts based on an emerging architecture meta-model. This paper describes the relationships among these artifacts and how they are used in the systems engineering effort. Some early lessons learned are discussed.

requirements analysis↗
NASA NTRSDate not supplied

Zero-Trust Architecture for Autonomous Edge Computing

We are at the apex of an aviation revolution where autonomy will play a central role in enabling complex, multi-agent systems to communicate, interact, and collaborate on a myriad of applications spanning autonomous swarms to wild-fire management. Autonomy is not an absolute but rather a spectrum ranging from a system requiring significant human intervention to one requiring little to none [1]. For example, the extreme, in the case of an autonomous aircraft, is one that operates independently in the airspace interacting with all other elements (air traffic controllers, other pilots) as if it were a human pilot. Critical to this vision is an architecture that enables autonomous agents to interact with minimal latency. Edge computing is an emerging architecture where compute and storage is pushed to the ‘edge’ of the network in order to minimize the round-trip time from agent to resource thereby mitigating the latency associated with cloud-only based approaches. Additionally, services can generate massive amounts of data (e.g., video feeds), which may require analysis in near real-time. Moving this data to the cloud for further processing may not be feasible due to latency, bandwidth, and cost. Privacy, security, and reliability can also be improved by edge computing architectures. However, this geo-distributed and dynamic* architecture complicates the establishment of unambiguous network security boundaries and can lead to vulnerabilities including man in the middle attacks, replay attacks, physical security breaches of edge nodes, signal interception, etc. This motivates the need for zero-trust architectures [2–4] which de-emphasize the notion of static network perimeters and, as the name implies, do not instill any innate trust in any particular agent. It is required that all agents must be authorized and approved in every transaction. In this paper, we present a zero-trust architecture suitable for edge-computing applications that demand significant low-latency, security, privacy, and reliability.

zero trust↗
NASA NTRS1987

Efficient Ada multitasking on a RISC register window architecture

This work addresses the problem of reducing context switch overhead on a processor which supports a large register file - a register file much like that which is part of the Berkeley RISC processors and several other emerging architectures (which are not necessarily reduced instruction set machines in the purest sense). Such a reduction in overhead is particularly desirable in a real-time embedded application, in which task-to-task context switch overhead may result in failure to meet crucial deadlines. A storage management technique by which a context switch may be implemented as cheaply as a procedure call is presented. The essence of this technique is the avoidance of the save/restore of registers on the context switch. This is achieved through analysis of the static source text of an Ada tasking program. Information gained during that analysis directs the optimized storage management strategy for that program at run time. A formal verification of the technique in terms of an operational control model and an evaluation of the technique's performance via simulations driven by synthetic Ada program traces are presented.

Kearns, J. P.↗
NASA NTRS2010

Introducing Locality-Aware Computation into OpenMP

This paper presents our idea to introduce data locality feature into OpenMP. Given the facts that the memory systems are hierarchical while OpenMP is at, we believe that it is important to introduce new features to OpenMF to provide Open MP programmer capability to manage the data layout and align tasks and data as close as possible in modern architectures. We present the syntax and examples of the proposed features in this paper, and hope to enable further discussion of useful language features to keep OpenMP scalable in emerging architectures.

Huang, Lei↗
NASA NTRS2023

The Earth in Living Color - NASA’s Surface Biology and Geology Designated Observable

The Surface Biology and Geology (SBG) Designated Observable will transform our understanding of the global land surface, inland and coastal aquatic ecosystems through visible-to-shortwave infra-red imaging (VSWIR) spectroscopy and thermal infra-red (TIR) imaging. SBG is one of four high-priority observables recommended in the 2017 NASA Earth Science Decadal Survey t o address science questions on vegetation and aquatic ecosystem health, snow-cover dynamics, volcanic activity, and minerology. With a planned launch readiness date of 2028, SBG is currently in Pre-Phase A, with Level 1 requirements being developed for a two-spacecraft architecture, including an additional constellation pathfinder. The recommended architecture emerged from an extensive study (2018-2021) that engaged the research and applications community to consider the science questions and measurement objectives of the Decadal Survey. A Science and Applications Traceability Matrix was used as a basis for scoring candidate architectures, with inputs from four working groups that covered algorithms, applications, calibration and validation, and modeling. Two pathfinder studies, Modeling End-to-End Traceability in support of SBG (MEET-SBG) and Space-based Imaging Spectroscopy and Thermal pathfindER (SISTER) are providing pre-launch modeling tools and data for algorithm development to support science value trades. The architecture consists of one spacecraft hosting a wide-swath VSWIR imaging spectrometer providing 30-m ground-sample distance (GSD), a spectral range of 380-2500 nm (at 10 nm resolution), 16-day revisit with 400 signal-to-noise for VNIR and 250 for SWIR (at 25% reflectance). A separate spacecraft will host a wide swath thermal imager, with five to seven bands placed between 4-12 μm), with 60-m (GSD), 3- day revisit, and 0.2K noise-equivalent differential temperature (NeDT). A VNIR compact camera will be hosted on the TIR spacecraft to enable coincident TIR and VNIR observations. A constellation pathfinder will evaluate options for enabling VSWIR mission continuity using Small Sats or data buys. Partnerships with international space agencies contribute technology as well as improvements to temporal revisit. SBG, when launched, will be the first dedicated mission collecting the full spectra of the Earth’s ‘living color’ and will play a critical role in NASA’s Earth System Observatory.

David S Schimel↗
NASA NTRS2017

Exploring Concepts of Operations for On-Demand Passenger Air Transportation

In recent years, a surge of interest in "flying cars" for city commutes has led to rapid development of new technologies to help make them and similar on-demand mobility platforms a reality. To this end, this paper provides analyses of the stakeholders involved, their proposed operational concepts, and the hazards and regulations that must be addressed. Three system architectures emerged from the analyses, ranging from conventional air taxi to revolutionary fully autonomous aircraft operations, each with vehicle safety functions allocated differently between humans and machines. Advancements for enabling technologies such as distributed electric propulsion and artificial intelligence have had major investments and initial experimental success, but may be some years away from being deployed for on-demand passenger air transportation at scale.

Nneji, Victoria Chibuogu↗
NASA NTRS2016

Architectural and Operational Considerations Emerging from Hybrid RF-Optical Network Loading Simulations

A technology demonstration of free space optical communication at interplanetary distances is planned via one or more future NASA deep-space missions. Such demonstrations will “pave the way” for operational use of optical communications on future robotic/potential Human missions. Hence, the Deep Space Network architecture will need to evolve. Preliminary attempts to model the anticipated future mission set and simulate how well it loads onto assumed architectures with combinations of RF and optical apertures have been evaluated. This paper discusses the results of preliminary loading simulations for hybrid RF-optical network architectures and highlights key mission and ground infrastructure considerations that emerge.

loading simulations↗
NASA NTRS2016

Architectural and Operational Considerations Emerging from Hybrid RF-Optical Network Loading Simulations

We have the technical capability to model hybrid deep-space RF and Optical communications networks, but we have little guidance on how the missions and ground architectures will be designed and operated. We exposed several issues that must be resolved before an optimal solution can be reached. With future studies, we may be able to determine solutions to these issues, and perform more precise loading performance analyses to arrive at the most optimal RF and optical ground assets combinations for meeting the projected future demand. The results will then help inform NASA as it plans for infrastructure development to prepare for human/robotic missions in the coming decades.

Chen, Yijiang↗
NASA NTRS2009

Ares V Overview and Status

As part of NASA s Constellation Program to resume exploration beyond low Earth orbit (LEO), the Ares V heavy-lift cargo launch vehicle as currently conceived will be able to send more crew and cargo to more places on the Moon than the Apollo Program Saturn V. (Figure 1) It also has unprecedented cargo mass and volume capabilities that will be a national asset for science, commerce, and national defense applications. Compared to current systems, it will offer approximately five times the mass and volume to most orbits and locations. The Columbia space shuttle accident, the resulting investigation, the Vision for Space Exploration, and the Exploration Systems Architecture Study (ESAS) broadly shaped the Constellation architecture. Out of those events and initiatives emerged an architecture intended to replace the space shuttle, complete the International Space Station (ISS), resume a much more ambitious plan to explore the moon as a stepping stone to other destinations in the solar system. The Ares I was NASA s main priority because of the goal to retire the Shuttle. Ares V remains in a concept development phase, evolving through hundreds of configurations. The current reference design was approved during the Lunar Capabilities Concept Review/Ares V Mission Concept Review (LCCR/MCR) in June 2008. This reference concept serves as a starting point for a renewed set of design trades and detailed analysis into its interaction with the other components of the Constellation architecture and existing launch infrastructure. In 2009, the Ares V team was heavily involved in supporting the Review of U.S. Human Space Flight Plans Committee. Several alternative designs for Ares V have been supplied to the committee. This paper will discuss the origins of the Ares V design, the evolution to the current reference configuration, and the options provided to the review committee.

Creech, Steve↗
NASA NTRSDate not supplied

Down-Selection of Four Common Habitat Variants

The Common Habitat is a large habitat that uses the Space Launch System core stage liquid oxygen tank as its primary structure. It has a gravity-independent internal architecture, such that identical units can be used on the lunar surface, Mars surface, and in microgravity. In developing the habitat, two key architectural questions emerged. Should the internal layout use a vertical or horizontal orientation of the tank? Should the crew size be four or eight? This led to the design of four variants: a four-crew horizontal, four-crew vertical, eight-crew horizontal, and eight-crew vertical. The primary consideration applied for down-selection was the crew experience living and working in the habitat, inclusive of crew productivity, well-being, and survivability. Based on this consideration, a series of seven assessments was performed to compare the four variants. A stowage assessment developed a standard logistics module and then considered the amounts of water to be stored in each variant. It then estimated how much stowage could be carried onboard each Common Habitat and how many logistics modules are required by each variant for a given mission duration. A functional analysis identified and compared the living and working functions across the four habitat, ranking them relative to each other. A crew time assessment first estimated the total crew time, building a weekly crew timeline for both four and eight-person crews. It then allocated time to activities linked to living and working functions, comparing how much time was available for each function in each variant. A science productivity assessment developed a relative metric using crew time, science stowage, and assumed rates of experiment consumables use to analytically compare the four variants. It also comparatively ranked the habitats with respect to a number of subjective parameters and a workstation acceptability rating. A maintenance capacity assessment identified and compared eleven generic maintenance capabilities across the four variants and also ranked the variants for their predicted ability to complete twelve fabrication, maintenance, and repair scenarios. A contingency responsiveness analysis examined twelve serious in-flight contingencies. For each scenario, the number of crew needed to respond was predicted and acceptability of various aspects of contingency response was evaluated, comparing the four variants against each other. Finally, in a habitability assessment, 120 habitability characteristics reflecting 13 major categories were evaluated for each habitat. These results were compared to identify the most acceptable habitat in each category. Ultimately, the data was shown to favor the horizontal orientation over the vertical and an eight-person crew over four. Implications of selecting this variant are discussed, including specific architectural challenges that result from the use of the full SLS liquid oxygen tank.

Habitability↗
NASA NTRSDate not supplied

Down-Selection of Four Common Habitat Variants

The Common Habitat is a large habitat developed as an alternative architecture study, not part of the current NASA baseline, that uses the SLS core stage liquid oxygen tank as its primary structure. It has a gravity-independent internal architecture, such that identical units can be used on the lunar surface, Mars surface, and in microgravity. In developing the habitat, two key architectural questions emerged. Should the internal layout use a vertical or horizontal orientation of the tank? Should the crew size be four or eight? This led to the design of four variants: a four-crew horizontal, four-crew vertical, eight-crew horizontal, and eight-crew vertical. The four-crew variants use a shortened version of the tank while the eight-crew variants use the entire tank. The primary consideration applied for down-selection is the crew experience living and working in the habitat, inclusive of crew productivity, well-being, and survivability. Based on this consideration, a series of seven assessments were performed to compare the variants. This analysis was performed as an unfunded, volunteer activity leveraging civil servants across multiple field centers, most with expertise working in various Artemis teams. Additionally, the evaluation was limited to the use of CAD models, images, and spreadsheet data, with no resources available for mockups or Virtual Reality. A logistics analysis developed a standard logistics module and then estimated how much stowage could be carried onboard each Common Habitat and how many logistics modules are required by each variant for a given mission duration. It also considered the amounts of water to be stored in each variant. A functional analysis identified and compared the living and working functions across the habitats, ranking them relative to each other. A crew time assessment first estimated the total crew time, building a weekly crew timeline for both four and eight-person crews. It then allocated time to activities linked to living and working functions, comparing how much time was available for each function in each variant. A science productivity assessment developed a relative metric using crew time, science stowage, and assumed rates of experiment consumables use to analytically compare the four variants. It also comparatively ranked the habitats with respect to a number of subjective parameters and a workstation acceptability rating. A maintenance capacity assessment identified and compared eleven generic maintenance capabilities across the variants and also ranked them for their predicted ability to complete twelve fabrication, maintenance, and repair scenarios. A contingency responsiveness analysis examined twelve serious in-flight contingencies. For each scenario, the number of crew needed to respond were predicted and acceptability of various aspects of contingency response were evaluated, comparing the variants against each other. Finally, in a habitability assessment, 120 habitability characteristics reflecting 13 major categories were evaluated for each habitat. These results were compared to identify the most acceptable habitat in each category. Ultimately, the data favored the horizontal orientation over the vertical and an eight-person crew over four. Implications of selecting this variant are discussed, including specific architectural challenges that result from the use of the full tank.

Habitability↗
NASA NTRS2003

Multi-Disciplinary Analysis for Future Launch Systems Using NASA's Advanced Engineering Environment (AEE)

A new engineering environment constructed for the purposes of analyzing and designing Reusable Launch Vehicles (RLVs) is presented. The new environment has been developed to allow NASA to perform independent analysis and design of emerging RLV architectures and technologies. The new Advanced Engineering Environment (AEE) is both collaborative and distributed. It facilitates integration of the analyses by both vehicle performance disciplines and life-cycle disciplines. Current performance disciplines supported include: weights and sizing, aerodynamics, trajectories, propulsion, structural loads, and CAD-based geometries. Current life-cycle disciplines supported include: DDT&E cost, production costs, operations costs, flight rates, safety and reliability, and system economics. Involving six NASA centers (ARC, LaRC, MSFC, KSC, GRC and JSC), AEE has been tailored to serve as a web-accessed agency-wide source for all of NASA's future launch vehicle systems engineering functions. Thus, it is configured to facilitate (a) data management, (b) automated tool/process integration and execution, and (c) data visualization and presentation. The core components of the integrated framework are a customized PTC Windchill product data management server, a set of RLV analysis and design tools integrated using Phoenix Integration's Model Center, and an XML-based data capture and transfer protocol. The AEE system has seen production use during the Initial Architecture and Technology Review for the NASA 2nd Generation RLV program, and it continues to undergo development and enhancements in support of its current main customer, the NASA Next Generation Launch Technology (NGLT) program.

Monell, D.↗
NASA NTRS2005

Generating Mosaics of Astronomical Images

"Montage" is the name of a service of the National Virtual Observatory (NVO), and of software being developed to implement the service via the World Wide Web. Montage generates science-grade custom mosaics of astronomical images on demand from input files that comply with the Flexible Image Transport System (FITS) standard and contain image data registered on projections that comply with the World Coordinate System (WCS) standards. "Science-grade" in this context signifies that terrestrial and instrumental features are removed from images in a way that can be described quantitatively. "Custom" refers to user-specified parameters of projection, coordinates, size, rotation, and spatial sampling. The greatest value of Montage is expected to lie in its ability to analyze images at multiple wavelengths, delivering them on a common projection, coordinate system, and spatial sampling, and thereby enabling further analysis as though they were part of a single, multi-wavelength image. Montage will be deployed as a computation-intensive service through existing astronomy portals and other Web sites. It will be integrated into the emerging NVO architecture and will be executed on the TeraGrid. The Montage software will also be portable and publicly available.

Bergou, Attila↗