Search NASA⌕ Search

SEARCH · Search NASA

Results for “Systems 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 145 records · Page 8
All sourcesNASA NTRSDOE OSTI
NASA NTRS1986

Standard data systems architecture for the Space Station

Attention is given to an end-to-end Space Station Data System (SSDS) architecture which is based on internationally-recommended standards developed by the Consultative Committee for Space Data Systems (CCSDS). The proposed system uses simple modular building blocks that are recursively replicated and linked to construct essentially any desired data system configuration. The SSDS concept provides for a user-transparent data transport system which is entirely independent of the characteristics of the user data being transported, and in addition, has the flexibility to accommodate mission-induced changes in data traffic. SSDS physical elements include the following: (1) on-orbit local area networks, (2) space-to-ground, ground-to-space, and space-to-space data links, and (3) ground mission support facilities containing telemetry and telecommand data handling termini and preprocessing services.

Greenberg, E.↗
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 NTRS1989

Fault tolerant hypercube computer system architecture

A fault-tolerant multiprocessor computer system of the hypercube type comprising a hierarchy of computers of like kind which can be functionally substituted for one another as necessary is disclosed. Communication between the working nodes is via one communications network while communications between the working nodes and watch dog nodes and load balancing nodes higher in the structure is via another communications network separate from the first. A typical branch of the hierarchy reporting to a master node or host computer comprises, a plurality of first computing nodes; a first network of message conducting paths for interconnecting the first computing nodes as a hypercube. The first network provides a path for message transfer between the first computing nodes; a first watch dog node; and a second network of message connecting paths for connecting the first computing nodes to the first watch dog node independent from the first network, the second network provides an independent path for test message and reconfiguration affecting transfers between the first computing nodes and the first switch watch dog node. There is additionally, a plurality of second computing nodes; a third network of message conducting paths for interconnecting the second computing nodes as a hypercube. The third network provides a path for message transfer between the second computing nodes; a fourth network of message conducting paths for connecting the second computing nodes to the first watch dog node independent from the third network. The fourth network provides an independent path for test message and reconfiguration affecting transfers between the second computing nodes and the first watch dog node; and a first multiplexer disposed between the first watch dog node and the second and fourth networks for allowing the first watch dog node to selectively communicate with individual ones of the computing nodes through the second and fourth networks; as well as, a second watch dog node operably connected to the first multiplexer whereby the second watch dog node can selectively communicate with individual ones of the computing nodes through the second and fourth networks. The branch is completed by a first load balancing node; and a second multiplexer connected between the first load balancing node and the first and second watch dog nodes, allowing the first load balancing node to selectively communicate with the first and second watch dog nodes.

Madan, Herb S.↗
NASA NTRS1999

Reusable Rocket Engine Advanced Health Management System. Architecture and Technology Evaluation: Summary

In this study, we proposed an Advanced Health Management System (AHMS) functional architecture and conducted a technology assessment for liquid propellant rocket engine lifecycle health management. The purpose of the AHMS is to improve reusable rocket engine safety and to reduce between-flight maintenance. During the study, past and current reusable rocket engine health management-related projects were reviewed, data structures and health management processes of current rocket engine programs were assessed, and in-depth interviews with rocket engine lifecycle and system experts were conducted. A generic AHMS functional architecture, with primary focus on real-time health monitoring, was developed. Fourteen categories of technology tasks and development needs for implementation of the AHMS were identified, based on the functional architecture and our assessment of current rocket engine programs. Five key technology areas were recommended for immediate development, which (1) would provide immediate benefits to current engine programs, and (2) could be implemented with minimal impact on the current Space Shuttle Main Engine (SSME) and Reusable Launch Vehicle (RLV) engine controllers.

Pettit, C. D.↗
NASA NTRSDate not supplied

Thermal Control System Architecture and Technology Challenges for a Lunar Surface Habitat

NASA’s current plans for exploration of the Lunar South Pole region include a Surface Habitat (SH) to provide up to 60-day habitability for a crew of four. The SH concept is comprised of several elements including an inflatable volume for the habitable space and a metallic airlock for access to a pressurized rover and other surface assets. A conceptual architecture for the SH Thermal Control System (TCS) is presented. A TCS dual loop design is utilized with a water/propylene glycol mix for the internal crew spaces and an external loop with low temperature coolant. The internal loop is partitioned into low and moderate temperature service with a sublimator available for operational scenarios prior to thermal radiator deployment (or redeployment). Waste heat is rejected through thermal radiators contained in the external loop. Optimization of the thermal radiator geometry/orientation as well as the TCS internal/external loop architecture is accomplished via analytical models of the system. Low mass, dust tolerant, deployable/retractable thermal radiators (in partial gravity) and thermal control surfaces, along with accommodating infrequent eclipse periods lasting up to 100 hours, present the major technology challenges. Mitigation strategies to reduce the energy needed to maintain the SH and associated systems above survival temperature limits during the eclipse period are considered in the paper. Options include retractable radiators, re-generable heat exchangers, temperature excursions, thermal energy storage and optimized inflatable optical properties. TCS sensitivity to potential SH Electrical Power System (EPS) growth is also a consideration for both operational and dormant mission phases.

Thermal Control System↗
NASA NTRSDate not supplied

Thermal Control System Architecture and Technology Challenges for a Lunar Surface Habitat

