Search NASA⌕ Search

SEARCH · Search NASA

Results for “Architectural Design”

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 19 records
All sourcesNASA NTRSDOE OSTI
NASA NTRS1992

A domain-specific design architecture for composite material design and aircraft part redesign

Advanced composites have been targeted as a 'leapfrog' technology that would provide a unique global competitive position for U.S. industry. Composites are unique in the requirements for an integrated approach to designing, manufacturing, and marketing of products developed utilizing the new materials of construction. Numerous studies extending across the entire economic spectrum of the United States from aerospace to military to durable goods have identified composites as a 'key' technology. In general there have been two approaches to composite construction: build models of a given composite materials, then determine characteristics of the material via numerical simulation and empirical testing; and experience-directed construction of fabrication plans for building composites with given properties. The first route sets a goal to capture basic understanding of a device (the composite) by use of a rigorous mathematical model; the second attempts to capture the expertise about the process of fabricating a composite (to date) at a surface level typically expressed in a rule based system. From an AI perspective, these two research lines are attacking distinctly different problems, and both tracks have current limitations. The mathematical modeling approach has yielded a wealth of data but a large number of simplifying assumptions are needed to make numerical simulation tractable. Likewise, although surface level expertise about how to build a particular composite may yield important results, recent trends in the KBS area are towards augmenting surface level problem solving with deeper level knowledge. Many of the relative advantages of composites, e.g., the strength:weight ratio, is most prominent when the entire component is designed as a unitary piece. The bottleneck in undertaking such unitary design lies in the difficulty of the re-design task. Designing the fabrication protocols for a complex-shaped, thick section composite are currently very difficult. It is in fact this difficulty that our research will address.

Punch, W. F., III↗
NASA NTRS2016

Technical Reference Suite Addressing Challenges of Providing Assurance for Fault Management Architectural Design

Research into complexities of software systems Fault Management (FM) and how architectural design decisions affect safety, preservation of assets, and maintenance of desired system functionality has coalesced into a technical reference (TR) suite that advances the provision of safety and mission assurance. The NASA Independent Verification and Validation (IV&V) Program, with Software Assurance Research Program support, extracted FM architectures across the IV&V portfolio to evaluate robustness, assess visibility for validation and test, and define software assurance methods applied to the architectures and designs. This investigation spanned IV&V projects with seven different primary developers, a wide range of sizes and complexities, and encompassed Deep Space Robotic, Human Spaceflight, and Earth Orbiter mission FM architectures. The initiative continues with an expansion of the TR suite to include Launch Vehicles, adding the benefit of investigating differences intrinsic to model-based FM architectures and insight into complexities of FM within an Agile software development environment, in order to improve awareness of how nontraditional processes affect FM architectural design and system health management. The identification of particular FM architectures, visibility, and associated IV&V techniques provides a TR suite that enables greater assurance that critical software systems will adequately protect against faults and respond to adverse conditions. Additionally, the role FM has with regard to strengthened security requirements, with potential to advance overall asset protection of flight software systems, is being addressed with the development of an adverse conditions database encompassing flight software vulnerabilities. Capitalizing on the established framework, this TR suite provides assurance capability for a variety of FM architectures and varied development approaches. Research results are being disseminated across NASA, other agencies, and the software community. This paper discusses the findings and TR suite informing the FM domain in best practices for FM architectural design, visibility observations, and methods employed for IV&V and mission assurance.

Fitz, Rhonda↗
NASA NTRS2016

Technical Reference Suite Addressing Challenges of Providing Assurance for Fault Management Architectural Design

Research into complexities of software systems Fault Management (FM) and how architectural design decisions affect safety, preservation of assets, and maintenance of desired system functionality has coalesced into a technical reference (TR) suite that advances the provision of safety and mission assurance. The NASA Independent Verification and Validation (IVV) Program, with Software Assurance Research Program support, extracted FM architectures across the IVV portfolio to evaluate robustness, assess visibility for validation and test, and define software assurance methods applied to the architectures and designs. This investigation spanned IVV projects with seven different primary developers, a wide range of sizes and complexities, and encompassed Deep Space Robotic, Human Spaceflight, and Earth Orbiter mission FM architectures. The initiative continues with an expansion of the TR suite to include Launch Vehicles, adding the benefit of investigating differences intrinsic to model-based FM architectures and insight into complexities of FM within an Agile software development environment, in order to improve awareness of how nontraditional processes affect FM architectural design and system health management.

Fitz, Rhonda↗
NASA NTRS1988

Applications of an architecture design and assessment system (ADAS)

