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 487 records · Page 27
All sourcesNASA NTRSDOE OSTI
NASA NTRS1997

Implementation of Helioseismic Data Reduction and Diagnostic Techniques on Massively Parallel Architectures

Under the direction of Dr. Rhodes, and the technical supervision of Dr. Korzennik, the data assimilation of high spatial resolution solar dopplergrams has been carried out throughout the program on the Intel Delta Touchstone supercomputer. With the help of a research assistant, partially supported by this grant, and under the supervision of Dr. Korzennik, code development was carried out at SAO, using various available resources. To ensure cross-platform portability, PVM was selected as the message passing library. A parallel implementation of power spectra computation for helioseismology data reduction, using PVM was successfully completed. It was successfully ported to SMP architectures (i.e. SUN), and to some MPP architectures (i.e. the CM5). Due to limitation of the implementation of PVM on the Cray T3D, the port to that architecture was not completed at the time.

Korzennik, Sylvain↗
NASA NTRS1998

Human Mars Missions: Cost Driven Architecture Assessments

This report investigates various methods of reducing the cost in space transportation systems for human Mars missions. The reference mission for this task is a mission currently under study at NASA. called the Mars Design Reference Mission, characterized by In-Situ propellant production at Mars. This study mainly consists of comparative evaluations to the reference mission with a view to selecting strategies that would reduce the cost of the Mars program as a whole. One of the objectives is to understand the implications of certain Mars architectures, mission modes, vehicle configurations, and potentials for vehicle reusability. The evaluations start with year 2011-2014 conjunction missions which were characterized by their abort-to-the-surface mission abort philosophy. Variations within this mission architecture, as well as outside the set to other architectures (not predicated on an abort to surface philosophy) were evaluated. Specific emphasis has been placed on identifying and assessing overall mission risk. Impacts that Mars mission vehicles might place upon the Space Station, if it were to be used as an assembly or operations base, were also discussed. Because of the short duration of this study only on a few propulsion elements were addressed (nuclear thermal, cryogenic oxygen-hydrogen, cryogenic oxygen-methane, and aerocapture). Primary ground rules and assumptions were taken from NASA material used in Marshall Space Flight Center's own assessment done in 1997.

Interplanetary Mission↗
NASA NTRS1999

Partitioning in Avionics Architectures: Requirements, Mechanisms, and Assurance

Automated aircraft control has traditionally been divided into distinct "functions" that are implemented separately (e.g., autopilot, autothrottle, flight management); each function has its own fault-tolerant computer system, and dependencies among different functions are generally limited to the exchange of sensor and control data. A by-product of this "federated" architecture is that faults are strongly contained within the computer system of the function where they occur and cannot readily propagate to affect the operation of other functions. More modern avionics architectures contemplate supporting multiple functions on a single, shared, fault-tolerant computer system where natural fault containment boundaries are less sharply defined. Partitioning uses appropriate hardware and software mechanisms to restore strong fault containment to such integrated architectures. This report examines the requirements for partitioning, mechanisms for their realization, and issues in providing assurance for partitioning. Because partitioning shares some concerns with computer security, security models are reviewed and compared with the concerns of partitioning.

Rushby, John↗
NASA NTRS1998

An Analysis of an Improved Bus-Based Multiprocessor Architecture

This paper analyses the effectiveness of a hybrid multiprocessing/multicomputing architecture that is based upon a single-board-computer multiprocessor (SBCM) architecture. Based upon empirical analysis using discrete event simulations and Monte Carlo techniques, this hybrid architecture, called the enhanced single-board-computer multiprocessor (ESBCM), is shown to have improved performance and scalability characteristics over current SBCM designs.

Ricks, Kenneth G.↗
NASA NTRS1999

An Integrated Architecture for Onboard Spacecraft

