SEARCH · Search NASA

Results for “architectural”

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 109 records · Page 6

All sources NASA NTRS DOE OSTI

NASA NTRS2011

A Summary of NASA Architecture Studies Utilizing Fission Surface Power Technology

Beginning with the Exploration Systems Architecture Study in 2005, NASA has conducted various mission architecture studies to evaluate implementation options for the U.S. Space Policy. Several of the studies examined the use of Fission Surface Power (FSP) systems for human missions to the lunar and Martian surface. This paper summarizes the FSP concepts developed under four different NASA-sponsored architecture studies: Lunar Architecture Team, Mars Architecture Team, Lunar Surface Systems/Constellation Architecture Team, and International Architecture Working Group-Power Function Team.

Mason, Lee S.↗

NASA NTRS2011

Executable Architecture Research at Old Dominion University

Executable Architectures allow the evaluation of system architectures not only regarding their static, but also their dynamic behavior. However, the systems engineering community do not agree on a common formal specification of executable architectures. To close this gap and identify necessary elements of an executable architecture, a modeling language, and a modeling formalism is topic of ongoing PhD research. In addition, systems are generally defined and applied in an operational context to provide capabilities and enable missions. To maximize the benefits of executable architectures, a second PhD effort introduces the idea of creating an executable context in addition to the executable architecture. The results move the validation of architectures from the current information domain into the knowledge domain and improve the reliability of such validation efforts. The paper presents research and results of both doctoral research efforts and puts them into a common context of state-of-the-art of systems engineering methods supporting more agility.

Tolk, Andreas↗

NASA NTRS2016

Functional Interface Considerations within an Exploration Life Support System Architecture

As notional life support system (LSS) architectures are developed and evaluated, myriad options must be considered pertaining to process technologies, components, and equipment assemblies. Each option must be evaluated relative to its impact on key functional interfaces within the LSS architecture. A leading notional architecture has been developed to guide the path toward realizing future crewed space exploration goals. This architecture includes atmosphere revitalization, water recovery and management, and environmental monitoring subsystems. Guiding requirements for developing this architecture are summarized and important interfaces within the architecture are discussed. The role of environmental monitoring within the architecture is described.

Perry, Jay L.↗

NASA NTRS2023

Exploration Systems Development Mission Directorate (ESDMD) Moon-to-Mars Architecture Definition Document

There are many opportunities in executing the ambitious Moon-to-Mars efforts through an integrated architecture. NASA addresses this in its Moon-to-Mars Strategy and Objectives Development2 document (hereafter referred to as the M2M Strategy). Many of these opportunities involve establishing a system engineering framework that can support the breadth of necessary program and system contributions. By applying these needs to nearer-term lunar development, NASA will be instituting the process, procedures, and techniques needed to enable longer-term Mars goals and more. Some of the challenges being addressed in the M2M Strategy are associated with the architecture definition and include broad/changing goals, funding, and external pressures/influences. This document and the methodology outlined for architecture definition have been crafted to contend with these using an iterative and adaptable framework. The primary purpose of the Architecture Definition Document (ADD) is to capture the methodology, organization, and decomposition necessary to translate the broad objectives outlined in the M2M Strategy into functions and use cases that can be allocated to implementable programs and projects. Inherent in this process will be the need to communicate the long-term vision, maintain traceability to responsible parties, and iterate on the architectural implementation as innovations and solutions develop. This document will be updated and improved in conjunction with the Architecture Concept Review (ACR) which will be held annually to help unify the Agency and to get buy-in and input from across the Agency on the human exploration architecture. The annual nature of the process provides the opportunity to continually incorporate new developments in technologies and new partnerships, whether they be with industry, the U.S. Government, international entities, or academia.

Moon-to-Mars Strategy↗

NASA NTRS2004

A comparative analysis of loop heat pipe based thermal architectures for spacecraft thermal control