A new Architecture Design and Assessment System (ADAS) tool package is introduced, and a range of possible applications is illustrated. ADAS was used to evaluate the performance of an advanced fault-tolerant computer architecture in a modern flight control application. Bottlenecks were identified and possible solutions suggested. The tool was also used to inject faults into the architecture and evaluate the synchronization algorithm, and improvements are suggested. Finally, ADAS was used as a front end research tool to aid in the design of reconfiguration algorithms in a distributed array architecture.

Gray, F. Gail↗
NASA NTRS1986

Simulation system architecture design for generic communications link

This paper addresses a computer simulation system architecture design for generic digital communications systems. It addresses the issues of an overall system architecture in order to achieve a user-friendly, efficient, and yet easily implementable simulation system. The system block diagram and its individual functional components are described in detail. Software implementation is discussed with the VAX/VMS operating system used as a target environment.

Tsang, Chit-Sang↗
NASA NTRS2009

Verifying Architectural Design Rules of the Flight Software Product Line

This paper presents experiences of verifying architectural design rules of the NASA Core Flight Software (CFS) product line implementation. The goal of the verification is to check whether the implementation is consistent with the CFS architectural rules derived from the developer's guide. The results indicate that consistency checking helps a) identifying architecturally significant deviations that were eluded during code reviews, b) clarifying the design rules to the team, and c) assessing the overall implementation quality. Furthermore, it helps connecting business goals to architectural principles, and to the implementation. This paper is the first step in the definition of a method for analyzing and evaluating product line implementations from an architecture-centric perspective.

Ganesan, Dharmalingam↗
NASA NTRS1993

Architectural design of the science complex at Elizabeth City State University

This paper gives an overall view of the architectural design process and elements in taking an idea from conception to execution. The project presented is an example for this process. Once the need for a new structure is established, an architect studies the requirements, opinions and limits in creating a structure that people will exist in, move through, and use. Elements in designing a building include factors such as volume and surface, light and form changes of scale and view, movement and stasis. Some of the other factors are functions and physical conditions of construction. Based on experience, intuition, and boundaries, an architect will utilize all elements in creating a new building. In general, the design process begins with studying the spatial needs which develop into an architectural program. A comprehensive and accurate architectural program is essential for having a successful building. The most attractive building which does not meet the functional needs of its users has failed at the primary reason for its existence. To have a good program an architect must have a full understanding of the daily functions that will take place in the building. The architectural program along with site characteristics are among a few of the important guidelines in studying the form, adjacencies, and circulation for the structure itself and also in relation to the adjacent structures. Conceptual studies are part of the schematic design, which is the first milestone in the design process. The other reference points are design development and construction documents. At each milestone, review and coordination with all the consultants is established, and the user is essential in refining the project. In design development phase, conceptual diagrams take shape, and architectural, structural, mechanical, and electrical systems are developed. The final phase construction documents convey all the information required to construct the building. The design process and elements described were applied in the following project.

Jahromi, Soheila↗
NASA NTRS1989

Architectural design of a ground-based deep-space optical reception antenna

An architectural design of a ground-based antenna (telescope) for receiving optical communications from deep space is presented. Physical and optical parameters, and their effect on the performance and cost considerations, are described. The channel capacity of the antenna is 100 kbits/s from Saturn and 5 Mbits/s from Mars. A novel sunshade is designed to permit optical communication even when the deep-space laser source is as close to the sun as 12 deg. Inserts in the tubes of the sunshade permit operations at solar elongations as small as 6 or 3 deg. The Nd:YAG source laser and the Fraunhofer filter (a narrow-band predetection optical filter) are tuned to match the Doppler shifts of the source and background. A typical Saturn-to-earth data link can reduce its source power requirement from 8.2 W to 2 W of laser output by employing a Fraunhofer filter instead of a conventional multilayer dielectric filter.

Kerr, E. L.↗
NASA NTRS2013

Understanding the Lunar System Architecture Design Space

Based on the flexible path strategy and the desire of the international community, the lunar surface remains a destination for future human exploration. This paper explores options within the lunar system architecture design space, identifying performance requirements placed on the propulsive system that performs Earth departure within that architecture based on existing and/or near-term capabilities. The lander crew module and ascent stage propellant mass fraction are primary drivers for feasibility in multiple lander configurations. As the aggregation location moves further out of the lunar gravity well, the lunar lander is required to perform larger burns, increasing the sensitivity to these two factors. Adding an orbit transfer stage to a two-stage lunar lander and using a large storable stage for braking with a one-stage lunar lander enable higher aggregation locations than Low Lunar Orbit. Finally, while using larger vehicles enables a larger feasible design space, there are still feasible scenarios that use three launches of smaller vehicles.

