Search NASA⌕ Search

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.

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 379 records · Page 21
All sourcesNASA NTRSDOE OSTI
NASA NTRS2017

Smashing the Stovepipe: Leveraging the GMSEC Open Architecture and Advanced IT Automation to Rapidly Prototype, Develop and Deploy Next-Generation Multi-Mission Ground Systems

Satellite/Payload Ground Systems - Typically highly-customized to a specific mission's use cases - Utilize hundreds (or thousands!) of specialized point-to-point interfaces for data flows / file transfers Documentation and tracking of these complex interfaces requires extensive time to develop and extremely high staffing costs Implementation and testing of these interfaces are even more cost-prohibitive, and documentation often lags behind implementation resulting in inconsistencies down the road With expanding threat vectors, IT Security, Information Assurance and Operational Security have become key Ground System architecture drivers New Federal security-related directives are generated on a daily basis, imposing new requirements on current / existing ground systems - These mandated activities and data calls typically carry little or no additional funding for implementation As a result, Ground System Sustaining Engineering groups and Information Technology staff continually struggle to keep up with the rolling tide of security Advancing security concerns and shrinking budgets are pushing these large stove-piped ground systems to begin sharing resources - I.e. Operational / SysAdmin staff, IT security baselines, architecture decisions or even networks / hosting infrastructure Refactoring these existing ground systems into multi-mission assets proves extremely challenging due to what is typically very tight coupling between legacy components As a result, many "Multi-Mission" ops. environments end up simply sharing compute resources and networks due to the difficulty of refactoring into true multi-mission systems Utilizing continuous integration / rapid system deployment technologies in conjunction with an open architecture messaging approach allows System Engineers and Architects to worry less about the low-level details of interfaces between components and configuration of systems GMSEC messaging is inherently designed to support multi-mission requirements, and allows components to aggregate data across multiple homogeneous or heterogeneous satellites or payloads - The highly-successful Goddard Science and Planetary Operations Control Center (SPOCC) utilizes GMSEC as the hub for it's automation and situational awareness capability Shifts focus towards getting GS to a final configuration-managed baseline, as well as multi-mission / big-picture capabilities that help increase situational awareness, promote cross-mission sharing and establish enhanced fleet management capabilities across all levels of the enterprise.

GMSEC↗
NASA NTRS1996

A Mission Operations Architecture for the 21st Century

A new operations architecture for low cost missions is proposed, to build a framework to enable NASA to face its major challenges beond 2000. This architecture is composed of three elements: Service Based Architecture, Demand Access Automation, Distributed Science Hubs.

operations↗
NASA NTRS2003

Reference architecture for space data systems

Architectures for terrestrial data systems that are built and managed by a single organization are inherently complex. In order to understand any large-scale system architecture, and to judge its applicability for its nominal task, a description of the system must be produced that exposes a number of distinct viewpoints. Within the CCSDS Architecture Working Group we have adapted the Reference Model for Open Distributed Processing to describe large, multi-national, space data systems.

CCSDS space communication reference architecture s↗
NASA NTRS2004

Separating essentials from incidentals: an execution architecture for real-time control systems

This paper describes an execution architecture that makes such systems far more analyzable and verifiable by aggressive separation of concerns. The architecture separates two key software concerns: transformations of global state, as defined in pure functions; and sequencing/timing of transformations, as performed by an engine that enforces four prime invariants. The important advantage of this architecture, besides facilitating verification, is that it encourages formal specification of systems in a vocabulary that brings systems engineering closer to software engineering.

execution architecture↗
NASA NTRS2008

Architecture Study on Telemetry Coverage for Immediate Post-Separation Phase

This document is the viewgraphs that accompanies a paper that presents the preliminary results of an architecture study that provides continuous telemetry coverage for NASA missions for immediate post-separation phase. After launch when the spacecraft separated from the upper stage, the spacecraft typically executes a number of mission-critical operations prior to the deployment of solar panels and the activation of the primary communication subsystem. JPL, GSFC, and APL have similar design principle statements that require continuous coverage of mission-critical telemetry during the immediate post-separation phase. To conform to these design principles, an architecture that consists of a separate spacecraft transmitter and a robust communication network capable of tracking the spacecraft signals is needed. The main results of this study are as follows: 1) At low altitude (< 10000 km) when most post-separation critical operations are executed, Earth-based network (e.g. Deep Space Network (DSN)) can only provide limited coverage, whereas space-based network (e.g. Space Network (SN)) can provide continuous coverage. 2) Commercial-off-the-shelf SN compatible transmitters are available for small satellite applications. In this paper we present the detailed coverage analysis of Earth-based and Space-based networks. We identify the key functional and performance requirements of the architecture, and describe the proposed selection criteria of the spacecraft transmitter. We conclude the paper with a proposed forward plan.

