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 55 records · Page 3

Implementing the space shuttle data processing system with the space generic open avionics architecture

This paper presents an overview of the application of the Space Generic Open Avionics Architecture (SGOAA) to the Space Shuttle Data Processing System (DPS) architecture design. This application has been performed to validate the SGOAA, and its potential use in flight critical systems. The paper summarizes key elements of the Space Shuttle avionics architecture, data processing system requirements and software architecture as currently implemented. It then summarizes the SGOAA architecture and describes a tailoring of the SGOAA to the Space Shuttle. The SGOAA consists of a generic system architecture for the entities in spacecraft avionics, a generic processing external and internal hardware architecture, a six class model of interfaces and functional subsystem architectures for data services and operations control capabilities. It has been proposed as an avionics architecture standard with the National Aeronautics and Space Administration (NASA), through its Strategic Avionics Technology Working Group, and is being considered by the Society of Aeronautic Engineers (SAE) as an SAE Avionics Standard. This architecture was developed for the Flight Data Systems Division of JSC by the Lockheed Engineering and Sciences Company, Houston, Texas.

Wray, Richard B.↗

High-Performance Monitoring Architecture for Large-Scale Distributed Systems Using Event Filtering

Monitoring is an essential process to observe and improve the reliability and the performance of large-scale distributed (LSD) systems. In an LSD environment, a large number of events is generated by the system components during its execution or interaction with external objects (e.g. users or processes). Monitoring such events is necessary for observing the run-time behavior of LSD systems and providing status information required for debugging, tuning and managing such applications. However, correlated events are generated concurrently and could be distributed in various locations in the applications environment which complicates the management decisions process and thereby makes monitoring LSD systems an intricate task. We propose a scalable high-performance monitoring architecture for LSD systems to detect and classify interesting local and global events and disseminate the monitoring information to the corresponding end- points management applications such as debugging and reactive control tools to improve the application performance and reliability. A large volume of events may be generated due to the extensive demands of the monitoring applications and the high interaction of LSD systems. The monitoring architecture employs a high-performance event filtering mechanism to efficiently process the large volume of event traffic generated by LSD systems and minimize the intrusiveness of the monitoring process by reducing the event traffic flow in the system and distributing the monitoring computation. Our architecture also supports dynamic and flexible reconfiguration of the monitoring mechanism via its Instrumentation and subscription components. As a case study, we show how our monitoring architecture can be utilized to improve the reliability and the performance of the Interactive Remote Instruction (IRI) system which is a large-scale distributed system for collaborative distance learning. The filtering mechanism represents an Intrinsic component integrated with the monitoring architecture to reduce the volume of event traffic flow in the system, and thereby reduce the intrusiveness of the monitoring process. We are developing an event filtering architecture to efficiently process the large volume of event traffic generated by LSD systems (such as distributed interactive applications). This filtering architecture is used to monitor collaborative distance learning application for obtaining debugging and feedback information. Our architecture supports the dynamic (re)configuration and optimization of event filters in large-scale distributed systems. Our work represents a major contribution by (1) survey and evaluating existing event filtering mechanisms In supporting monitoring LSD systems and (2) devising an integrated scalable high- performance architecture of event filtering that spans several kev application domains, presenting techniques to improve the functionality, performance and scalability. This paper describes the primary characteristics and challenges of developing high-performance event filtering for monitoring LSD systems. We survey existing event filtering mechanisms and explain key characteristics for each technique. In addition, we discuss limitations with existing event filtering mechanisms and outline how our architecture will improve key aspects of event filtering.

Maly, K.↗

Automated Synthesis of Architecture of Avionic Systems

The Architecture Synthesis Tool (AST) is software that automatically synthesizes software and hardware architectures of avionic systems. The AST is expected to be most helpful during initial formulation of an avionic-system design, when system requirements change frequently and manual modification of architecture is time-consuming and susceptible to error. The AST comprises two parts: (1) an architecture generator, which utilizes a genetic algorithm to create a multitude of architectures; and (2) a functionality evaluator, which analyzes the architectures for viability, rejecting most of the non-viable ones. The functionality evaluator generates and uses a viability tree a hierarchy representing functions and components that perform the functions such that the system as a whole performs system-level functions representing the requirements for the system as specified by a user. Architectures that survive the functionality evaluator are further evaluated by the selection process of the genetic algorithm. Architectures found to be most promising to satisfy the user s requirements and to perform optimally are selected as parents to the next generation of architectures. The foregoing process is iterated as many times as the user desires. The final output is one or a few viable architectures that satisfy the user s requirements.

