Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “ARCHITECTURE”

Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.

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

At least 937 records · Page 52

Constellation Architecture Team-Lunar: Lunar Habitat Concepts

This paper will describe lunar habitat concepts that were defined as part of the Constellation Architecture Team-Lunar (CxAT-Lunar) in support of the Vision for Space Exploration. There are many challenges to designing lunar habitats such as mission objectives, launch packaging, lander capability, and risks. Surface habitats are required in support of sustaining human life to meet the mission objectives of lunar exploration, operations, and sustainability. Lunar surface operations consist of crew operations, mission operations, EVA operations, science operations, and logistics operations. Habitats are crewed pressurized vessels that include surface mission operations, science laboratories, living support capabilities, EVA support, logistics, and maintenance facilities. The challenge is to deliver, unload, and deploy self-contained habitats and laboratories to the lunar surface. The CxAT-Lunar surface campaign analysis focused on three primary trade sets of analysis. Trade set one (TS1) investigated sustaining a crew of four for six months with full outpost capability and the ability to perform long surface mission excursions using large mobility systems. Two basic habitat concepts of a hard metallic horizontal cylinder and a larger inflatable torus concept were investigated as options in response to the surface exploration architecture campaign analysis. Figure 1 and 2 depicts the notional outpost configurations for this trade set. Trade set two (TS2) investigated a mobile architecture approach with the campaign focused on early exploration using two small pressurized rovers and a mobile logistics support capability. This exploration concept will not be described in this paper. Trade set three (TS3) investigated delivery of a "core' habitation capability in support of an early outpost that would mature into the TS1 full outpost capability. Three core habitat concepts were defined for this campaign analysis. One with a four port core habitat, another with a 2 port core habitat, and the third investigated leveraging commonality of the lander ascent module and airlock pressure vessel hard shell. The paper will describe an overview of the various habitat concepts and their functionality. The Crew Operations area includes basic crew accommodations such as sleeping, eating, hygiene and stowage. The EVA Operations area includes additional EVA capability beyond the suit-port airlock function such as redundant airlock(s), suit maintenance, spares stowage, and suit stowage. The Logistics Operations area includes the enhanced accommodations for 180 days such as closed loop life support systems hardware, consumable stowage, spares stowage, interconnection to the other Hab units, and a common interface mechanism for future growth and mating to a pressurized rover. The Mission & Science Operations area includes enhanced outpost autonomy such as an IVA glove box, life support, and medical operations.

Toups, Larry↗

Overview of the Phoenix Entry, Descent and Landing System Architecture

NASA s Phoenix Mars Lander began its journey to Mars from Cape Canaveral, Florida in August 2007, but its journey to the launch pad began many years earlier in 1997 as NASA s Mars Surveyor Program 2001 Lander. In the intervening years, the entry, descent and landing (EDL) system architecture went through a series of changes, resulting in the system flown to the surface of Mars on May 25th, 2008. Some changes, such as entry velocity and landing site elevation, were the result of differences in mission design. Other changes, including the removal of hypersonic guidance, the reformulation of the parachute deployment algorithm, and the addition of the backshell avoidance maneuver, were driven by constant efforts to augment system robustness. An overview of the Phoenix EDL system architecture is presented along with rationales driving these architectural changes.

Grover, Myron R., III↗

Linking and Combining Distributed Operations Facilities using NASA's "GMSEC" Systems Architectures

NASA's Goddard Mission Services Evolution Center (GMSEC) ground system architecture has been in development since late 2001, has successfully supported eight orbiting satellites and is being applied to many of NASA's future missions. GMSEC can be considered an event-driven service-oriented architecture built around a publish/subscribe message bus middleware. This paper briefly discusses the GMSEC technical approaches which have led to significant cost savings and risk reduction for NASA missions operated at the Goddard Space Flight Center (GSFC). The paper then focuses on the development and operational impacts of extending the architecture across multiple mission operations facilities.

Smith, Danford↗

Sensor Webs with a Service-Oriented Architecture for On-demand Science Products