Loop Heat Pipes (LHP) have gained acceptance as a viable means of heat transport in many spacecraft in recent years. However, applications using LHP technology tend to only remove waste heat from a single component to an external radiator. Removing heat from multiple components has been done by using multiple LHPs. This paper discusses the development and implementation of a Loop Heat Pipe based thermal architecture for spacecraft. In this architecture, a Loop Heat Pipe with multiple evaporators and condensers is described in which heat load sharing and thermal control of multiple components can be achieved. A key element in using a LHP thermal architecture is defining the need for such an architecture early in the spacecraft design process. This paper describes an example in which a LHP based thermal architecture can be used and how such a system can have advantages in weight, cost and reliability over other kinds of distributed thermal control systems. The example used in this paper focuses on a Mars Rover Thermal Architecture. However, the principles described here are applicable to Earth orbiting spacecraft as well.

loop heat pipes↗

NASA NTRS2006

Architecting Ourselves: Schema to Facilitate Growth of the International Space Architecture Community

This paper develops a conceptual model, adapted from the way research and development non-profits and universities tend to be organized, that could help amplify the reach and effectiveness of the international space architecture community. The model accommodates current activities and published positions, and increases involvement by allocating accountability for necessary professional and administrative activities. It coordinates messaging and other outreach functions to improve brand management. It increases sustainability by balancing volunteer workload. And it provides an open-ended structure that can be modified gracefully as needs, focus, and context evolve. Over the past 20 years, Space Architecture has attained some early signs of legitimacy as a discipline: an active, global community of practicing and publishing professionals; university degree programs; a draft undergraduate curriculum; and formal committee establishment within multiple professional organizations. However, the nascent field has few outlets for expression in built architecture, which exacerbates other challenges the field is experiencing in adolescence: obtaining recognition and inclusion as a unique contributor by the established aerospace profession; organizing and managing outreach by volunteers; striking a balance between setting admittance or performance credentials and attaining a critical mass of members; and knowing what to do, beyond sharing common interests, to actually increase the market demand for space architecture. This paper develops a conceptual model, adapted from the way research-anddevelopment non-profits and universities tend to be organized, that could help amplify the reach and effectiveness of the international space architecture community. The model accommodates current activities and published positions, and increases involvement by allocating accountability for necessary professional and administrative activities. It coordinates messaging and other outreach functions to improve brand management. It increases sustainability by balancing volunteer workload. And it provides an open-ended structure that can be modified gracefully as needs, focus, and context evolve. This organizational model is offered up for consideration, debate, and toughening by the space architecture community at large.

space architecure↗

NASA NTRS2015

Fault Management Architectures and the Challenges of Providing Software Assurance

Fault Management (FM) is focused on safety, the preservation of assets, and maintaining the desired functionality of the system. How FM is implemented varies among missions. Common to most missions is system complexity due to a need to establish a multi-dimensional structure across hardware, software and spacecraft operations. FM is necessary to identify and respond to system faults, mitigate technical risks and ensure operational continuity. Generally, FM architecture, implementation, and software assurance efforts increase with mission complexity. Because FM is a systems engineering discipline with a distributed implementation, providing efficient and effective verification and validation (V&V) is challenging. A breakout session at the 2012 NASA Independent Verification & Validation (IV&V) Annual Workshop titled "V&V of Fault Management: Challenges and Successes" exposed this issue in terms of V&V for a representative set of architectures. NASA's Software Assurance Research Program (SARP) has provided funds to NASA IV&V to extend the work performed at the Workshop session in partnership with NASA's Jet Propulsion Laboratory (JPL). NASA IV&V will extract FM architectures across the IV&V portfolio and evaluate the data set, assess visibility for validation and test, and define software assurance methods that could be applied to the various architectures and designs. This SARP initiative focuses efforts on FM architectures from critical and complex projects within NASA. The identification of particular FM architectures and associated V&V/IV&V techniques provides a data set that can enable improved assurance that a system will adequately detect and respond to adverse conditions. Ultimately, results from this activity will be incorporated into the NASA Fault Management Handbook providing dissemination across NASA, other agencies and the space community. This paper discusses the approach taken to perform the evaluations and preliminary findings from the research.

Fault Management↗

NASA NTRS2011

Model-Based Systems Engineering for Capturing Mission Architecture System Processes with an Application Case Study - Orion Flight Test 1

