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 361 records · Page 20
All sourcesNASA NTRSDOE OSTI
NASA NTRS1991

The Space Station end-to-end data system - Linking architecture and operations

The paper describes tha data system designed for linking and integrating the Space Station Freedom (SSF) space and ground architecture and for providing instrument data to the user and discusses the operations of the system. Particular attention is given to the objectives, the organization, and the schedule of the SSF Program, the infrastructure elements of the end-to-end data system, the key active functional areas of the system, the types of data, the user scenario, and the SSF's space, space-to-ground, and ground infrastructures as they are active in support of the stipulated user scenario.

Fishkind, Stanley↗
NASA NTRS2008

Space Telecommunications Radio System Software Architecture Concepts and Analysis

The Space Telecommunications Radio System (STRS) project investigated various Software Defined Radio (SDR) architectures for Space. An STRS architecture has been selected that separates the STRS operating environment from its various waveforms and also abstracts any specialized hardware to limit its effect on the operating environment. The design supports software evolution where new functionality is incorporated into the radio. Radio hardware functionality has been moving from hardware based ASICs into firmware and software based processors such as FPGAs, DSPs and General Purpose Processors (GPPs). Use cases capture the requirements of a system by describing how the system should interact with the users or other systems (the actors) to achieve a specific goal. The Unified Modeling Language (UML) is used to illustrate the Use Cases in a variety of ways. The Top Level Use Case diagram shows groupings of the use cases and how the actors are involved. The state diagrams depict the various states that a system or object may be in and the transitions between those states. The sequence diagrams show the main flow of activity as described in the use cases.

Handler, Louis M.↗
NASA NTRS2003

Architecture and System Engineering Development Study of Space-Based Satellite Networks for NASA Missions

Traditional NASA missions, both near Earth and deep space, have been stovepipe in nature and point-to-point in architecture. Recently, NASA and others have conceptualized missions that required space-based networking. The notion of networks in space is a drastic shift in thinking and requires entirely new architectures, radio systems (antennas, modems, and media access), and possibly even new protocols. A full system engineering approach for some key mission architectures will occur that considers issues such as the science being performed, stationkeeping, antenna size, contact time, data rates, radio-link power requirements, media access techniques, and appropriate networking and transport protocols. This report highlights preliminary architecture concepts and key technologies that will be investigated.

Ivancic, William D.↗
NASA NTRS2013

Advanced Exploration Systems Water Architecture Study Interim Results

The mission of the Advanced Exploration System (AES) Water Recovery Project (WRP) is to develop advanced water recovery systems that enable NASA human exploration missions beyond low Earth orbit (LEO). The primary objective of the AES WRP is to develop water recovery technologies critical to near-term missions beyond LEO. The secondary objective is to continue to advance mid-readiness-level technologies to support future NASA missions. An effort is being undertaken to establish the architecture for the AES Water Recovery System (WRS) that meets both near- and long-term objectives. The resultant architecture will be used to guide future technical planning, establish a baseline development roadmap for technology infusion, and establish baseline assumptions for integrated ground and on-orbit Environmental Control and Life Support Systems definition. This study is being performed in three phases. Phase I established the scope of the study through definition of the mission requirements and constraints, as well as identifying all possible WRS configurations that meet the mission requirements. Phase II focused on the near-term space exploration objectives by establishing an International Space Station-derived reference schematic for long-duration (>180 day) in-space habitation. Phase III will focus on the long-term space exploration objectives, trading the viable WRS configurations identified in Phase I to identify the ideal exploration WRS. The results of Phases I and II are discussed in this paper.

Sargusingh, Miriam J.↗
NASA NTRS1991

Toward autonomous driving: The CMU Navlab. II - Architecture and systems

A description is given of EDDIE, the architecture for the Navlab mobile robot which provides a toolkit for building specific systems quickly and easily. Included in the discussion are the annotated maps used by EDDIE and the Navlab's road-following system, called the Autonomous Mail Vehicle, which was built using EDDIE and its annotated maps as a basis. The contributions of the Navlab project and the lessons learned from it are examined.

Thorpe, Charles↗
NASA NTRS2003

A CDMA Spotbeam Architecture for the Next Generation Satellite System (NGSS) for the Aeronautical Telecommunications Network (ATN)

This paper will present work being done to model and simulate a CDMA based Mobile Satellite System architecture for providing all or part of the future Air Traffic Management (ATM) services. Such a system, will help in relieving the dependence on ground based networks, if not eliminate it. Additionally such an architecture can be used in parallel or as a supplementary service along with ground based links to help alleviate any capacity bottlenecks, or in areas where such services are difficult to make available such as in oceanic, remote areas outside the jet highways, or in developing countries where ground services are less available.

Raghavan, Rajesh S.↗
DOE OSTI2021