This paper describes the work being managed by the NASA Goddard Space Flight Center (GSFC) Information System Division (ISD) under a NASA Earth Science Technology Ofice (ESTO) Advanced Information System Technology (AIST) grant to develop a modular sensor web architecture which enables discovery of sensors and workflows that can create customized science via a high-level service-oriented architecture based on Open Geospatial Consortium (OGC) Sensor Web Enablement (SWE) web service standards. These capabilities serve as a prototype to a user-centric architecture for Global Earth Observing System of Systems (GEOSS). This work builds and extends previous sensor web efforts conducted at NASA/GSFC using the Earth Observing 1 (EO-1) satellite and other low-earth orbiting satellites.

Mandl, Daniel↗

Architecture Analysis of Evolving Complex Systems of Systems (C107)

This viewgraph presentation reviews the analysis of the architecture of complex systems and the development of a tool to assist in the analysis. The goal of the project was to research and develop a tool for architecture analysis of dynamic and static data. The new tool, Dyn-SAVE, was an extension of an already existing static tool, Software Architecture Visualization and Evaluation (SAVE).

Lindvall, Mikael↗

Human Exploration of Mars Design Reference Architecture 5.0

This document reviews the Design Reference Architecture (DRA) for human exploration of Mars. The DRA represents the current best strategy for human missions. The DRA is not a formal plan, but provides a vision and context to tie current systems and technology developments to potential missions to Mars, and it also serves as a benchmark against which alternative architectures can be measured. The document also reviews the objectives and products of the 2007 study that was to update NASA's human Mars mission reference architecture, assess strategic linkages between lunar and Mars strategies, develop an understanding of methods for reducing cost/risk of human missions through investment in research, technology development and synergy with other exploration plans. There is also a review of the process by which the DRA will continue to be refined. The unique capacities of human exploration is reviewed. The possible goals and objectives of the first three human missions are presented, along with the recommendation that the mission involve a long stay visiting multiple sites.The deployment strategy is outlined and diagrammed including the pre-deployment of the many of the material requirements, and a six crew travel to Mars on a six month trajectory. The predeployment and the Orion crew vehicle are shown. The ground operations requirements are also explained. Also the use of resources found on the surface of Mars is postulated. The Mars surface exploration strategy is reviewed, including the planetary protection processes that are planned. Finally a listing of the key decisions and tenets is posed.

Drake, Bret G.↗

Complex Event Recognition Architecture

Complex Event Recognition Architecture (CERA) is the name of a computational architecture, and software that implements the architecture, for recognizing complex event patterns that may be spread across multiple streams of input data. One of the main components of CERA is an intuitive event pattern language that simplifies what would otherwise be the complex, difficult tasks of creating logical descriptions of combinations of temporal events and defining rules for combining information from different sources over time. In this language, recognition patterns are defined in simple, declarative statements that combine point events from given input streams with those from other streams, using conjunction, disjunction, and negation. Patterns can be built on one another recursively to describe very rich, temporally extended combinations of events. Thereafter, a run-time matching algorithm in CERA efficiently matches these patterns against input data and signals when patterns are recognized. CERA can be used to monitor complex systems and to signal operators or initiate corrective actions when anomalous conditions are recognized. CERA can be run as a stand-alone monitoring system, or it can be integrated into a larger system to automatically trigger responses to changing environments or problematic situations.

Fitzgerald, William A.↗

Avionics System Architecture for the NASA Orion Vehicle

It has been 30 years since the National Aeronautics and Space Administration (NASA) last developed a crewed spacecraft capable of launch, on-orbit operations, and landing. During that time, aerospace avionics technologies have greatly advanced in capability, and these technologies have enabled integrated avionics architectures for aerospace applications. The inception of NASA s Orion Crew Exploration Vehicle (CEV) spacecraft offers the opportunity to leverage the latest integrated avionics technologies into crewed space vehicle architecture. The outstanding question is to what extent to implement these advances in avionics while still meeting the unique crewed spaceflight requirements for safety, reliability and maintainability. Historically, aircraft and spacecraft have very similar avionics requirements. Both aircraft and spacecraft must have high reliability. They also must have as much computing power as possible and provide low latency between user control and effecter response while minimizing weight, volume, and power. However, there are several key differences between aircraft and spacecraft avionics. Typically, the overall spacecraft operational time is much shorter than aircraft operation time, but the typical mission time (and hence, the time between preventive maintenance) is longer for a spacecraft than an aircraft. Also, the radiation environment is typically more severe for spacecraft than aircraft. A "loss of mission" scenario (i.e. - the mission is not a success, but there are no casualties) arguably has a greater impact on a multi-million dollar spaceflight mission than a typical commercial flight. Such differences need to be weighted when determining if an aircraft-like integrated modular avionics (IMA) system is suitable for a crewed spacecraft. This paper will explore the preliminary design process of the Orion vehicle avionics system by first identifying the Orion driving requirements and the difference between Orion requirements and those of other previous crewed spacecraft avionics systems. Common systems engineering methods will be used to evaluate the value propositions, or the factors that weight most heavily in design consideration, of Orion and other aerospace systems. Then, the current Orion avionics architecture will be presented and evaluated.