Chau, Savio↗

DFT algorithms for bit-serial GaAs array processor architectures

Systems and Processes Engineering Corporation (SPEC) has developed an innovative array processor architecture for computing Fourier transforms and other commonly used signal processing algorithms. This architecture is designed to extract the highest possible array performance from state-of-the-art GaAs technology. SPEC's architectural design includes a high performance RISC processor implemented in GaAs, along with a Floating Point Coprocessor and a unique Array Communications Coprocessor, also implemented in GaAs technology. Together, these data processors represent the latest in technology, both from an architectural and implementation viewpoint. SPEC has examined numerous algorithms and parallel processing architectures to determine the optimum array processor architecture. SPEC has developed an array processor architecture with integral communications ability to provide maximum node connectivity. The Array Communications Coprocessor embeds communications operations directly in the core of the processor architecture. A Floating Point Coprocessor architecture has been defined that utilizes Bit-Serial arithmetic units, operating at very high frequency, to perform floating point operations. These Bit-Serial devices reduce the device integration level and complexity to a level compatible with state-of-the-art GaAs device technology.

Mcmillan, Gary B.↗

Formalization and visualization of domain-specific software architectures

This paper describes a domain-specific software design system based on the concepts of software architectures engineering and domain-specific models and languages. In this system, software architectures are used as high level abstractions to formulate a domain-specific software design. The software architecture serves as a framework for composing architectural fragments (e.g., domain objects, system components, and hardware interfaces) that make up the knowledge (or model) base for solving a problem in a particular application area. A corresponding software design is generated by analyzing and describing a system in the context of the software architecture. While the software architecture serves as the framework for the design, this concept is insufficient by itself for supplying the additional details required for a specific design. Additional domain knowledge is still needed to instantiate components of the architecture and develop optimized algorithms for the problem domain. One possible way to obtain the additional details is through the use of domain-specific languages. Thus, the general concept of a software architecture and the specific design details provided by domain-specific languages are combined to create what can be termed a domain-specific software architecture (DSSA).

Bailor, Paul D.↗

Processor architecture and data buffering

A set of architectures from three major architecture families: stack, register, and memory-to-memory is discussed. It is shown that scalable architectures are not applicable for low-density technologies because they require at least 32 words of local memory. Software support is shown to be capable of bridging the performance gap between scalable and nonscalable architectures. A register architecture with 32 words of local memory allocated interprocedurally outperforms scalable architectures with equal sizes local memories and even some with larger size local memories. The performance advantage of unscalable architectures becomes significant when in addition to quality compile-time support, a small cache is added to an unscalable architecture. A 32-register architecture with 512 byte cache executes 20 percent less cycles when compared with an 8-set multiple overlapping set organization.

Mulder, Hans↗

An International Strategy for Human Exploration of the Moon: The International Space Exploration Coordination Group (ISECG) Reference Architecture for Human Lunar Exploration

The International Space Exploration Coordination Group (ISECG) was established in response to The Global Exploration Strategy: The Framework for Coordination developed by fourteen space agencies and released in May 2007. Several ISECG participating space agencies have been studying concepts for human exploration of the moon that allow individual and collective goals and objectives to be met. This 18 month study activity culminated with the development of the ISECG Reference Architecture for Human Lunar Exploration. The reference architecture is a series of elements delivered over time in a flexible and evolvable campaign. This paper will describe the reference architecture and how it will inform near-term and long-term programmatic planning within interested agencies. The reference architecture is intended to serve as a global point of departure conceptual architecture that enables individual agency investments in technology development and demonstration, International Space Station research and technology demonstration, terrestrial analog studies, and robotic precursor missions to contribute towards the eventual implementation of a human lunar exploration scenario which reflects the concepts and priorities established to date. It also serves to create opportunities for partnerships that will support evolution of this concept and its eventual realization. The ISECG Reference Architecture for Human Lunar Exploration (commonly referred to as the lunar gPoD) reflects the agency commitments to finding an effective balance between conducting important scientific investigations of and from the moon, as well as demonstrating and mastering the technologies and capabilities to send humans farther into the Solar System. The lunar gPoD begins with a robust robotic precursor phase that demonstrates technologies and capabilities considered important for the success of the campaign. Robotic missions will inform the human missions and buy down risks. Human exploration will start with a thorough scientific investigation of the polar region while allowing the ability to demonstrate and validate the systems needed to take humans on more ambitious lunar exploration excursions. The ISECG Reference Architecture for Human Lunar Exploration serves as a model for future cooperation and is documented in a summary report and a comprehensive document that also describes the collaborative international process that led to its development. ISECG plans to continue with architecture studies such as this to examine an open transportation architecture and other destinations, with expanded participation from ISECG agencies, as it works to inform international partnerships and advance the Global Exploration Strategy.