architecture↗
NASA NTRS2011

Integration of the Reconfigurable Self-Healing eDNA Architecture in an Embedded System

In this work we describe the first real world case study for the self-healing eDNA (electronic DNA) architecture by implementing the control and data processing of a Fourier Transform Spectrometer (FTS) on an eDNA prototype. For this purpose the eDNA prototype has been ported from a Xilinx Virtex 5 FPGA to an embedded system consisting of a PowerPC and a Xilinx Virtex 5 FPGA. The FTS instrument features a novel liquid crystal waveguide, which consequently eliminates all moving parts from the instrument. The addition of the eDNA architecture to do the control and data processing has resulted in a highly fault-tolerant FTS instrument. The case study has shown that the early stage prototype of the autonomous self-healing eDNA architecture is expensive in terms of execution time.

Computer architecture↗
NASA NTRS2011

Autonomous Dynamically Self-Organizing and Self-Healing Distributed Hardware Architecture - the eDNA Concept

This paper presents the current state of the autonomous dynamically self-organizing and self-healing electronic DNA (eDNA) hardware architecture (patent pending). In its current prototype state, the eDNA architecture is capable of responding to multiple injected faults by autonomously reconfiguring itself to accommodate the fault and keep the application running. This paper will also disclose advanced features currently available in the simulation model only. These features are future work and will soon be implemented in hardware. Finally we will describe step-by-step how an application is implemented on the eDNA architecture.

self-healing hardware↗
NASA NTRS2013

Service Oriented Robotic Architecture for Space Robotics: Design, Testing, and Lessons Learned

This paper presents the lessons learned from six years of experiments with planetary rover prototypes running the Service Oriented Robotic Architecture (SORA) developed by the Intelligent Robotics Group (IRG) at the NASA Ames Research Center. SORA relies on proven software engineering methods and technologies applied to space robotics. Based on a Service Oriented Architecture and robust middleware, SORA encompasses on-board robot control and a full suite of software tools necessary for remotely operated exploration missions. SORA has been eld tested in numerous scenarios of robotic lunar and planetary exploration. The experiments conducted by IRG with SORA exercise a large set of the constraints encountered in space applications: remote robotic assets, ight relevant science instruments, distributed operations, high network latencies and unreliable or intermittent communication links. In this paper, we present the results of these eld tests in regard to the developed architecture, and discuss its bene ts and limitations.

service oriented architecture↗
NASA NTRS2014

Space Telecommunications Radio System (STRS) Architecture, Tutorial Part 2 - Detailed

The STRS architecture detail presentation presents each requirement in the STRS Architecture Standard with some examples and supporting information. The purpose is to give a platform provider, application provider, or application integrator a better, more detailed understanding of the STRS Architecture Standard and its use.

Architecture (computers)↗
NASA NTRS2017

Model-Driven Development of Safety Architectures

We describe the use of model-driven development for safety assurance of a pioneering NASA flight operation involving a fleet of small unmanned aircraft systems (sUAS) flying beyond visual line of sight. The central idea is to develop a safety architecture that provides the basis for risk assessment and visualization within a safety case, the formal justification of acceptable safety required by the aviation regulatory authority. A safety architecture is composed from a collection of bow tie diagrams (BTDs), a practical approach to manage safety risk by linking the identified hazards to the appropriate mitigation measures. The safety justification for a given unmanned aircraft system (UAS) operation can have many related BTDs. In practice, however, each BTD is independently developed, which poses challenges with respect to incremental development, maintaining consistency across different safety artifacts when changes occur, and in extracting and presenting stakeholder specific information relevant for decision making. We show how a safety architecture reconciles the various BTDs of a system, and, collectively, provide an overarching picture of system safety, by considering them as views of a unified model. We also show how it enables model-driven development of BTDs, replete with validations, transformations, and a range of views. Our approach, which we have implemented in our toolset, AdvoCATE, is illustrated with a running example drawn from a real UAS safety case. The models and some of the innovations described here were instrumental in successfully obtaining regulatory flight approval.

Safety case↗
NASA NTRS2019

Cost Breakeven Analysis of Lunar ISRU for Human Lunar Surface Architectures