Baggerman, Clint↗

A Distributed Prognostic Health Management Architecture

This paper introduces a generic distributed prognostic health management (PHM) architecture with specific application to the electrical power systems domain. Current state-of-the-art PHM systems are mostly centralized in nature, where all the processing is reliant on a single processor. This can lead to loss of functionality in case of a crash of the central processor or monitor. Furthermore, with increases in the volume of sensor data as well as the complexity of algorithms, traditional centralized systems become unsuitable for successful deployment, and efficient distributed architectures are required. A distributed architecture though, is not effective unless there is an algorithmic framework to take advantage of its unique abilities. The health management paradigm envisaged here incorporates a heterogeneous set of system components monitored by a varied suite of sensors and a particle filtering (PF) framework that has the power and the flexibility to adapt to the different diagnostic and prognostic needs. Both the diagnostic and prognostic tasks are formulated as a particle filtering problem in order to explicitly represent and manage uncertainties; however, typically the complexity of the prognostic routine is higher than the computational power of one computational element ( CE). Individual CEs run diagnostic routines until the system variable being monitored crosses beyond a nominal threshold, upon which it coordinates with other networked CEs to run the prognostic routine in a distributed fashion. Implementation results from a network of distributed embedded devices monitoring a prototypical aircraft electrical power system are presented, where the CEs are Sun Microsystems Small Programmable Object Technology (SPOT) devices.

Bhaskar, Saha↗

Exploration Architecture Options - ECLSS, EVA, TCS Implications

Many options for exploration of the Moon and Mars have been identified and evaluated since the Vision for Space Exploration VSE was announced in 2004. Lunar architectures have been identified and addressed in the Lunar Surface Systems team to establish options for how to get to and then inhabit and explore the moon. The Augustine Commission evaluated human space flight for the Obama administration and identified many options for how to conduct human spaceflight in the future. This paper will evaluate the options for exploration of the moon and Mars and those of the Augustine human spaceflight commission for the implications of each architecture on the Environmental Control and Life Support, ExtraVehicular Activity and Thermal Control systems. The advantages and disadvantages of each architecture and options are presented.

Chambliss, Joe↗

Exploration Architecture Options - ECLSS, EVA, TCS Implications

Many options for exploration of space have been identified and evaluated since the Vision for Space Exploration (VSE) was announced in 2004. Lunar architectures have been identified and addressed in the Lunar Surface Systems team to establish options for how to get to and then inhabit and explore the moon. The Augustine Commission evaluated human space flight for the Obama administration and identified many options for how to conduct human spaceflight in the future. This paper will evaluate the options for exploration of space for the implications of architectures on the Environmental Control and Life Support (ECLSS), ExtraVehicular Activity (EVA) and Thermal Control System (TCS) Systems. The advantages and disadvantages of each architecture and options are presented.

Chambliss, Joe↗

Space Telecommunications Radio System (STRS) Architecture Standard. Release 1.02.1

This document contains the NASA architecture standard for software defined radios used in space- and ground-based platforms to enable commonality among radio developments to enhance capability and services while reducing mission and programmatic risk. Transceivers (or transponders) with functionality primarily defined in software (e.g., firmware) have the ability to change their functional behavior through software alone. This radio architecture standard offers value by employing common waveform software interfaces, method of instantiation, operation, and testing among different compliant hardware and software products. These common interfaces within the architecture abstract application software from the underlying hardware to enable technology insertion independently at either the software or hardware layer.

Reinhart, Richard C.↗

Simplified Architecture for Precise Aiming of a Deep-Space Communication Laser Transceiver