Model-based Systems Engineering (MBSE) is an emerging methodology that can be leveraged to enhance many system development processes. MBSE allows for the centralization of an architecture description that would otherwise be stored in various locations and formats, thus simplifying communication among the project stakeholders, inducing commonality in representation, and expediting report generation. This paper outlines the MBSE approach taken to capture the processes of two different, but related, architectures by employing the Systems Modeling Language (SysML) as a standard for architecture description and the modeling tool MagicDraw. The overarching goal of this study was to demonstrate the effectiveness of MBSE as a means of capturing and designing a mission systems architecture. The first portion of the project focused on capturing the necessary system engineering activities that occur when designing, developing, and deploying a mission systems architecture for a space mission. The second part applies activities from the first to an application problem - the system engineering of the Orion Flight Test 1 (OFT-1) End-to-End Information System (EEIS). By modeling the activities required to create a space mission architecture and then implementing those activities in an application problem, the utility of MBSE as an approach to systems engineering can be demonstrated.

Orion Flight Test 1 (OFT-1)↗

NASA NTRS2017

SpaceCubeX: A Framework for Evaluating Hybrid Multi-Core CPU FPGA DSP Architectures

The SpaceCubeX project is motivated by the need for high performance, modular, and scalable on-board processing to help scientists answer critical 21st century questions about global climate change, air quality, ocean health, and ecosystem dynamics, while adding new capabilities such as low-latency data products for extreme event warnings. These goals translate into on-board processing throughput requirements that are on the order of 100-1,000 more than those of previous Earth Science missions for standard processing, compression, storage, and downlink operations. To study possible future architectures to achieve these performance requirements, the SpaceCubeX project provides an evolvable testbed and framework that enables a focused design space exploration of candidate hybrid CPU/FPGA/DSP processing architectures. The framework includes ArchGen, an architecture generator tool populated with candidate architecture components, performance models, and IP cores, that allows an end user to specify the type, number, and connectivity of a hybrid architecture. The framework requires minimal extensions to integrate new processors, such as the anticipated High Performance Spaceflight Computer (HPSC), reducing time to initiate benchmarking by months. To evaluate the framework, we leverage a wide suite of high performance embedded computing benchmarks and Earth science scenarios to ensure robust architecture characterization. We report on our projects Year 1 efforts and demonstrate the capabilities across four simulation testbed models, a baseline SpaceCube 2.0 system, a dual ARM A9 processor system, a hybrid quad ARM A53 and FPGA system, and a hybrid quad ARM A53 and DSP system.

Hybrid Flight Architectures↗

NASA NTRS2017

Prospective Architectures for Onboard vs Cloud-Based Decision Making for Unmanned Aerial Systems

This paper investigates propsective architectures for decision-making in unmanned aerial systems. When these unmanned vehicles operate in urban environments, there are several sources of uncertainty that affect their behavior, and decision-making algorithms need to be robust to account for these different sources of uncertainty. It is important to account for several risk-factors that affect the flight of these unmanned systems, and facilitate decision-making by taking into consideration these various risk-factors. In addition, there are several technical challenges related to autonomous flight of unmanned aerial systems; these challenges include sensing, obstacle detection, path planning and navigation, trajectory generation and selection, etc. Many of these activities require significant computational power and in many situations, all of these activities need to be performed in real-time. In order to efficiently integrate these activities, it is important to develop a systematic architecture that can facilitate real-time decision-making. Four prospective architectures are discussed in this paper; on one end of the spectrum, the first architecture considers all activities/computations being performed onboard the vehicle whereas on the other end of the spectrum, the fourth and final architecture considers all activities/computations being performed in the cloud, using a new service known as Prognostics as a Service that is being developed at NASA Ames Research Center. The four different architectures are compared, their advantages and disadvantages are explained and conclusions are presented.

Software engineering↗

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 NTRSDate not supplied

Analysis of Alternative Architectures for Cargo Lunar Landers