NASA’s current plans for exploration of the Lunar South Pole region include a Surface Habitat (SH) to provide up to 60-day habitability for a crew of four. The SH concept is comprised of several elements including an inflatable volume for the habitable space and a metallic airlock for access to a pressurized rover and other surface assets. A conceptual architecture for the SH Thermal Control System (TCS) is presented. A TCS dual loop design is utilized with a water/propylene glycol mix for the internal crew spaces and an external loop with low temperature coolant. The internal loop is partitioned into low and moderate temperature service with a sublimator available for operational scenarios prior to thermal radiator deployment (or redeployment). Waste heat is rejected through thermal radiators contained in the external loop. Optimization of the thermal radiator geometry/orientation as well as the TCS internal/external loop architecture is accomplished via analytical models of the system. Low mass, dust tolerant, deployable/retractable thermal radiators (in partial gravity) and thermal control surfaces, along with accommodating infrequent eclipse periods lasting up to 100 hours, present the major technology challenges. Mitigation strategies to reduce the energy needed to maintain the SH and associated systems above survival temperature limits during the eclipse period are considered in the paper. Options include retractable radiators, re-generable heat exchangers, temperature excursions, thermal energy storage and optimized inflatable optical properties. TCS sensitivity to potential SH Electrical Power System (EPS) growth is also a consideration for both operational and dormant mission phases.

Thermal Control System↗
NASA NTRS1992

Deep Space Network information system architecture study

The purpose of this article is to describe an architecture for the Deep Space Network (DSN) information system in the years 2000-2010 and to provide guidelines for its evolution during the 1990s. The study scope is defined to be from the front-end areas at the antennas to the end users (spacecraft teams, principal investigators, archival storage systems, and non-NASA partners). The architectural vision provides guidance for major DSN implementation efforts during the next decade. A strong motivation for the study is an expected dramatic improvement in information-systems technologies, such as the following: computer processing, automation technology (including knowledge-based systems), networking and data transport, software and hardware engineering, and human-interface technology. The proposed Ground Information System has the following major features: unified architecture from the front-end area to the end user; open-systems standards to achieve interoperability; DSN production of level 0 data; delivery of level 0 data from the Deep Space Communications Complex, if desired; dedicated telemetry processors for each receiver; security against unauthorized access and errors; and highly automated monitor and control.

Beswick, C. A.↗
NASA NTRS2006

System Architecture Modeling for Technology Portfolio Management using ATLAS

Strategic planners and technology portfolio managers have traditionally relied on consensus-based tools, such as Analytical Hierarchy Process (AHP) and Quality Function Deployment (QFD) in planning the funding of technology development. While useful to a certain extent, these tools are limited in the ability to fully quantify the impact of a technology choice on system mass, system reliability, project schedule, and lifecycle cost. The Advanced Technology Lifecycle Analysis System (ATLAS) aims to provide strategic planners a decision support tool for analyzing technology selections within a Space Exploration Architecture (SEA). Using ATLAS, strategic planners can select physics-based system models from a library, configure the systems with technologies and performance parameters, and plan the deployment of a SEA. Key parameters for current and future technologies have been collected from subject-matter experts and other documented sources in the Technology Tool Box (TTB). ATLAS can be used to compare the technical feasibility and economic viability of a set of technology choices for one SEA, and compare it against another set of technology choices or another SEA. System architecture modeling in ATLAS is a multi-step process. First, the modeler defines the system level requirements. Second, the modeler identifies technologies of interest whose impact on an SEA. Third, the system modeling team creates models of architecture elements (e.g. launch vehicles, in-space transfer vehicles, crew vehicles) if they are not already in the model library. Finally, the architecture modeler develops a script for the ATLAS tool to run, and the results for comparison are generated.

Thompson, Robert W.↗
NASA NTRS2016

Hydrogen Purification and Recycling for an Integrated Oxygen Recovery System Architecture

The United States Atmosphere Revitalization life support system on the International Space Station (ISS) performs several services for the crew including oxygen generation, trace contaminant control, carbon dioxide (CO2) removal, and oxygen recovery. Oxygen recovery is performed using a Sabatier reactor developed by Hamilton Sundstrand, wherein CO2 is reduced with hydrogen in a catalytic reactor to produce methane and water. The water product is purified in the Water Purification Assembly and recycled to the Oxygen Generation Assembly (OGA) to provide O2 to the crew. This architecture results in a theoretical maximum oxygen recovery from CO2 of approximately 54% due to the loss of reactant hydrogen in Sabatier-produced methane that is currently vented outside of ISS. Plasma Methane Pyrolysis technology (PPA), developed by Umpqua Research Company, provides the capability to further close the Atmosphere Revitalization oxygen loop by recovering hydrogen from Sabatier-produced methane. A key aspect of this technology approach is to purify the hydrogen from the PPA product stream which includes acetylene, unreacted methane and byproduct water and carbon monoxide. In 2015, four sub-scale hydrogen separation systems were delivered to NASA for evaluation. These included two electrolysis single-cell hydrogen purification cell stacks developed by Sustainable Innovations, LLC, a sorbent-based hydrogen purification unit using microwave power for sorbent regeneration developed by Umpqua Research Company, and a LaNi4.6Sn0.4 metal hydride produced by Hydrogen Consultants, Inc. Here we report the results of these evaluations, discuss potential architecture options, and propose future work.

Abney, Morgan B.↗