Arney, Dale C.↗
NASA NTRS1971

Architectural design and simulation of a virtual memory

Virtual memory is an imaginary main memory with a very large capacity which the programmer has at his disposal. It greatly contributes to the solution of the dynamic storage allocation problem. The architectural design of a virtual memory is presented which implements by hardware the idea of queuing and scheduling the page requests to a paging drum in such a way that the access of the paging drum is increased many times. With the design, an increase of up to 16 times in page transfer rate is achievable when the virtual memory is heavily loaded. This in turn makes feasible a great increase in the system throughput.

Kwok, G.↗
NASA NTRS2017

CisLunar Habitat Internal Architecture Design Criteria

BACKGROUND: In preparation for human exploration to Mars, there is a need to define the development and test program that will validate deep space operations and systems. In that context, a Proving Grounds CisLunar habitat spacecraft is being defined as the next step towards this goal. This spacecraft will operate differently from the ISS or other spacecraft in human history. The performance envelope of this spacecraft (mass, volume, power, specifications, etc.) is being defined by the Future Capabilities Study Team. This team has recognized the need for a human-centered approach for the internal architecture of this spacecraft and has commissioned a CisLunar Phase-1 Habitat Internal Architecture Study Team to develop a NASA reference configuration, providing the Agency with a "smart buyer" approach for future acquisition. THE CISLUNAR HABITAT INTERNAL ARCHITECTURE STUDY: Overall, the CisLunar Habitat Internal Architecture study will address the most significant questions and risks in the current CisLunar architecture, habitation, and operations concept development. This effort is achieved through definition of design criteria, evaluation criteria and process, design of the CisLunar Habitat Phase-1 internal architecture, and the development and fabrication of internal architecture concepts combined with rigorous and methodical Human-in-the-Loop (HITL) evaluations and testing of the conceptual innovations in a controlled test environment. The vision of the CisLunar Habitat Internal Architecture Study is to design, build, and test a CisLunar Phase-1 Habitat Internal Architecture that will be used for habitation (e.g. habitability and human factors) evaluations. The evaluations will mature CisLunar habitat evaluation tools, guidelines, and standards, and will interface with other projects such as the Advanced Exploration Systems (AES) Program integrated Power, Avionics, Software (iPAS), and Logistics for integrated human-in-the-loop testing. The mission of the CisLunar Habitat Internal Architecture Study is to become a forcing function to establish a common understanding of CisLunar Phase-1 Habitation Internal Architecture design criteria, processes, and tools. The scope of the CisLunar Habitat Internal Architecture study is to design, develop, demonstrate, and evaluate a Phase-1 CisLunar Habitat common module internal architecture based on design criteria agreed to by NASA, the International Partners, and Commercial Exploration teams. This task is to define the CisLunar Phase-1 Internal Architecture Government Reference Design, assist NASA in becoming a "smart buyer" for Phase-1 Habitat Concepts, and ultimately to derive standards and requirements from the Internal Architecture Design Process. The first step was to define a Habitat Internal Architecture Design Criteria and create a structured philosophy to be used by design teams as a filter by which critical aspects of consideration would be identified for the purpose of organizing and utilizing interior spaces. With design criteria in place, the team will develop a series of iterative internal architecture concept designs which will be assessed by means of an evaluation criteria and process. These assessments will successively drive and refine the design, leading to the combination and down-selection of design concepts. A single refined reference design configuration will be developed into in a medium-to-high fidelity mockup. A multi-day human-in-the-loop mission test will fully evaluate the reference design and validate its configuration. Lessons learned from the design and evaluation will enable the team to identify appropriate standards for Phase-1 CisLunar Habitat Internal Architecture and will enable NASA to develop derived requirements in support of maturing CisLunar Habitation capabilities. This paper will describe the criteria definition process, workshop event, and resulting CisLunar Phase-1 Habitat Internal Architecture Design Criteria.

Jones, R.↗
NASA NTRS2009

Lunar Navigation Architecture Design Considerations

The NASA Constellation Program is aiming to establish a long-term presence on the lunar surface. The Constellation elements (Orion, Altair, Earth Departure Stage, and Ares launch vehicles) will require a lunar navigation architecture for navigation state updates during lunar-class missions. Orion in particular has baselined earth-based ground direct tracking as the primary source for much of its absolute navigation needs. However, due to the uncertainty in the lunar navigation architecture, the Orion program has had to make certain assumptions on the capabilities of such architectures in order to adequately scale the vehicle design trade space. The following paper outlines lunar navigation requirements, the Orion program assumptions, and the impacts of these assumptions to the lunar navigation architecture design. The selection of potential sites was based upon geometric baselines, logistical feasibility, redundancy, and abort support capability. Simulated navigation covariances mapped to entry interface flightpath- angle uncertainties were used to evaluate knowledge errors. A minimum ground station architecture was identified consisting of Goldstone, Madrid, Canberra, Santiago, Hartebeeshoek, Dongora, Hawaii, Guam, and Ascension Island (or the geometric equivalent).