NASA’s Human Landing System (HLS) program has been working with commercial partners to develop human-class lunar landers to return the first American woman and next American man to the lunar surface in the mid 2020’s. In an effort to expand human presence beyond low Earth orbit, NASA’s Artemis program aims to facilitate a sustainable, long-term human presence in cis-lunar space. A component of this will require significant infrastructure to be delivered to the lunar surface. Delivering this infrastructure will require a significant lander capability that has yet to be developed. A thorough understanding of cargo lunar lander architectures is required such that select alternatives can be identified that best support the Artemis program’s objective of sustainability. The goal of this study is to aid NASA and its partners in the understanding of the cargo lunar lander trades space, as well as identify potential robust alternatives. The results will support NASA as it moves forward with key activities such as requirements formulation, agency strategic planning, and potential cargo lunar lander procurements. The study builds off of recent work performed by the Human Landing System program’s Architecture and Systems Analysis group to encompass a broad trade space of cargo lunar lander architecture alternatives. The current trade space as depicted by the morphological matrix and mission graph in Fig. 1 and Fig. 2, respectively, includes key alternative options that have become highly relevant due to current HLS activities and include on-orbit refueling, active cryogenic fluid management, Earth orbit aggregation, and global lunar access. The authors believe that there is also a statistically relevant impact of lander-payload configuration on the primary structure of the vehicle that could greatly impact alternative selection. Because of this, several conceptual lander-payload configurations will be evaluated to determine the level of impact. The current set of conceptual configurations are shown in Fig. 3 and Fig. 4. To aid the conceptual evaluation of these configurations, a catalogue of notional payloads has been developed that represent a wide range of masses and volumes that are expected to be delivered in support of a sustained human lunar presence, including pressurized and unpressurized rovers, surface habitats, power systems, and other support infrastructure. In order to execute this study in a timely fashion, a similar approach to that utilized in a similar 2019 study focused on 2024 human lunar sorties will be employed [1]. The team utilized a novel architecture synthesis framework currently being developed by NASA/MSFC to evaluate over 600,000 lunar lander architectures over a two month time frame [2]. From this large data set, varying ground rules and assumptions were applied as filters to explore the trade space to identify alternatives which exhibited robustness, as measured by launch vehicle payload margin, to absorb the natural growth that occurs during design maturation. The set of Earth-Moon system Delta-Vs assumed from the 2019 study, shown in Fig. 5, will be repurposed to accelerate model formulation for this effort. Additionally, current efforts in collaboration with the Georgia Institute of Technology’s Aerospace System Design Lab will be integrated to provide probabilistic modeling of the cargo lunar lander architectures to aid in identifying robust design alternatives [3]. The approach will help minimize potential impacts due to large levels of uncertainty inherent to pre phase-A conceptual design. By leveraging these past and present studies and partnerships, a highly detailed set of data can be generated in a short time period to aid NASA in the coming years to support the goal of a sustained human lunar presence.

Architectures↗

NASA NTRS1977

Spacelab output processing system architectural study

Two different system architectures are presented. The two architectures are derived from two different data flows within the Spacelab Output Processing System. The major differences between these system architectures are in the position of the decommutation function (the first architecture performs decommutation in the latter half of the system and the second architecture performs that function in the front end of the system). In order to be examined, the system was divided into five stand-alone subsystems; Work Assembler, Mass Storage System, Output Processor, Peripheral Pool, and Resource Monitor. The work load of each subsystem was estimated independent of the specific devices to be used. The candidate devices were surveyed from a wide sampling of off-the-shelf devices. Analytical expressions were developed to quantify the projected workload in conjunction with typical devices which would adequately handle the subsystem tasks. All of the study efforts were then directed toward preparing performance and cost curves for each architecture subsystem.

Source record↗

NASA NTRS1987

The hypercluster: A parallel processing test-bed architecture for computational mechanics applications

The development of numerical methods and software tools for parallel processors can be aided through the use of a hardware test-bed. The test-bed architecture must be flexible enough to support investigations into architecture-algorithm interactions. One way to implement a test-bed is to use a commercial parallel processor. Unfortunately, most commercial parallel processors are fixed in their interconnection and/or processor architecture. In this paper, we describe a modified n cube architecture, called the hypercluster, which is a superset of many other processor and interconnection architectures. The hypercluster is intended to support research into parallel processing of computational fluid and structural mechanics problems which may require a number of different architectural configurations. An example of how a typical partial differential equation solution algorithm maps on to the hypercluster is given.