Laurini, Kathleen C.↗

Exploration Space Suit Architecture: Destination Environmental-Based Technology Development

This paper picks up where EVA Space Suit Architecture: Low Earth Orbit Vs. Moon Vs. Mars (Hill, Johnson, IEEEAC paper #1209) left off in the development of a space suit architecture that is modular in design and interfaces and could be reconfigured to meet the mission or during any given mission depending on the tasks or destination. This paper will walk though the continued development of a space suit system architecture, and how it should evolve to meeting the future exploration EVA needs of the United States space program. In looking forward to future US space exploration and determining how the work performed to date in the CxP and how this would map to a future space suit architecture with maximum re-use of technology and functionality, a series of thought exercises and analysis have provided a strong indication that the CxP space suit architecture is well postured to provide a viable solution for future exploration missions. Through the destination environmental analysis that is presented in this paper, the modular architecture approach provides the lowest mass, lowest mission cost for the protection of the crew given any human mission outside of low Earth orbit. Some of the studies presented here provide a look and validation of the non-environmental design drivers that will become every-increasingly important the further away from Earth humans venture and the longer they are away. Additionally, the analysis demonstrates a logical clustering of design environments that allows a very focused approach to technology prioritization, development and design that will maximize the return on investment independent of any particular program and provide architecture and design solutions for space suit systems in time or ahead of being required for any particular manned flight program in the future. The new approach to space suit design and interface definition the discussion will show how the architecture is very adaptable to programmatic and funding changes with minimal redesign effort required such that the modular architecture can be quickly and efficiently honed into a specific mission point solution if required.

Hill, Terry R.↗

Exploration Space Suit Architecture and Destination Environmental-Based Technology Development

This paper continues forward where EVA Space Suit Architecture: Low Earth Orbit Vs. Moon Vs. Mars [1] left off in the development of a space suit architecture that is modular in design and could be reconfigured prior to launch or during any given mission depending on the tasks or destination. This paper will address the space suit system architecture and technologies required based upon human exploration extravehicular activity (EVA) destinations, and describe how they should evolve to meet the future exploration EVA needs of the US human space flight program.1, 2, 3 In looking forward to future US space exploration to a space suit architecture with maximum reuse of technology and functionality across a range of mission profiles and destinations, a series of exercises and analyses have provided a strong indication that the Constellation Program (CxP) space suit architecture is postured to provide a viable solution for future exploration missions4. The destination environmental analysis presented in this paper demonstrates that the modular architecture approach could provide the lowest mass and mission cost for the protection of the crew given any human mission outside of low-Earth orbit (LEO). Additionally, some of the high-level trades presented here provide a review of the environmental and non-environmental design drivers that will become increasingly important the farther away from Earth humans venture. This paper demonstrates a logical clustering of destination design environments that allows a focused approach to technology prioritization, development, and design that will maximize the return on investment, independent of any particular program, and provide architecture and design solutions for space suit systems in time or ahead of need dates for any particular crewed flight program in the future. The approach to space suit design and interface definition discussion will show how the architecture is very adaptable to programmatic and funding changes with minimal redesign effort such that the modular architecture can be quickly and efficiently honed into a specific mission point solution if required. Additionally, the modular system will allow for specific technology incorporation and upgrade as required with minimal redesign of the system.

Hill, Terry R.↗

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↗

Probabilistic Modeling of a Three-Stage Human Landing System Architecture

Space Policy Directive-1 has led to NASA partnerships with commercial entities on procurement which includes the development of the Human Landing System (HLS) [1]. With the goal of delivering human crew to the lunar surface by 2024, system uncertainties become an important obstacle to the maturation of multiple new, driving technologies and mission concepts of the HLS program. As unmitigated uncertainties have previously led to failed development programs, these risks and their impacts must be understood and handled to ensure program success [2]. Sources of uncertainty include novel engine designs and configurations, increased reliance on cryogenic fluid management(CFM), and refueling technologies—which propagate as high-level performance metrics such as overall propellant mass and engine performance. Also, the occurrence of operational uncertainties—e.g. launch conditions or need to abort during the mission—can cause cascading effects on the rest of the mission that are difficult to definitively quantify, and are outside the scope of control. These concrete examples and other occurrences can be categorized as either epistemic or aleatory uncertainties.Epistemic uncertainty arises due to a lack of knowledge and can be alleviated with design and program maturation. Aleatory uncertainty is due to the inherent randomness of the system and cannot be directly reduced, unlike epistemic uncertainty. Robust design and probabilistic methods can compensate for aleatory effects. A taxonomy of uncertainty is referred to for this work [3]. In this paper, a probabilistic methodology to handle uncertainties has been demonstrated on a three-element HLS concept [1, 4], which allows tracking of current best estimates of the concept and assessment of concept design robustness against uncertainties. A sample case has been completed for this abstract, and an expansion on the methodology will be included in the final paper. This methodology has two key parts: first, the creation of a dynamic architecture model of a three-element HLS concept; and second, its use with surrogate modeling and range estimating techniques to capture and propagate uncertainties. This abstract will cover the basics of the approach used, and further details and justifications will be in the final paper.The mission profile associated with this three-element concept (Fig 1) was modeled as a set of mission events that facilitated mass changes, idles, or spacecraft maneuvers. The mission profile scope starts with each element’s NRHO orbit insertion and aggregation and ends at post-sortie rendezvous with Orion. More detail on the mission profile will be in the final paper. The DYnamic Rocket EQuation Tool (DYREQT), a space systems synthesis and sizing framework used by NASA, was used as the physics framework to model the HLS architecture for applying the probabilistic methodology [5, 6]. Specifically, a parametric representation of the lander, ascent, and transfer elements and the mission profile of each element was established, with vehicle and mission parameters available as inputs to allow for a dynamic model. Each vehicle stage was modeled with high-level performance metrics, using Isp and propellant mass fraction (PMF) to remain parametric. For the probabilistic analysis, uncertainties of interest within the HLS concept were enumerated and represented as parameters within the DYREQT model as inputs for vehicle stages or mission profile events. These parameters were frozen at their nominal values for the purposes of baselining architecture performance and sizing the vehicle appropriately based on reference documentation [1]. Range estimating—a probabilistic method that combines Monte Carlo sampling, focus on critical parameters, and heuristics to assess risk and opportunities—is traditionally used with Mass Equipment Lists (MELs), but has been adapted with operational parameters as well as vehicle parameters in theDYREQT model to capture mission uncertainty alongside vehicle uncertainty [7, 3]. This method was selected due to its application and insight on a system from a bottom-up perspective, independence from historical rules of thumb, and ability to generate sensitivities based on design decisions and uncertainties. As a sample case for the abstract, the boiloff rates of the vehicle elements and the loiter times during the mission (simulating launch time variations and changing window of opportunities) were used with range estimating to provide preliminary results. To perform the range estimation portion of this methodology (depicted in Fig. 3, further details in final paper), the DYREQT model was sampled using a Design of Experiments (DoE) to efficiently explore the architecture design space with respect to the sample set of uncertainty parameters; 5,000 cases via Latin Hypercube Sampling were computed on the DYREQT architecture model. Then, the results were used to create surrogate models, multivariate regressions that can visualize hypercube trends in the design space, of the architecture with respect to the uncertainty parameters. Range estimating was applied to the surrogates instead of the actual models, which saves computational expense due to the bulk of cases needed for the Monte Carlo simulation as part of range estimating. Uncertainty parameters were sampled independently from triangular distributions using the DoE ranges as ‘min’ and ‘max’, and the nominal value as ‘most likely’. Based engineering intuition, some uncertainty parameters are correlated—e.g. if the main propellant has a high boil-off rate, the oxidizer should follow suit as both are related to CFM technology.While a Monte Carlo simulation samples all inputs as independent, the results would show model correlations; thus, it is efficient to sample the inputs as correlated. Using a correlation matrix constructed for the uncertainty parameters, previously independent samples were transformed to perform a Correlated Monte Carlo. A table for the DoE ranges and probability distribution parameters is shown in Table 1, and more details on Correlated Monte Carlo Simulations will be discussed in the final paper. The model’s resulting DoE showed that multivariate polynomial equations fit via least squares method captured its behavior accurately for the sample case. For the Correlated Monte Carlo Simulation, a positive correlation between fuel and oxidizer boiloff rates was used as a demonstration. 10,000 cases were computed with the surrogates and the launched masses for each vehicle element was collated. The results can be displayed in a probability density function (PDF), showing the impact of the uncertainty parameters chosen. Integrating the PDFs will yield a cumulative distribution function (CDF) that shows the cumulative probability of a given value on the x-axis. For the sample case, the elements’ launch mass margin was calculated and represented in as CDFs, as a demonstrated representation of figures of merit for the HLS concept. For the lander and ascent elements, the NRHO mass insertion limit is 16t; the transfer element has a limit of 30t [1]. It can be seen with Figure 2 that this probabilistic methodology can provide insight into mass margin with respect to the uncertainties being modeled. Currently, the results show that the lander (descent) vehicle element has the most restrictive design space; it is the only element to show a 10% probability of negative margin. Further analysis on the Monte Carlo results will show sensitivities for driving constraints and parameters for architecture feasibility, which can lead to establishing potential mission rules.The combination of range estimating with a parametric architecture model for HLS demonstrated the capability of this probabilistic methodology in a sample case. As the HLS development progresses, this methodology has the potential for keeping current best estimates of architecture performance for awarded concepts due to the flexibility in DYREQT’s modeling framework and its parametric nature. Concept maturation and increased epistemic knowledge can be injected into the model probabilistic modeling, and thus continue to track probability of mission success.

Stephanie Y Zhu↗

Virtualization - A Key Cost Saver in NASA Multi-Mission Ground System Architecture

With science team budgets being slashed, and a lack of adequate facilities for science payload teams to operate their instruments, there is a strong need for innovative new ground systems that are able to provide necessary levels of capability processing power, system availability and redundancy while maintaining a small footprint in terms of physical space, power utilization and cooling.The ground system architecture being presented is based off of heritage from several other projects currently in development or operations at Goddard, but was designed and built specifically to meet the needs of the Science and Planetary Operations Control Center (SPOCC) as a low-cost payload command, control, planning and analysis operations center. However, this SPOCC architecture was designed to be generic enough to be re-used partially or in whole by other labs and missions (since its inception that has already happened in several cases!)The SPOCC architecture leverages a highly available VMware-based virtualization cluster with shared SAS Direct-Attached Storage (DAS) to provide an extremely high-performing, low-power-utilization and small-footprint compute environment that provides Virtual Machine resources shared among the various tenant missions in the SPOCC. The storage is also expandable, allowing future missions to chain up to 7 additional 2U chassis of storage at an extremely competitive cost if they require additional archive or virtual machine storage space.The software architecture provides a fully-redundant GMSEC-based message bus architecture based on the ActiveMQ middleware to track all health and safety status within the SPOCC ground system. All virtual machines utilize the GMSEC system agents to report system host health over the GMSEC bus, and spacecraft payload health is monitored using the Hammers Integrated Test and Operations System (ITOS) Galaxy Telemetry and Command (TC) system, which performs near-real-time limit checking and data processing on the downlinked data stream and injects messages into the GMSEC bus that are monitored to automatically page the on-call operator or Systems Administrator (SA) when an off-nominal condition is detected. This architecture, like the LTSP thin clients, are shared across all tenant missions.Other required IT security controls are implemented at the ground system level, including physical access controls, logical system-level authentication authorization management, auditing and reporting, network management and a NIST 800-53 FISMA-Moderate IT Security plan Risk Assessment Contingency Plan, helping multiple missions share the cost of compliance with agency-mandated directives.The SPOCC architecture provides science payload control centers and backup mission operations centers with a cost-effective, standardized approach to virtualizing and monitoring resources that were traditionally multiple racks full of physical machines. The increased agility in deploying new virtual systems and thin client workstations can provide significant savings in personnel costs for maintaining the ground system. The cost savings in procurement, power, rack footprint and cooling as well as the shared multi-mission design greatly reduces upfront cost for missions moving into the facility. Overall, the authors hope that this architecture will become a model for how future NASA operations centers are constructed!

Ground System Architecture↗

A Systems Engineering Approach to Architecture Development

Architecture development is conducted prior to system concept design when there is a need to determine the best-value mix of systems that works collectively in specific scenarios and time frames to accomplish a set of mission area objectives. While multiple architecture frameworks exist, they often require use of unique taxonomies and data structures. In contrast, this presentation characterizes architecture development using terminology widely understood within the systems engineering community. Using a notional civil space architecture example, it employs a multi-tier framework to describe the enterprise level architecture and illustrates how results of lower tier, mission area architectures integrate into the enterprise architecture. It also presents practices for conducting effective mission area architecture studies, including establishing the trade space, developing functions and metrics, evaluating the ability of potential design solutions to meet the required functions, and expediting study execution through the use of iterative design cycles.

Architecture Development↗

A Systems Engineering Approach to Architecture Development

Architecture development is often conducted prior to system concept design when there is a need to determine the best-value mix of systems that works collectively in specific scenarios and time frames to accomplish a set of mission area objectives. While multiple architecture frameworks exist, they often require use of unique taxonomies and data structures. In contrast, this paper characterizes architecture development using terminology widely understood within the systems engineering community. Using a notional civil space architecture example, it employs a multi-tier framework to describe the enterprise level architecture and illustrates how results of lower tier, mission area architectures integrate into the enterprise architecture. It also presents practices for conducting effective mission area architecture studies, including establishing the trade space, developing functions and metrics, evaluating the ability of potential design solutions to meet the required functions, and expediting study execution through the use of iterative design cycles.

Multi-tier Framework↗

A Systems Engineering Approach to Architecture Development

Architecture development is often conducted prior to system concept design when there is a need to determine the best-value mix of systems that works collectively in specific scenarios and time frames to accomplish a set of mission area objectives. While multiple architecture frameworks exist, they often require use of unique taxonomies and data structures. In contrast, this paper characterizes architecture development using terminology widely understood within the systems engineering community. Using a notional civil space architecture example, it employs a multi-tier framework to describe the enterprise level architecture and illustrates how results of lower tier, mission area architectures integrate into the enterprise architecture. It also presents practices for conducting effective mission area architecture studies, including establishing the trade space, developing functions and metrics, evaluating the ability of potential design solutions to meet the required functions, and expediting study execution through the use of iterative design cycles

Architecture Development↗

Analysis of Alternative Architectures for a 2024 Lunar Sortie

This study focused on performing a broad analysis of lunar architectures to identify key alternatives capable of performing a 2024 human lunar landing mission. The goal of the study was to identify architecture alternatives which exhibit robustness, as measured by launch vehicle payload margin, to absorb the natural growth that occurs during design maturation. The study consisted of up to three element architectures which perform the mission from cis-lunar aggregation, through the surface sortie, and return to cis-lunar space. More than 600,000 data points were evaluated utilizing a novel architecture synthesis framework currently being developed by NASA/MSFC. Key findings from the study indicate that architecture complexity can be reduced by minimizing the number of discrete, unique architecture elements, which in turn translates into reduced design, development, test, and evaluation (DDT&E) complexity. It was identified that heavy lift launch vehicles enable such architectures while also providing significant increases to launch vehicle margin over existing and near-term commercial launch vehicle (CLV) performance expected in the 2024 time frame. Additionally, the study identified storable propellant based lander architectures as leading alternatives in achieving a 2024 human lunar landing by providing reduced technology needs and development schedules.

Architecture Analysis↗

The planning coordinator: A design architecture for autonomous error recovery and on-line planning of intelligent tasks

Developing a robust, task level, error recovery and on-line planning architecture is an open research area. There is previously published work on both error recovery and on-line planning; however, none incorporates error recovery and on-line planning into one integrated platform. The integration of these two functionalities requires an architecture that possesses the following characteristics. The architecture must provide for the inclusion of new information without the destruction of existing information. The architecture must provide for the relating of pieces of information, old and new, to one another in a non-trivial rather than trivial manner (e.g., object one is related to object two under the following constraints, versus, yes, they are related; no, they are not related). Finally, the architecture must be not only a stand alone architecture, but also one that can be easily integrated as a supplement to some existing architecture. This thesis proposal addresses architectural development. Its intent is to integrate error recovery and on-line planning onto a single, integrated, multi-processor platform. This intelligent x-autonomous platform, called the Planning Coordinator, will be used initially to supplement existing x-autonomous systems and eventually replace them.

Farah, Jeffrey J.↗

Generic POCC architectures

This document describes a generic POCC (Payload Operations Control Center) architecture based upon current POCC software practice, and several refinements to the architecture based upon object-oriented design principles and expected developments in teleoperations. The current-technology generic architecture is an abstraction based upon close analysis of the ERBS, COBE, and GRO POCC's. A series of three refinements is presented: these may be viewed as an approach to a phased transition to the recommended architecture. The third refinement constitutes the recommended architecture, which, together with associated rationales, will form the basis of the rapid synthesis environment to be developed in the remainder of this task. The document is organized into two parts. The first part describes the current generic architecture using several graphical as well as tabular representations or 'views.' The second part presents an analysis of the generic architecture in terms of object-oriented principles. On the basis of this discussion, refinements to the generic architecture are presented, again using a combination of graphical and tabular representations.

Source record↗