The simplified architecture is a minimal system for a deep-space optical communications transceiver. For a deepspace optical communications link the simplest form of the transceiver requires (1) an efficient modulated optical source, (2) a point-ahead mechanism (PAM) to compensate for two-way light travel, (3) an aperture to reduce the divergence of the transmit laser communication signal and also to collect the uplink communication signal, and (4) a receive detector to sense the uplink communication signal. Additional components are introduced to mitigate for spacecraft microvibrations and to improve the pointing accuracy. The Canonical Transceiver implements this simplified architecture (see figure). A single photon-counting smart focal plane sensor combines acquisition, tracking, and forward link data detection functionality. This improves optical efficiency by eliminating channel splits. A transmit laser blind sensor (e.g. silicon with 1,550-nm beam) provides transmit beam-pointing feedback via the two-photon absorption (TPA) process. This vastly improves the transmit/receive isolation because only the focused transmit beam is detected. A piezoelectric tiptilt actuator implements the required point-ahead angle. This point-ahead mechanism has been demonstrated to have near zero quiescent power and is flight qualified. This architecture also uses an innovative 100-mHz resonant frequency passive isolation platform to filter spacecraft vibrations with voice coil actuators for active tip-tilt correction below the resonant frequency. The canonical deep-space optical communications transceiver makes synergistic use of innovative technologies to reduce size, weight, power, and cost. This optical transceiver can be used to retire risks associated with deep-space optical communications on a planetary pathfinder mission and is complementary to ongoing lunar and access link developments.

Ortiz, Gerard G.↗

A Phobos-Deimos Mission as an Element of the NASA Mars Design Reference Architecture 5.0

NASA has conducted a series of mission studies over the past 25 years examining the eventual exploration of the surface of Mars by humans. The latest version of this evolutionary series of design reference missions/architectures - Design Reference Architecture 5 or DRA-5 - was completed in 2007. This paper examines the implications of including a human mission to explore the moons of Mars and teleoperate robots in various locations, but not to land the human crews on Mars, as an element of this reference architecture. Such a mission has been proposed several times during this same 25 year evolution leading up to the completion of DRA-5 primarily as a mission of testing the in-space vehicles and operations while surface vehicles and landers are under development. But such a precursor or test mission has never been explicitly included as an element of this Architecture. This paper will first summarize the key features of the DRA-5 to provide context for the remainder of the assessment. This will include a description of the in-space vehicles that would be the subject of a shakedown test during the Mars orbital mission. A decision tree will be used to illustrate the factors that will be analyzed, and the sequence in which they will be addressed, for this assessment. The factors that will be analyzed include the type of interplanetary transfer orbit (opposition class versus conjunction class), the type of parking orbit (circular versus elliptical), and the type of propulsion technology (high thrust chemical versus nuclear thermal rocket). The manner in which each of these factors impacts an individual mission will be described. In addition to the direct impact of these factors, additional considerations impacting crew health and overall programmatic outcomes will be discussed. Numerical results for each of the factors in the decision tree will be grouped with derived qualitative impacts from crew health and programmatic consideration. These quantitative and qualitative results will be summarized in a pros/cons table as a summary for this analysis.

Hoffman, Stephen J.↗

Small Orbital Debris Mitigation Mission Architecture

Small orbital debris in LEO (1-10 cm in size) presents a clear and present danger to operational LEO spacecraft. This debris field has dramatically increased (nearly doubled) in recent years following the Chinese ASAT Test in 2007 and the Iridium/Cosmos collision in 2009. Estimates of the number of small debris have grown to 500,000 objects after these two events; previously the population was 300,000 objects. These small, untracked debris objects (appproximately 500,000) outnumber the larger and tracked objects (appproximately 20,000) by a factor 25 to 1. Therefore, the risk of the small untracked debris objects to operational spacecraft is much greater than the risk posed by the larger and tracked LEO debris objects. A recent study by The Aerospace Corporation found that the debris environment will increase the costs of maintaining a constellation of government satellites by 5%, a constellation of large commercial satellites by 11%, and a constellation of factory built satellites by 26% from $7.6 billion to $9.57 billion. Based upon these facts, the NASA Marshall Space Flight Center (MSFC) Advanced Concepts Office (ACO) performed an architecture study on Small Orbital Debris Active Removal (SODAR) using a space-based nonweapons- class laser satellite for LEO debris removal. The goal of the SODAR study was to determine the ability of a space-based laser system to remove the most pieces of debris (1 cm to 10 cm, locations unknown), in the shortest amount of time, with the fewest number of spacecraft. The ESA developed MASTER2005 orbital debris model was used to probabilistically classify the future debris environment including impact velocity, magnitude, and directionality. The study ground rules and assumptions placed the spacecraft into a high inclination Low Earth Orbit at 800 km as an initial reference point. The architecture study results found that a spacecraft with an integrated forward-firing laser is capable of reducing the small orbital debris flux within a 60 to 100 km orbital shell by a significant amount within the one spacecraft's operational lifetime. The technology developments required for such an architecture to be successfully employed are: 1) A pico-pulsed, space qualified laser and 2) The ability to detect and track a small LEO small debris object from a space based platform. Therefore, a conceptual design for a demonstration satellite to showcase the ability to detect and track small orbital debris was completed