The return of humans to the lunar surface encompasses a range of possible architectures from brief Apollo-like sorties to long-term sustainment of human presence. Any architecture in this span requires propellant for the crew’s ascent from the lunar surface, as well as consumables to support their presence on the Moon. Oxygen and hydrogen are candidates for the propellant for the ascent vehicle due to their high specific impulse and potential for production from lunar resources and also constitute important consumables for the crew. Thus, the production of oxygen and/or hydrogen from lunar resources could significantly reduce the mass that must be sent from Earth to enable future human lunar missions. To assess the merits of using lunar resources, the costs associated with developing, producing, launching, operating, and maintaining those systems must be considered relative to the costs of delivering the needed resources from Earth. The demand for those resources depends upon the nature of the lunar mission, while the costs of both Earth-derived and lunar-derived resources depend on the performance requirements and technology capabilities associated with each approach. Thus, determining which approach is more cost efficient requires modeling the performance and cost of the associated systems as well as the range of possible architectures over which such a determination might apply. This research proposes a model that parametrically captures the factors influencing the relevant costs of providing propellant and crew consumables on the lunar surface from Earth and from the Moon. Two ISRU system models are assessed relative to propellant delivery from Earth. In this model, lunar ISRU breaks even with propellant delivery from Earth at high propellant demands and mission durations with multi-year ISRU system lifetimes; however, the costs of developing the necessary technologies to support a highly reliable and autonomous lunar ISRU system were not included.

ISRU↗
NASA NTRSDate not supplied

Internal Architecture of the Common Habitat

The core stage liquid oxygen tank of the Space Launch System can be manufactured as a habitat instead of as a propellant tank, with a common design such that it is equally suitable for use in 0g, 1/6g, 3/8g, 1g, or variable artificial gravity. This Common Habitat can be the central element of a human spaceflight architecture that encompasses the Moon, Mars, and other destinations within the inner solar system. The Common Habitat is specifically used within an alternative architecture study (that is not part of the current NASA baseline) as the core habitation element within a Lunar Basecamp, Mars Basecamp, and the Deep Space Exploration Vehicle. The Common Habitat internal architecture applies a design philosophy to separate crew functions according to deck. The lower deck is reserved for private functions. It includes eight private crew quarters and four waste and hygiene clusters – each with a private waste management compartment, private full body hygiene compartment, and foyer/clothes changing area. The mid deck is primarily allocated to mission-related working functions. It includes an exercise facility, fabrication / maintenance / repair facility, physical science laboratory (physics, geology, and astronomy), and life science laboratory (biology and human research). The mid deck also has four external hatches, clocked one every 90 degrees, centered on the vehicle vertical centerline. Each hatch has a 60-inch tall by 40-inch wide opening with the mid deck floor 16 inches below the bottom lip of the hatch opening. The upper deck is primarily allocated to group or social functions. It includes a large galley, wardroom with projector and display screen, plant growth chambers, bulk stowage, command and control station, medical facility, hygiene compartment, and vehicle subsystems. A Vertical Translation System, based in part on results from a GrabCAD public challenge, enables crew and equipment traverse between habitat decks in 0g, 1/6g, 3/8g, and 1g. A 40-inch by 60-inch vertical translation corridor ensures that anything that can fit through the external hatches can also be moved from deck to deck. The system includes three component systems: a deploying floor to safety barrier system that folds down to become a traversable floor when vertical translation is not in use and deploys to become a safety barrier during vertical translations; a folding ladder that stows in the ceiling when not in use; and an elevator platform that can attach to the ladder for cargo or incapacitated crew member transport. This system is complemented by a Horizontal Translation System, also based in part on the same GrabCAD challenge, provides for horizontal crew translation in microgravity but requires no vehicle reconfiguration for fractional or whole gravity operation. It relies primarily on gecko-inspired grippers, originally developed at Stanford and NASA JPL, attached to footwear to enable crew to emulate walking. Some handrails are also strategically placed throughout the Common Habitat to aid translation in both gravity and microgravity environments.

Common Habitat↗
NASA NTRS2024

Crew Health and Performance Integrated Data Architecture (CHP-IDA) Project