As increasingly complex scientific and environmental observation spacecraft are deployed, the burden on the downlink assets, and ground-based systems complexity and cost is becoming a major problem. Already, the limitations of communications bandwidth and processing throughput limit the science data gathering, both in volume and in rate. This poses a dilemma to the scientist experimenter forcing choices between data collection and bandwidth/processing/archiving. Advances in ground based processing and space-to-Earth links have fallen behind the requirements for observation data, at increasing rates, over the last few decades. As NASA achieves its 40th anniversary, the ability to observe and capture phenomena of theoretical and practical interest to life on Earth far outstrips the ability to transfer, process, or store these data. NASA recognizes the need to invest on technological advancements that will enable both the space and ground systems to address the limitations. Spacecraft onboard computing power is a clear one. The capability of creating data products onboard the spacecraft adds a new level of flexibility to address the more demanding observation needs. Current spacecraft computing power is limited and incapable of addressing the needs of the new generation of observation satellites because extensive onboard data processing is required. Traditional spacecraft architectures only collect, package, and transmit to Earth the data acquired by multiple instruments. Conversely, the experience on developing ground data systems shows the need for high performance computing systems to process and create information from the instrumentation data. The expectation is that supercomputing technology is required to enable spacecraft to create information onboard. Moving supercomputing capability onboard spacecraft requires an approach that considers an integrated data architecture. Otherwise, it may simply convert a compute-bound problem into a communications bound problem, as has been shown numerous times in the context of massively parallel architectures. What is left to determine are the technologies that will enable spacecraft high performance computing.

Figueiredo, Marco A.↗
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 NTRS1986

Integrating Computer Architectures into the Design of High-Performance Controllers

Modern control systems must typically perform real-time identification and control, as well as coordinate a host of other activities related to user interaction, on-line graphics, and file management. This paper discusses five global design considerations that are useful to integrate array processor, multimicroprocessor, and host computer system architecture into versatile, high-speed controllers. Such controllers are capable of very high control throughput, and can maintain constant interaction with the non-real-time or user environment. As an application example, the architecture of a high-speed, closed-loop controller used to actively control helicopter vibration will be briefly discussed. Although this system has been designed for use as the controller for real-time rotorcraft dynamics and control studies in a wind-tunnel environment, the control architecture can generally be applied to a wide range of automatic control applications.

Jacklin, Stephen A.↗
NASA NTRS1999

Analog Module Architecture for Space-Qualified Field-Programmable Mixed-Signal Arrays

Spacecraft require all manner of both digital and analog circuits. Onboard digital systems are constructed almost exclusively from field-programmable gate array (FPGA) circuits providing numerous advantages over discrete design including high integration density, high reliability, fast turn-around design cycle time, lower mass, volume, and power consumption, and lower parts acquisition and flight qualification costs. Analog and mixed-signal circuits perform tasks ranging from housekeeping to signal conditioning and processing. These circuits are painstakingly designed and built using discrete components due to a lack of options for field-programmability. FPAA (Field-Programmable Analog Array) and FPMA (Field-Programmable Mixed-signal Array) parts exist but not in radiation-tolerant technology and not necessarily in an architecture optimal for the design of analog circuits for spaceflight applications. This paper outlines an architecture proposed for an FPAA fabricated in an existing commercial digital CMOS process used to make radiation-tolerant antifuse-based FPGA devices. The primary concerns are the impact of the technology and the overall array architecture on the flexibility of programming, the bandwidth available for high-speed analog circuits, and the accuracy of the components for high-performance applications.

Edwards, R. Timothy↗
NASA NTRS1999

Design Description of the X-33 Avionics Architecture

In this paper, we provide a design description of the X-33 avionics architecture. The X-33 is an autonomous Single Stage to Orbit (SSTO) launch vehicle currently being developed by Lockheed Martin for NASA as a technology demonstrator for the VentureStar Reusable Launch Vehicle (RLV). The X-33 avionics provides autonomous control of die vehicle throughout takeoff, ascent, descent, approach, landing, rollout, and vehicle safing. During flight the avionics provides communication to the range through uplinked commands and downlinked telemetry. During pre-launch and post-safing activities, the avionics provides interfaces to ground support consoles that perform vehicle flight preparations and maintenance. The X-33 Avionics is a hybrid of centralized and distributed processing elements connected by three dual redundant Mil-Std 1553 data buses. These data buses are controlled by a central processing suite located in the avionics bay and composed of triplex redundant Vehicle Mission Computers (VMCs). The VMCs integrate mission management, guidance, navigation, flight control, subsystem control and redundancy management functions. The vehicle sensors, effectors and subsystems are interfaced directly to the centralized VMCs as remote terminals or through dual redundant Data Interface Units (DIUs). The DIUs are located forward and aft of the avionics bay and provide signal conditioning, health monitoring, low level subsystem control and data interface functions. Each VMC is connected to all three redundant 1553 data buses for monitoring and provides a complete identical data set to the processing algorithms. This enables bus faults to be detected and reconfigured through a voted bus control configuration. Data is also shared between VMCs though a cross channel data link that is implemented in hardware and controlled by AlliedSignal's Fault Tolerant Executive (FTE). The FTE synchronizes processors within the VMC and synchronizes redundant VMCs to each other. The FTE provides an output-voting plane to detect, isolate and contain faults due to internal hardware or software faults and reconfigures the VMCs to accommodate these faults. Critical data in the 1553 messages are scheduled and synchronized to specific processing frames in order to minimize data latency. In order to achieve an open architecture, military and commercial off-the-shelf equipment is incorporated using common processors, standard VME backplanes and chassis, the VxWorks operating system, and MartixX for automatic code generation. The use of off-the-shelf tools and equipment helps reduce development time and enables software reuse. The open architecture allows for technology insertion, while the distributed modular elements allow for expansion to increased redundancy levels to meet the higher reliability goals of future RLVs.