D'Souza, Christopher↗
NASA NTRS1992

Open System Architecture design for planet surface systems

The Open System Architecture is an approach to meeting the needs for flexibility and evolution of the U.S. Space Exploration Initiative program of the manned exploration of the solar system and its permanent settlement. This paper investigates the issues that future activities of the planet exploration program must confront, defines the basic concepts that provide the basis for establishing an Open System Architecture, identifies the appropriate features of such an architecture, and discusses examples of Open System Architectures.

Petri, D. A.↗
NASA NTRS1995

Teledesic Global Wireless Broadband Network: Space Infrastructure Architecture, Design Features and Technologies

The Teledesic satellites are a new class of small satellites which demonstrate the important commercial benefits of using technologies developed for other purposes by U.S. National Laboratories. The Teledesic satellite architecture, subsystem design features, and new technologies are described. The new Teledesic satellite manufacturing, integration, and test approaches which use modern high volume production techniques and result in surprisingly low space segment costs are discussed. The constellation control and management features and attendant software architecture features are addressed. After briefly discussing the economic and technological impact on the USA commercial space industries of the space communications revolution and such large constellation projects, the paper concludes with observations on the trend toward future system architectures using networked groups of much smaller satellites.

Stuart, James R.↗
NASA NTRS1992

Advanced information processing system: The Army fault tolerant architecture conceptual study. Volume 2: Army fault tolerant architecture design and analysis

Described here is the Army Fault Tolerant Architecture (AFTA) hardware architecture and components and the operating system. The architectural and operational theory of the AFTA Fault Tolerant Data Bus is discussed. The test and maintenance strategy developed for use in fielded AFTA installations is presented. An approach to be used in reducing the probability of AFTA failure due to common mode faults is described. Analytical models for AFTA performance, reliability, availability, life cycle cost, weight, power, and volume are developed. An approach is presented for using VHSIC Hardware Description Language (VHDL) to describe and design AFTA's developmental hardware. A plan is described for verifying and validating key AFTA concepts during the Dem/Val phase. Analytical models and partial mission requirements are used to generate AFTA configurations for the TF/TA/NOE and Ground Vehicle missions.

Harper, R. E.↗
NASA NTRS2012

Feasibility Study of Two Candidate Reaction Wheel/thruster Hybrid Control Architecture Designs for the Cassini Spacecraft

As the first spacecraft to achieve orbit at Saturn in 2004, Cassini has collected science data throughout its four-year prime mission (2004-08), and has since been approved for a first and second extended mission through 2017. Cassini carries a set of three "fixed" reaction wheels and a backup reaction wheel (reaction wheel #4) is mounted on top of an articulable platform. If necessary, this platform could be articulated to orient the backup reaction wheel with the degraded wheel. The reaction wheels are used primarily for attitude control when precise and stable pointing of a science instrument such as the narrow angle camera is required. In 2001-02, reaction wheel #3 exhibited signs of bearing cage instability. As a result, reaction wheel #4 was articulated to align with reaction wheel #3. Beginning in July 2003, Cassini was controlled using wheel #1, #2, and #4. From their first use in the spring of 2000 until today, reaction wheels #1 and #2 have accumulated more than3.5 billions revolutions each. As such, in spite of very carefully management of the wheel spin rates by the mission operation team, there are some observed increases in the drag torque of the wheels' bearings. Hence, the mission operations team must prepare for the contingency scenario in which the reaction wheel #1 (in addition to wheel #3) had degraded. In this hypothetical fault scenario, the two remaining reaction wheels (#2 and #4) will not be able to provide precise and stable three-axis control of the spacecraft. In this study, we evaluate the feasibility of controlling Cassini using the two remaining reaction wheels and four thrusters to meet the science pointing requirements for two key science operational modes: the Optical Remote Sensing and Downlink, Fields, Particles, & Waves operation modes. The performance (e.g., pointing control error, pointing stability, hydrazine consumption rate, etc.) of the hybrid controllers in both operations scenarios will be compared with those achieved using an all-thruster controller design. Strength and weaknesses of the hybrid control architecture are assessed quantitatively.

Cassini↗