BACKGROUND: Future Human Exploration missions introduce a new paradigm as crews move further from the resupply and near real-time ground support typical of Low Earth Orbit missions today. Without immediate support from ground-based personnel, exploration crews will be more reliant on inflight data and technology to respond to emergencies and anomalies. A data architecture to support a new generation of technologies, employing advanced analytical and predictive modeling techniques, is needed to enable crew autonomy. OVERVIEW: The Crew Health and Performance Integrated Data Architecture (CHP-IDA) project funded by NASA’s Exploration Medical Integrated Product Team (XMIPT) is laying a foundation for future in-flight informatics by providing a back-end architecture for collecting, storing, and integrating multiple sources of data generated by and around the crew. CHP-IDA provides a platform for common data models and Application Programming Interfaces to access, integrate, process, and display CHP data (e.g., environmental, exercise, medical, sleep, performance, etc.). This will facilitate the increased situation awareness and decision support required by the crew and remote support of exploration missions. This presentation will describe the currently ongoing effort to develop and evaluate a path-to-flight concept of the CHP-IDA software and its core capabilities. Current integrations will be discussed, including analytics for Extravehicular Activity metabolic rate and data ingestion from a multi-functional integrated medical device. The presentation will also provide examples of scenarios used to demonstrate the CHP-IDA through human-in-the-loop test bed activities as well as examples of appropriate system performance metrics. DISCUSSION: Today, in-flight data is often siloed, unsynchronized, and largely inaccessible in real time. Many data sets require manual entry and/or data transfer between vehicles and the ground. These issues contribute to risks in supporting exploration medical capabilities. The CHP-IDA is a back-end data system providing core capabilities needed for timely and meaningful data insights across CHP domains to crew and remote personnel to enable increased crew autonomy. Future work includes collaboration with additional CHP domains, new technology integrations, and further demonstrations of the IDA within different vehicle and communication latency contexts. LEARNING OBJECTIVES 1. The audience will understand that the CHP-IDA is a back-end system, providing a platform to facilitate access, promote decision tools, and provide meaningful insights to crew and to remote stakeholders during exploration missions. 2. The audience will gain insight into human-centered research and activities used to discover CHP domain data needs and pain points and how this information is used to guide development of the IDA.

Exploration↗
NASA NTRS1973

Design of a fault tolerant airborne digital computer. Volume 1: Architecture

This volume is concerned with the architecture of a fault tolerant digital computer for an advanced commercial aircraft. All of the computations of the aircraft, including those presently carried out by analogue techniques, are to be carried out in this digital computer. Among the important qualities of the computer are the following: (1) The capacity is to be matched to the aircraft environment. (2) The reliability is to be selectively matched to the criticality and deadline requirements of each of the computations. (3) The system is to be readily expandable. contractible, and (4) The design is to appropriate to post 1975 technology. Three candidate architectures are discussed and assessed in terms of the above qualities. Of the three candidates, a newly conceived architecture, Software Implemented Fault Tolerance (SIFT), provides the best match to the above qualities. In addition SIFT is particularly simple and believable. The other candidates, Bus Checker System (BUCS), also newly conceived in this project, and the Hopkins multiprocessor are potentially more efficient than SIFT in the use of redundancy, but otherwise are not as attractive.

Wensley, J. H.↗
NASA NTRS1978

Technology advances and market forces: Their impact on high performance architectures

Reasonable projections into future supercomputer architectures and technology require an analysis of the computer industry market environment, the current capabilities and trends within the component industry, and the research activities on computer architecture in the industrial and academic communities. Management, programmer, architect, and user must cooperate to increase the efficiency of supercomputer development efforts. Care must be taken to match the funding, compiler, architecture and application with greater attention to testability, maintainability, reliability, and usability than supercomputer development programs of the past.

Best, D. R.↗
NASA NTRS1982

A study of the selection of microcomputer architectures to automate planetary spacecraft power systems

Performance and reliability models of alternate microcomputer architectures as a methodology for optimizing system design were examined. A methodology for selecting an optimum microcomputer architecture for autonomous operation of planetary spacecraft power systems was developed. Various microcomputer system architectures are analyzed to determine their application to spacecraft power systems. It is suggested that no standardization formula or common set of guidelines exists which provides an optimum configuration for a given set of specifications.

Nauda, A.↗
NASA NTRS1982

A parallel VLSI architecture for a digital filter of arbitrary length using Fermat number transforms

A parallel architecture for computation of the linear convolution of two sequences of arbitrary lengths using the Fermat number transform (FNT) is described. In particular a pipeline structure is designed to compute a 128-point FNT. In this FNT, only additions and bit rotations are required. A standard barrel shifter circuit is modified so that it performs the required bit rotation operation. The overlap-save method is generalized for the FNT to compute a linear convolution of arbitrary length. A parallel architecture is developed to realize this type of overlap-save method using one FNT and several inverse FNTs of 128 points. The generalized overlap save method alleviates the usual dynamic range limitation in FNTs of long transform lengths. Its architecture is regular, simple, and expandable, and therefore naturally suitable for VLSI implementation.

Truong, T. K.↗
NASA NTRS1982

Architectural options for space stations in the context of the space infrastructure

The role of space stations in the space element infrastructure anticipated for the end of the 20th century is discussed. Various architectures for space stations designed to function as part of the infrastructure are examined with respect to a set of potential objectives for the stations. Architectural options are described that range from a minimum station of low capability and cost to an expensive station with a full operations capability and high growth potential. The capabilities, growth potentials, and likely costs of the options are compared, and the association between functional capabilities and likely cost is considered. It is concluded that the cost of a space station is intimately related to its architecture and that a larger initial investment must be made to satisfy more ambitious objectives.

Bekey, I.↗