Reichenfeld, Curtis J.↗
NASA NTRS2000

The Design of a Fault-Tolerant COTS-Based Bus Architecture for Space Applications

The high-performance, scalability and miniaturization requirements together with the power, mass and cost constraints mandate the use of commercial-off-the-shelf (COTS) components and standards in the X2000 avionics system architecture for deep-space missions. In this paper, we report our experiences and findings on the design of an IEEE 1394 compliant fault-tolerant COTS-based bus architecture. While the COTS standard IEEE 1394 adequately supports power management, high performance and scalability, its topological criteria impose restrictions on fault tolerance realization. To circumvent the difficulties, we derive a "stack-tree" topology that not only complies with the IEEE 1394 standard but also facilitates fault tolerance realization in a spaceborne system with limited dedicated resource redundancies. Moreover, by exploiting pertinent standard features of the 1394 interface which are not purposely designed for fault tolerance, we devise a comprehensive set of fault detection mechanisms to support the fault-tolerant bus architecture.

Chau, Savio N.↗
NASA NTRS2000

Autonomy Architectures for a Constellation of Spacecraft

Until the past few years, missions typically involved fairly large expensive spacecraft. Such missions have primarily favored using older proven technologies over more recently developed ones, and humans controlled spacecraft by manually generating detailed command sequences with low-level tools and then transmitting the sequences for subsequent execution on a spacecraft controller. This approach toward controlling a spacecraft has worked spectacularly on previous missions, but it has limitations deriving from communications restrictions - scheduling time to communicate with a particular spacecraft involves competing with other projects due to the limited number of deep space network antennae. This implies that a spacecraft can spend a long time just waiting whenever a command sequence fails. This is one reason why the New Millennium program has an objective to migrate parts of mission control tasks onboard a spacecraft to reduce wait time by making spacecraft more robust. The migrated software is called a "remote agent" and has 4 components: a mission manager to generate the high level goals, a planner/scheduler to turn goals into activities while reasoning about future expected situations, an executive/diagnostics engine to initiate and maintain activities while interpreting sensed events by reasoning about past and present situations, and a conventional real-time subsystem to interface with the spacecraft to implement an activity's primitive actions. In addition to needing remote planning and execution for isolated spacecraft, a trend toward multiple-spacecraft missions points to the need for remote distributed planning and execution. The past few years have seen missions with growing numbers of probes. Pathfinder has its rover (Sojourner), Cassini has its lander (Huygens), and the New Millenium Deep Space 3 (DS3) proposal involves a constellation of 3 spacecraft for interferometric mapping. This trend is expected to continue to progressively larger fleets. For example, one mission proposed to succeed DS3 would have 18 spacecraft flying in formation in order to detect earth-sized planets orbiting other stars. A proposed magnetospheric constellation would involve 5 to 500 spacecraft in Earth orbit to measure global phenomena within the magnetosphere. This work describes and compares three autonomy architectures for a system that continuously plans to control a fleet of spacecraft using collective mission goals instead of goals or command sequences for each spacecraft. A fleet of self-commanding spacecraft would autonomously coordinate itself to satisfy high level science and engineering goals in a changing partially-understood environment making feasible the operation of tens or even a hundred spacecraft (such as for interferometry or plasma physics missions). The easiest way to adapt autonomous spacecraft research to controlling constellations involves treating the constellation as a single spacecraft. Here one spacecraft directly controls the others as if they were connected. The controlling "master" spacecraft performs all autonomy reasoning, and the slaves only have real-time subsystems to execute the master's commands and transmit local telemetry/observations. The executive/diagnostics module starts actions and the master's real-time subsystem controls the action either locally or remotely through a slave. While the master/slave approach benefits from conceptual simplicity, it relies on an assumption that the master spacecraft's executive can continuously monitor the slaves' real-time subsystems, and this relies on high-bandwidth highly-reliable communications. Since unintended results occur fairly rarely, one way to relax the bandwidth requirements involves only monitoring unexpected events in spacecraft. Unfortunately, this disables the ability to monitor for unexpected events between spacecraft and leads to a host of coordination problems among the slaves. Also, failures in the communications system can result in losing slaves. The other two architectures improve robustness while reducing communications by progressively distributing more of the other three remote agent components across the constellation. In a teamwork architecture, all spacecraft have executives and real-time subsystems - only the leader has the planner/scheduler and mission manager. Finally, distributing all remote agent components leads to a peer-to-peer approach toward constellation control.