Supporting Co-Design of Extreme-Scale Systems with In Situ Visual Analysis of Event-Driven Simulations (Final Report)

Extreme-scale systems for compute- and data-centric science are pushing the boundaries of system architectures in order to achieve ambitious goals in terms of computing capability, resilience, and power efficiency. Future systems necessitate emerging designs that incorporate new technologies, system organizations, and computer science techniques, and these changes are not yet well understood. Discrete-event-driven simulation of computing system architectures and subsystems has emerged as a productive and cost-effective means to evaluating potential designs, along with capabilities for executing these simulations of extreme-scale systems. However, techniques for analyzing the behavior of these simulations have not kept pace with our ability to perform the simulations, preventing us from extracting the most value from this promising approach. The objective of this project is to support the codesign of extreme-scale system architectures for compute and data-centric science through research and development of novel methods for analysis and visualization of large-scale event-driven simulations.

97 MATHEMATICS AND COMPUTING↗
NASA NTRS1982

Step-oriented pipeline data processing system

Architecture for step-oriented pipeline data processing is disclosed utilizing a plurality of cascaded modules, each module including a programmable general purpose processor and a read/write random access memory. The memory of each module, shared with the next module in cascade serves as an output memory for the processor and the input memory for the next processor. An additional memory is provided to serve as the input memory of the first module, and each module is provided with a memory, which may be a read-out memory, to store a program for the processor. Each module is further provided with a logic network for resolving a potential memory sharing conflict by awarding priority to the processor of the module.

Castleman, Kenneth R.↗
DOE OSTI2020

The Dark Planets of the WASP-47 Planetary System

Exoplanet discoveries have demonstrated a vast range of planetary system architectures. The demographic of compact planetary systems are especially interesting from the perspective of planetary formation and the evolution of orbital dynamics. Another interesting demographic is that of giant planets in eccentric orbits, since these planets have likely had a dynamical history involving planet–planet scattering events. The WASP-47 system is particularly fascinating since it combines these two demographics, having both compact planetary orbits and a giant planet on an eccentric orbit within the system the habitable zone. Here we provide an analysis of the WASP-47 system from the perspective of atmospheric detection and characterization. We discuss the system architecture and the potential for additional long-period planets. We simulate expected phase variations as a function of planet orbital phase for the system due to the combined effect of the planets. We present an analysis of precision photometry of WASP-47 from the K2 mission, phased on each of the planets. The analysis rules out the detection of phase signatures for the two inner-most planets, enabling constraints upon their albedos and atmospheric properties. Our study concludes that WASP-47b is an example of a “dark” planet with a tentative geometric albedo of 0.016 and a 1σ upper limit of 0.17. The WASP-47e data are consistent with a broad range of albedos, but also show early evidence of having a relatively low albedo. The growing number of dark, short-period giant planets provide the framework of an ideal sample for studying low albedo dependence on atmospheric composition.

79 ASTRONOMY AND ASTROPHYSICS↗
NASA NTRS2011

Reverse Launch Abort System Parachute Architecture Trade Study

This study investigated a potential Launch Abort System (LAS) Concept of Operations and abort parachute architecture. The purpose of the study was to look at the concept of jettisoning the LAS tower forward (Reverse LAS or RLAS) into the free-stream flow rather than after reorienting to a heatshield forward orientation. A hypothesized benefit was that due to the compressed timeline the dynamic pressure at main line stretch would be substantially less. This would enable the entry parachutes to be designed and sized based on entry loading conditions rather than the current stressing case of a Pad Abort. Ultimately, concerns about the highly dynamic reorientation of the CM via parachutes, and the additional requirement of a triple bridle attachment for the RLAS parachute system, overshadowed the potential benefits and ended this effort.

Litton, Daniel K.↗
NASA NTRS1997

ASAC Executive Assistant Architecture Description Summary

In this technical document, we describe the system architecture developed for the Aviation System Analysis Capability (ASAC) Executive Assistant (EA). We describe the genesis and role of the ASAC system, discuss the objectives of the ASAC system and provide an overview of components and models within the ASAC system, discuss our choice for an architecture methodology, the Domain Specific Software Architecture (DSSA), and the DSSA approach to developing a system architecture, and describe the development process and the results of the ASAC EA system architecture. The document has six appendices.

Roberts, Eileen↗
NASA NTRS2011

Current Status of the Nitrogen Oxygen Recharge System