Blech, Richard A.↗

NASA NTRS1991

Architecture for Survivable System Processing (ASSP)

The Architecture for Survivable System Processing (ASSP) Program is a multi-phase effort to implement Department of Defense (DOD) and commercially developed high-tech hardware, software, and architectures for reliable space avionics and ground based systems. System configuration options provide processing capabilities to address Time Dependent Processing (TDP), Object Dependent Processing (ODP), and Mission Dependent Processing (MDP) requirements through Open System Architecture (OSA) alternatives that allow for the enhancement, incorporation, and capitalization of a broad range of development assets. High technology developments in hardware, software, and networking models, address technology challenges of long processor life times, fault tolerance, reliability, throughput, memories, radiation hardening, size, weight, power (SWAP) and security. Hardware and software design, development, and implementation focus on the interconnectivity/interoperability of an open system architecture and is being developed to apply new technology into practical OSA components. To insure for widely acceptable architecture capable of interfacing with various commercial and military components, this program provides for regular interactions with standardization working groups (e.g.) the International Standards Organization (ISO), American National Standards Institute (ANSI), Society of Automotive Engineers (SAE), and Institute of Electrical and Electronic Engineers (IEEE). Selection of a viable open architecture is based on the widely accepted standards that implement the ISO/OSI Reference Model.

Wood, Richard J.↗

NASA NTRS1992

Aerospace architecture - A comparative analysis of five lunar habitats

This paper investigates the trade-off between efficiency and habitability in lunar architectures. Five distinct lunar architectures are briefly presented and then critically examined in terms of spatial allocation and surface area to net and gross volume and in terms of four habitability criteria. Advantages and limitations of the basic concepts underlying each architecture are examined. A fundamental inverse relation is discovered between spatial efficiency (and thus cost containment) and habitability (and thus satisfaction and productivity). The most efficient architectures are described in detail, as are the most habitable architectures. This leads to a critical trade-off to be made in the design of any lunar architecture. Ways are suggested to integrate the concerns for efficiency with habitability.

Moore, Gary T.↗

NASA NTRS1992

A neuro-fuzzy architecture for real-time applications

Neural networks and fuzzy expert systems perform the same task of functional mapping using entirely different approaches. Each approach has certain unique features. The ability to learn specific input-output mappings from large input/output data possibly corrupted by noise and the ability to adapt or continue learning are some important features of neural networks. Fuzzy expert systems are known for their ability to deal with fuzzy information and incomplete/imprecise data in a structured, logical way. Since both of these techniques implement the same task (that of functional mapping--we regard 'inferencing' as one specific category under this class), a fusion of the two concepts that retains their unique features while overcoming their individual drawbacks will have excellent applications in the real world. In this paper, we arrive at a new architecture by fusing the two concepts. The architecture has the trainability/adaptibility (based on input/output observations) property of the neural networks and the architectural features that are unique to fuzzy expert systems. It also does not require specific information such as fuzzy rules, defuzzification procedure used, etc., though any such information can be integrated into the architecture. We show that this architecture can provide better performance than is possible from a single two or three layer feedforward neural network. Further, we show that this new architecture can be used as an efficient vehicle for hardware implementation of complex fuzzy expert systems for real-time applications. A numerical example is provided to show the potential of this approach.

Ramamoorthy, P. A.↗

NASA NTRS1992

A reference architecture for the component factory

Software reuse can be achieved through an organization that focuses on utilization of life cycle products from previous developments. The component factory is both an example of the more general concepts of experience and domain factory and an organizational unit worth being considered independently. The critical features of such an organization are flexibility and continuous improvement. In order to achieve these features we can represent the architecture of the factory at different levels of abstraction and define a reference architecture from which specific architectures can be derived by instantiation. A reference architecture is an implementation and organization independent representation of the component factory and its environment. The paper outlines this reference architecture, discusses the instantiation process, and presents some examples of specific architectures by comparing them in the framework of the reference model.

Basili, Victor R.↗