Barrett, Anthony↗
NASA NTRS2000

COTS-Based Fault Tolerance in Deep Space: Qualitative and Quantitative Analyses of a Bus Network Architecture

Using COTS products, standards and intellectual properties (IPs) for all the system and component interfaces is a crucial step toward significant reduction of both system cost and development cost as the COTS interfaces enable other COTS products and IPs to be readily accommodated by the target system architecture. With respect to the long-term survivable systems for deep-space missions, the major challenge for us is, under stringent power and mass constraints, to achieve ultra-high reliability of the system comprising COTS products and standards that are not developed for mission-critical applications. The spirit of our solution is to exploit the pertinent standard features of a COTS product to circumvent its shortcomings, though these standard features may not be originally designed for highly reliable systems. In this paper, we discuss our experiences and findings on the design of an IEEE 1394 compliant fault-tolerant COTS-based bus architecture. We first derive and qualitatively analyze a -'stacktree topology" that not only complies with IEEE 1394 but also enables the implementation of a fault-tolerant bus architecture without node redundancy. We then present a quantitative evaluation that demonstrates significant reliability improvement from the COTS-based fault tolerance.

Tai, Ann T.↗
NASA NTRS2000

Streamlining Collaborative Planning in Spacecraft Mission Architectures

During the past two decades, the planning and scheduling community has substantially increased the capability and efficiency of individual planning and scheduling systems. Relatively recently, research work to streamline collaboration between planning systems is gaining attention. Spacecraft missions stand to benefit substantially from this work as they require the coordination of multiple planning organizations and planning systems. Up to the present time this coordination has demanded a great deal of human intervention and/or extensive custom software development efforts. This problem will become acute with increased requirements for cross-mission plan coordination and multi -spacecraft mission planning. The Advanced Architectures and Automation Branch of NASA's Goddard Space Flight Center is taking innovative steps to define collaborative planning architectures, and to identify coordinated planning tools for Cross-Mission Campaigns. Prototypes are being developed to validate these architectures and assess the usefulness of the coordination tools by the planning community. This presentation will focus on one such planning coordination too], named Visual Observation Layout Tool (VOLT), which is currently being developed to streamline the coordination between astronomical missions

Misra, Dhariti↗
NASA NTRS1997

Integrity Constraint Monitoring in Software Development: Proposed Architectures

In the development of complex software systems, designers are required to obtain from many sources and manage vast amounts of knowledge of the system being built and communicate this information to personnel with a variety of backgrounds. Knowledge concerning the properties of the system, including the structure of, relationships between and limitations of the data objects in the system, becomes increasingly more vital as the complexity of the system and the number of knowledge sources increases. Ensuring that violations of these properties do not occur becomes steadily more challenging. One approach toward managing the enforcement or system properties, called context monitoring, uses a centralized repository of integrity constraints and a constraint satisfiability mechanism for dynamic verification of property enforcement during program execution. The focus of this paper is to describe possible software architectures that define a mechanism for dynamically checking the satisfiability of a set of constraints on a program. The next section describes the context monitoring approach in general. Section 3 gives an overview of the work currently being done toward the addition of an integrity constraint satisfiability mechanism to a high-level program language, SequenceL, and demonstrates how this model is being examined to develop a general software architecture. Section 4 describes possible architectures for a general constraint satisfiability mechanism, as well as an alternative approach that, uses embedded database queries in lieu of an external monitor. The paper concludes with a brief summary outlining the, current state of the research and future work.