This paper presents an overview of the Nitrogen Oxygen Recharge System (NORS) to date and the current development status of the system. NORS is an element of the International Space Station (ISS) Environmental Control and Life Support Systems (ECLSS) used to resupply the ISS with Nitrogen and Oxygen following the impending retirement of the Space Shuttle. The paper will discuss why NASA is developing NORS, including a summary of other concepts considered, and other related concepts currently being developed by NASA. The current system architecture will be described, along with a summary of the current design of the NORS. The overall programmatic schedule of the NORS in the context of the upcoming shuttle retirement and future launch vehicle development will also be presented. Finally, the paper will examine the significant technical challenges encountered during the requirements and preliminary design phase of NORS development. A key challenge to the development of NORS is the international shipment - and associated regulations - of pressurized Oxygen, which is necessary due to the use of launch vehicles based in Japan and French Guiana to send NORS gasses to the ISS. The storage and use of relatively large quantities of high pressure (41,000 kPa) Oxygen and Nitrogen within the ISS, which is unprecedented both on the ISS and other space vehicles, has had a significant impact on the design and architecture of the system. The high pressure of the system also poses unique thermal considerations, which has led to the development of a heater system for thermal conditioning of high pressure gas to avoid thermal impacts on downstream hardware. The on-orbit envelope allocated to the NORS has changed (gotten smaller) and has impacted both the design and architecture of the system. Finally, the balance of safety considerations associated with these high pressure gasses, particularly high pressure Oxygen, with the functionality of the system has profoundly impacted the form of the system and will be discussed.

Dick, Brandon↗
NASA NTRS1983

Distributed asynchronous microprocessor architectures in fault tolerant integrated flight systems

The paper discusses the implementation of fault tolerant digital flight control and navigation systems for rotorcraft application. It is shown that in implementing fault tolerance at the systems level using advanced LSI/VLSI technology, aircraft physical layout and flight systems requirements tend to define a system architecture of distributed, asynchronous microprocessors in which fault tolerance can be achieved locally through hardware redundancy and/or globally through application of analytical redundancy. The effects of asynchronism on the execution of dynamic flight software is discussed. It is shown that if the asynchronous microprocessors have knowledge of time, these errors can be significantly reduced through appropiate modifications of the flight software. Finally, the papear extends previous work to show that through the combined use of time referencing and stable flight algorithms, individual microprocessors can be configured to autonomously tolerate intermittent faults.

Dunn, W. R.↗
DOE OSTI2021

Evaluating cyber-risk in synchrophasor systems

Technology related to evaluating cyber-risk for synchrophasor systems is disclosed. In one example of the disclosed technology, a method includes generating an event tree model of a timing-attack on a synchrophasor system architecture. The event tree model can be based on locations and types of timing-attacks, an attack likelihood, vulnerabilities and detectability along a scenario path, and consequences of the timing-attack. A cyber-risk score of the synchrophasor system architecture can be determined using the event tree model. The synchrophasor system architecture can be adapted in response to the cyber-risk score.

Pal, Seemita↗
NASA NTRS2015

Exploring Life Support Architectures for Evolution of Deep Space Human Exploration

Life support system architectures for long duration space missions are often explored analytically in the human spaceflight community to find optimum solutions for mass, performance, and reliability. But in reality, many other constraints can guide the design when the life support system is examined within the context of an overall vehicle, as well as specific programmatic goals and needs. Between the end of the Constellation program and the development of the "Evolvable Mars Campaign", NASA explored a broad range of mission possibilities. Most of these missions will never be implemented but the lessons learned during these concept development phases may color and guide future analytical studies and eventual life support system architectures. This paper discusses several iterations of design studies from the life support system perspective to examine which requirements and assumptions, programmatic needs, or interfaces drive design. When doing early concept studies, many assumptions have to be made about technology and operations. Data can be pulled from a variety of sources depending on the study needs, including parametric models, historical data, new technologies, and even predictive analysis. In the end, assumptions must be made in the face of uncertainty. Some of these may introduce more risk as to whether the solution for the conceptual design study will still work when designs mature and data becomes available.

Anderson, Molly↗
NASA NTRS2015

Exploring Life Support Architectures for Evolution of Deep Space Human Exploration

Life support system architectures for long duration space missions are often explored analytically in the human spaceflight community to find optimum solutions for mass, performance, and reliability. But in reality, many other constraints can guide the design when the life support system is examined within the context of an overall vehicle, as well as specific programmatic goals and needs. Between the end of the Constellation program and the development of the "Evolvable Mars Campaign", NASA explored a broad range of mission possibilities. Most of these missions will never be implemented but the lessons learned during these concept development phases may color and guide future analytical studies and eventual life support system architectures. This paper discusses several iterations of design studies from the life support system perspective to examine which requirements and assumptions, programmatic needs, or interfaces drive design. When doing early concept studies, many assumptions have to be made about technology and operations. Data can be pulled from a variety of sources depending on the study needs, including parametric models, historical data, new technologies, and even predictive analysis. In the end, assumptions must be made in the face of uncertainty. Some of these may introduce more risk as to whether the solution for the conceptual design study will still work when designs mature and data becomes available.

Anderson, Molly S.↗