Wiegmann, Bruce M.↗

Error Propagation Analysis in the SAE Architecture Analysis and Design Language (AADL) and the EDICT Tool Framework

This report documents the capabilities of the EDICT tools for error modeling and error propagation analysis when operating with models defined in the Architecture Analysis & Design Language (AADL). We discuss our experience using the EDICT error analysis capabilities on a model of the Scalable Processor-Independent Design for Enhanced Reliability (SPIDER) architecture that uses the Reliable Optical Bus (ROBUS). Based on these experiences we draw some initial conclusions about model based design techniques for error modeling and analysis of highly reliable computing architectures.

LaValley, Brian W.↗

C-Band Airport Surface Communications System Standards Development. Phase II Final Report. Volume 1: Concepts of Use, Initial System Requirements, Architecture, and AeroMACS Design Considerations

This report is provided as part of ITT s NASA Glenn Research Center Aerospace Communication Systems Technical Support (ACSTS) contract NNC05CA85C, Task 7: New ATM Requirements-Future Communications, C-Band and L-Band Communications Standard Development and was based on direction provided by FAA project-level agreements for New ATM Requirements-Future Communications. Task 7 included two subtasks. Subtask 7-1 addressed C-band (5091- to 5150-MHz) airport surface data communications standards development, systems engineering, test bed and prototype development, and tests and demonstrations to establish operational capability for the Aeronautical Mobile Airport Communications System (AeroMACS). Subtask 7-2 focused on systems engineering and development support of the L-band digital aeronautical communications system (L-DACS). Subtask 7-1 consisted of two phases. Phase I included development of AeroMACS concepts of use, requirements, architecture, and initial high-level safety risk assessment. Phase II builds on Phase I results and is presented in two volumes. Volume I (this document) is devoted to concepts of use, system requirements, and architecture, including AeroMACS design considerations. Volume II describes an AeroMACS prototype evaluation and presents final AeroMACS recommendations. This report also describes airport categorization and channelization methodologies. The purposes of the airport categorization task were (1) to facilitate initial AeroMACS architecture designs and enable budgetary projections by creating a set of airport categories based on common airport characteristics and design objectives, and (2) to offer high-level guidance to potential AeroMACS technology and policy development sponsors and service providers. A channelization plan methodology was developed because a common global methodology is needed to assure seamless interoperability among diverse AeroMACS services potentially supplied by multiple service providers.

Hall, Edward↗

Performance Analysis of Cloud Computing Architectures Using Discrete Event Simulation

Cloud computing offers the economic benefit of on-demand resource allocation to meet changing enterprise computing needs. However, the flexibility of cloud computing is disadvantaged when compared to traditional hosting in providing predictable application and service performance. Cloud computing relies on resource scheduling in a virtualized network-centric server environment, which makes static performance analysis infeasible. We developed a discrete event simulation model to evaluate the overall effectiveness of organizations in executing their workflow in traditional and cloud computing architectures. The two part model framework characterizes both the demand using a probability distribution for each type of service request as well as enterprise computing resource constraints. Our simulations provide quantitative analysis to design and provision computing architectures that maximize overall mission effectiveness. We share our analysis of key resource constraints in cloud computing architectures and findings on the appropriateness of cloud computing in various applications.

Stocker, John C.↗