Fernandez, Francisco G.↗
NASA NTRS2000

Communications System Architecture Development for Air Traffic Management and Aviation Weather Information Dissemination

This document is the NASA AATT Task Order 24 Final Report. NASA Research Task Order 24 calls for the development of eleven distinct task reports. Each task was a necessary exercise in the development of comprehensive communications systems architecture (CSA) for air traffic management and aviation weather information dissemination for 2015, the definition of the interim architecture for 2007, and the transition plan to achieve the desired End State. The eleven tasks are summarized along with the associated Task Order reference. The output of each task was an individual task report. The task reports that make up the main body of this document include Task 5, Task 6, Task 7, Task 8, Task 10, and Task 11. The other tasks provide the supporting detail used in the development of the architecture. These reports are included in the appendices. The detailed user needs, functional communications requirements and engineering requirements associated with Tasks 1, 2, and 3 have been put into a relational database and are provided electronically.

Gallagher, Seana↗
NASA NTRS1999

Alternative Architectures for Distributed Cooperative Problem-Solving in the National Airspace System

The air traffic management system in the United States is an example of a distributed problem solving system. It has elements of both cooperative and competitive problem-solving. This system includes complex organizations such as Airline Operations Centers (AOCs), the FAA Air Traffic Control Systems Command Center (ATCSCC), and traffic management units (TMUs) at enroute centers and TRACONs, all of which have a major focus on strategic decision-making. It also includes individuals concerned more with tactical decisions (such as air traffic controllers and pilots). The architecture for this system has evolved over time to rely heavily on the distribution of tasks and control authority in order to keep cognitive complexity manageable for any one individual operator, and to provide redundancy (both human and technological) to serve as a safety net to catch the slips or mistakes that any one person or entity might make. Currently, major changes are being considered for this architecture, especially with respect to the locus of control, in an effort to improve efficiency and safety. This paper uses a series of case studies to help evaluate some of these changes from the perspective of system complexity, and to point out possible alternative approaches that might be taken to improve system performance. The paper illustrates the need to maintain a clear understanding of what is required to assure a high level of performance when alternative system architectures and decompositions are developed.

Smith, Phillip J.↗
NASA NTRS1998

Exploring Gigabyte Datasets in Real Time: Architectures, Interfaces and Time-Critical Design

Architectures and Interfaces: The implications of real-time interaction on software architecture design: decoupling of interaction/graphics and computation into asynchronous processes. The performance requirements of graphics and computation for interaction. Time management in such an architecture. Examples of how visualization algorithms must be modified for high performance. Brief survey of interaction techniques and design, including direct manipulation and manipulation via widgets. talk discusses how human factors considerations drove the design and implementation of the virtual wind tunnel. Time-Critical Design: A survey of time-critical techniques for both computation and rendering. Emphasis on the assignment of a time budget to both the overall visualization environment and to each individual visualization technique in the environment. The estimation of the benefit and cost of an individual technique. Examples of the modification of visualization algorithms to allow time-critical control.

Bryson, Steve↗
NASA NTRS2002

A Facility and Architecture for Autonomy Research

Autonomy is a key enabling factor in the advancement of the remote robotic exploration. There is currently a large gap between autonomy software at the research level and software that is ready for insertion into near-term space missions. The Mission Simulation Facility (MST) will bridge this gap by providing a simulation framework and suite of simulation tools to support research in autonomy for remote exploration. This system will allow developers of autonomy software to test their models in a high-fidelity simulation and evaluate their system's performance against a set of integrated, standardized simulations. The Mission Simulation ToolKit (MST) uses a distributed architecture with a communication layer that is built on top of the standardized High Level Architecture (HLA). This architecture enables the use of existing high fidelity models, allows mixing simulation components from various computing platforms and enforces the use of a standardized high-level interface among components. The components needed to achieve a realistic simulation can be grouped into four categories: environment generation (terrain, environmental features), robotic platform behavior (robot dynamics), instrument models (camera/spectrometer/etc.), and data analysis. The MST will provide basic components in these areas but allows users to plug-in easily any refined model by means of a communication protocol. Finally, a description file defines the robot and environment parameters for easy configuration and ensures that all the simulation models share the same information.

Pisanich, Greg↗