Search NASA⌕ Search

SEARCH · Search NASA

Results for “architecture definition”

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 109 records · Page 6

Deep Space Habitat ECLSS Design Concept

Life support is vital to human spaceflight, and most current life support systems employ single-use hardware or regenerable technologies that throw away the waste products, relying on resupply to make up the consumables lost in the process. Because the long-term goal of the National Aeronautics and Space Administration is to expand human presence beyond low-earth orbit, life support systems must become self-sustaining for missions where resupply is not practical. From May through October 2011, the life support team at the Johnson Space Center was challenged to define requirements, develop a system concept, and create a preliminary life support system design for a non-planetary Deep Space Habitat that could sustain a crew of four in near earth orbit for a duration of 388 days. Some of the preferred technology choices to support this architecture were passed over because the mission definition has an unmanned portion lasting 825 days. The main portion of the architecture was derived from technologies currently integrated on the International Space Station as well as upcoming technologies with moderate Technology Readiness Levels. The final architecture concept contains only partially-closed air and water systems, as the breakeven point for some of the closure technologies was not achieved with the mission duration.

Curley, Su↗

The NASA Integrated Information Technology Architecture

This document defines an Information Technology Architecture for the National Aeronautics and Space Administration (NASA), where Information Technology (IT) refers to the hardware, software, standards, protocols and processes that enable the creation, manipulation, storage, organization and sharing of information. An architecture provides an itemization and definition of these IT structures, a view of the relationship of the structures to each other and, most importantly, an accessible view of the whole. It is a fundamental assumption of this document that a useful, interoperable and affordable IT environment is key to the execution of the core NASA scientific and project competencies and business practices. This Architecture represents the highest level system design and guideline for NASA IT related activities and has been created on the authority of the NASA Chief Information Officer (CIO) and will be maintained under the auspices of that office. It addresses all aspects of general purpose, research, administrative and scientific computing and networking throughout the NASA Agency and is applicable to all NASA administrative offices, projects, field centers and remote sites. Through the establishment of five Objectives and six Principles this Architecture provides a blueprint for all NASA IT service providers: civil service, contractor and outsourcer. The most significant of the Objectives and Principles are the commitment to customer-driven IT implementations and the commitment to a simpler, cost-efficient, standards-based, modular IT infrastructure. In order to ensure that the Architecture is presented and defined in the context of the mission, project and business goals of NASA, this Architecture consists of four layers in which each subsequent layer builds on the previous layer. They are: 1) the Business Architecture: the operational functions of the business, or Enterprise, 2) the Systems Architecture: the specific Enterprise activities within the context of IT systems, 3) the Technical Architecture: a common, vendor-independent framework for design, integration and implementation of IT systems and 4) the Product Architecture: vendor=specific IT solutions. The Systems Architecture is effectively a description of the end-user "requirements". Generalized end-user requirements are discussed and subsequently organized into specific mission and project functions. The Technical Architecture depicts the framework, and relationship, of the specific IT components that enable the end-user functionality as described in the Systems Architecture. The primary components as described in the Technical Architecture are: 1) Applications: Basic Client Component, Object Creation Applications, Collaborative Applications, Object Analysis Applications, 2) Services: Messaging, Information Broker, Collaboration, Distributed Processing, and 3) Infrastructure: Network, Security, Directory, Certificate Management, Enterprise Management and File System. This Architecture also provides specific Implementation Recommendations, the most significant of which is the recognition of IT as core to NASA activities and defines a plan, which is aligned with the NASA strategic planning processes, for keeping the Architecture alive and useful.

Baldridge, Tim↗

Deep Space Habitat ECLS Design Concept

Life support is vital to human spaceflight, and most current life support systems employ single-use hardware or regenerable technologies that throw away the waste products, relying on resupply to make up the consumables lost in the process. Because the long-term goal of the National Aeronautics and Space Administration is to expand human presence beyond low-earth orbit, life support systems must become self-sustaining for missions where resupply is not practical. From May through October 2011, the life support team at the Johnson Space Center was challenged to define requirements, develop a system concept, and create a preliminary life support system design for a non-planetary Deep Space Habitat that could sustain a crew of four in near earth orbit for a duration of 388 days. Some of the preferred technology choices to support this architecture were passed over as the mission definition also has an unmanned portion lasting 825 days. The main portion of the architecture was derived from technologies currently integrated on the International Space Station as well as upcoming technologies with moderate Technology Readiness Levels. The final architecture concept contains only partially-closed air and water systems, as the breakeven point for some of the closure technologies was not achieved with the mission duration.

Curley, Su↗

System architectures for telerobotic research

Several activities are performed related to the definition and creation of telerobotic systems. The effort and investment required to create architectures for these complex systems can be enormous; however, the magnitude of process can be reduced if structured design techniques are applied. A number of informal methodologies supporting certain aspects of the design process are available. More recently, prototypes of integrated tools supporting all phases of system design from requirements analysis to code generation and hardware layout have begun to appear. Activities related to system architecture of telerobots are described, including current activities which are designed to provide a methodology for the comparison and quantitative analysis of alternative system architectures.

Harrison, F. Wallace↗

Computer architecture for efficient algorithmic executions in real-time systems: New technology for avionics systems and advanced space vehicles

Improvements and advances in the development of computer architecture now provide innovative technology for the recasting of traditional sequential solutions into high-performance, low-cost, parallel system to increase system performance. Research conducted in development of specialized computer architecture for the algorithmic execution of an avionics system, guidance and control problem in real time is described. A comprehensive treatment of both the hardware and software structures of a customized computer which performs real-time computation of guidance commands with updated estimates of target motion and time-to-go is presented. An optimal, real-time allocation algorithm was developed which maps the algorithmic tasks onto the processing elements. This allocation is based on the critical path analysis. The final stage is the design and development of the hardware structures suitable for the efficient execution of the allocated task graph. The processing element is designed for rapid execution of the allocated tasks. Fault tolerance is a key feature of the overall architecture. Parallel numerical integration techniques, tasks definitions, and allocation algorithms are discussed. The parallel implementation is analytically verified and the experimental results are presented. The design of the data-driven computer architecture, customized for the execution of the particular algorithm, is discussed.

Carroll, Chester C.↗

Considerations and Architectures for Inter-Satellite Communications in Distributed Spacecraft Systems

This paper will identify the important characteristics and requirements necessary for inter-satellite communications in distributed spacecraft systems and present analysis results focusing on architectural and protocol comparisons. Emerging spacecraft systems plan to deploy multiple satellites in various "distributed" configurations ranging from close proximity formation flying to widely separated constellations. Distributed spacecraft configurations provide advantages for science exploration and operations since many activities useful for missions may be better served by distributing them between spacecraft. For example, many scientific observations can be enhanced through spatially separated platforms, such as for deep space interferometry. operating multiple distributed spacecraft as a mission requires coordination that may be best provided through inter-satellite communications. For example, several future distributed spacecraft systems envision autonomous operations requiring relative navigational calculations and coordinated attitude and position corrections. To conduct these operations, data must be exchanged between spacecraft. Direct cross-links between satellites provides an efficient and practical method for transferring data and commands. Unlike existing "bent-pipe" relay networks supporting space missions, no standard or widely-used method exists for cross-link communications. Consequently, to support these future missions, the characteristics necessary for inter-satellite communications need to be examined. At first glance, all of the missions look extremely different. Some missions call for tens to hundreds of nano-satellites in constant communications in close proximity to each other. Other missions call for a handful of satellites communicating very slowly over thousands to hundreds of thousands of kilometers. The paper will first classify distributed spacecraft missions to help guide the evaluation and definition of cross-link architectures and approaches. Based on this general classification, the paper will examine general physical layer parameters, such as frequency bands and data rates, necessary to support the missions. The paper will also identify classes of communication architectures that may be employed, ranging from fully distributed to centralized topologies. Numerous factors, such as number of spacecraft, must be evaluated when attempting to pick a communications architecture. Also important is the stability of the formation from a communications standpoint. For example, do all of the spacecraft require equal bandwidth and are spacecraft allowed to enter and leave a formation? The type of science mission being attempted may also heavily influence the communications architecture. In addition, the paper will assess various parameters and characteristics typically associated with the data link layer. The paper will analyze the performance of various multiple access techniques given the operational scenario, requirements, and communication topologies envisioned for missions. This assessment will also include a survey of existing standards and their applicability for distributed spacecraft systems. An important consideration includes the interoperability of the lower layers (physical and data link) examined in this paper with the higher layer protocols(network) envisioned for future space internetworking. Finally, the paper will define a suggested path, including preliminary recommendations, for defining and developing a standard for intersatellite communications based on the classes of distributed spacecraft missions and analysis results.

Edwards, Bernard↗

Lessons learned in the development of the Hubble Space Telescope software

An effort is made to document what was successful in the HST software development, and to present a retrospective analysis indicating what could have been done more efficiently. Consideration is given to systems engineering and design definition, standards and tools, system architecture and design, operational considerations, and reuse and adaptation of existing resources.

Harrington, Michael↗

A Framework for Intelligent Rocket Test Facilities with Smart Sensors

A long-term center goal at the John C. Stennis Space Center (SSC) is the formulation and implementation of a framework for an Intelligent Rocket Test Facility (IRTF), which incorporates distributed smart sensor elements. The IRTF is to provide reliable, high-confident measurements. Specific objectives include: 1. Definition of a framework and architecture that supports implementation of highly autonomous methodologies founded on basic physical principles and embedded knowledge. 2. Modeling of autonomous sensors and processes as self-sufficient, evolutionary elements. 3. Development of appropriate communications protocols to enable the complex interactions that must take place to allow timely and high-quality flow of of information among all the autonomous elements of the system. 4. Development of lab-scale prototypes of key system elements. Though our application is next-generation rocket test facilities, applications for the approach are much wider and include monitoring of shuttle launch operations, air and spacecraft operations and health monitoring, and other large-scale industrial system operations such as found in processing and manufacturing plans. Elements of prototype IRTF have been implemented in preparation for advanced development and validation using rocket test stand facilities as SSC. This work has identified issues that are important to further development of complex network and should be of interest to other working with sensor networks.

Figueroa, Fernando↗

A Modular Instrumentation System for NASA's Habitat Demonstration Unit

NASA's human spaceflight program is focused on developing technologies to expand the reaches of human exploration and science activities beyond low earth orbit. A critical aspect of living in space or on planetary surfaces is habitation, which provides a safe and comfortable space in which humans can live and work. NASA is seeking out the best option for habitation by exploring several different concepts through the Habitat Demonstration Unit (HDU) project. The purpose of this HDU is to develop a fully autonomous habitation system that enables human exploration of space. One critical feature of the HDU project that helps to accomplish its mission of autonomy is the instrumentation system that monitors key subsystems operating within a Habitat configuration. The following paper will discuss previous instrumentation systems used in analog habitat concepts and how the current instrumentation system being implemented on the HDU1-PEM, or pressurized excursion module, is building upon the lessons learned of those previous systems. Additionally, this paper will discuss the benefits and the limitations of implementing a wireless sensor network (WSN) as the basis for data transport in the instrumentation system. Finally, this paper will address the experiences and lessons learned with integration, testing prior to deployment, and field testing at the JSC rock yard. NASA is developing the HDU1-PEM as a step towards a fully autonomous habitation system that enables human exploration of space. To accomplish this purpose, the HDU project is focusing on development, integration, testing, and evaluation of habitation systems. The HDU will be used as a technology pull, testbed, and integration environment in which to advance NASA's understanding of alternative mission architectures, requirements, and operations concepts definition and validation. This project is a multi-year effort. In 2010, the HDU1-PEM will be in a pressurized excursion module configuration, and in 2011 the module will be reconfigured for a pressurized core module configuration. Each year the HDU configurations will undergo testing at NASA's Desert Research and Technology Studies (D-RaTS) in Arizona [1]. As part of this project, a modular instrumentation system is developed to meet the monitoring needs of the HDU subsystems and to integrate with the current command and data handling infrastructure that has been developed for the project. The main objective of this study is to provide for the monitoring needs of the HDU. The requirements necessary to meet this objective are developed by working with the subsystem managers of the HDU to understand their monitoring needs. Additionally, the instrumentation system design leverages knowledge and lessons learned from previous studies, such as the inflatable habitat health monitoring system that was deployed in Antarctica [2], the integrated health monitoring system developed for NASA's Microhab [3], and the JSC Lunar Habitat Wireless Testbed to demonstrate a "standardsbased" approach to a wireless instrumentation system [4]. The HDU also requires flexibility in reconfiguration options, and it is necessary to demonstrate and evaluate a modular approach to an instrumentation system. Thus, the instrumentation system is designed in two parts: the primary system employs a standard WSN configuration, and the secondary system employs a wired USB hub. The WSN design provides for reconfiguration or replacement of sensors due to malfunctions or upgrades by using a wireless node that accepts ten instrument inputs and wirelessly transmits the data to the command and data handling system. The USB hub is necessary for those instruments that operate using a wired USB connection, although the design attempts to limit the amount of sensors that need to be wired connections.

Rojdev, Kristina↗

Architectural Analysis of Systems Based on the Publisher-Subscriber Style

Architectural styles impose constraints on both the topology and the interaction behavior of involved parties. In this paper, we propose an approach for analyzing implemented systems based on the publisher-subscriber architectural style. From the style definition, we derive a set of reusable questions and show that some of them can be answered statically whereas others are best answered using dynamic analysis. The paper explains how the results of static analysis can be used to orchestrate dynamic analysis. The proposed method was successfully applied on the NASA's Goddard Mission Services Evolution Center (GMSEC) software product line. The results show that the GMSEC has a) a novel reusable vendor-independent middleware abstraction layer that allows the NASA's missions to configure the middleware of interest without changing the publishers' or subscribers' source code, and b) some high priority bugs due to behavioral discrepancies, which were eluded during testing and code reviews, among different implementations of the same APIs for different vendors.

Ganesun, Dharmalingam↗

Science Objectives of the ACCP/AOS Millimeter- and Submillimeter-Wave Radiometers

Passive microwave radiometers provide highly useful information regarding the Earth system by measuring thermal emission (from the surface and atmosphere) that is reflected, absorbed, and scattered by the surface and the atmosphere. As such, radiometers have been instrumental across Earth-observing concepts with heritage tracing back to the Nimbus era, and clouds and precipitation have been key geophysical phenomena these sensors have targeted. As millimeter-wave (particularly ≥85 GHz) and submillimeter-wave technologies have advanced, the applicability of microwave radiometers has expanded to encompass falling snow and ice clouds, respectively. Given the strong heritage of microwave radiometry and the emergence of submillimeter-wave sensors for sensing falling snow and ice clouds, the National Academies’ 2017 Decadal Survey for Earth Science and Applications from Space recommended passive sensors covering these wavelengths be included in observing systems that address the Aerosols, Clouds, Convection, and Precipitation (ACCP) combined designated observable. To showcase the capabilities for addressing the ACCP science objectives, we will provide an overview of the passive microwave capabilities envisioned for the Atmosphere Observing System (AOS, part of the recently unveiled NASA Earth System Observatory), including descriptions of the radiometers for the inclined and polar orbits and the primary geophysical variables of interest related to ice-phase clouds and precipitation. We will also discuss secondary science objectives, such as precipitation mapping, that can be achieved with the ACCP/AOS radiometers. Examples from the analyses performed for the ACCP/AOS architecture study and subsequent sensor definition exercises will be presented, outlining the basis for the radiometer configuration within the context of the overarching ACCP/AOS goals to elucidate the connections between atmospheric dynamics, weather (including extreme events), air quality, and climate.

Ian S Adams↗

Lessons Learned in Systems Engineering Availability and Recommendations for Mission Technical Leaders

In spaceflight missions at Goddard Space Flight Center (GSFC), the Mission System Engineer (MSE) is the technical leader of the overall engineering team and also is the Independent Engineering Technical Authority. The responsibility of this role includes the definition of the mission design architecture, concept of operations, and mission requirements, management of risk throughout the development, and verification and validation of the final system performance and function amongst other duties. This responsibility inherently requires time management, enabling focus on a balanced development with appropriate risk. Time is the most valuable resource of the MSE. The system engineer’s availability to interact with the development team (often product or component design leads and technicians, often in different worksites) to discover and mitigate mission risks during development is key to mission success. This paper presents examples from Lunar Reconnaissance Orbiter, Landsat 9, and Neutron star Interior Composition ExploreR (NICER) which represent in-house and out-of-house hardware builds. These examples demonstrate how interactions between the Mission Systems Engineers and other project and partner engineers result in discovery of critical risks, leading to early mitigation with significant cost and performance savings. These three missions would have suffered test failures or on-orbit failures had their MSEs not set aside time to visit engineers and technicians that were working on key pieces of space flight hardware. Availability is more than just time; it is openness to listen to concerns and questions. It begins by building a level of trust in the team that it is safe to ask questions or share concerns without the fear of blame or additional workload. It also requires enabling informal conversations (over lunch, coffee, in the clean room, or at the team members desk, etc.) where key information can be exchanged, and team members may even provide an easy-to-implement mitigation idea for another subsystem. Availability is a highly valuable commodity and completely non-obvious to protect and optimize. The natural tendency of engineers is to keep themselves busy with solving problems that they know about. This paper is encouraging MSEs to resist this tendency to try and solve all the complex problems themselves and actively devote daily time to learning and solving problems that are found with informal communications with other team members.

Lessons Learned↗

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.↗

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.↗

Selection of a Data Acquisition and Controls System Communications and Software Architecture for Johnson Space Center's Space Environment Simulation Laboratory Thermal and Vacuum Test Facilities

Upgrade of data acquisition and controls systems software at Johnson Space Center's Space Environment Simulation Laboratory (SESL) involved the definition, evaluation and selection of a system communication architecture and software components. A brief discussion of the background of the SESL and its data acquisition and controls systems provides a context for discussion of the requirements for each selection. Further framework is provided as upgrades to these systems accomplished in the 1990s and in 2003 are compared to demonstrate the role that technological advances have had in their improvement. Both of the selections were similar in their three phases; 1) definition of requirements, 2) identification of candidate products and their evaluation and testing and 3) selection by comparison of requirement fulfillment. The candidates for the communication architecture selection embraced several different methodologies which are explained and contrasted. Requirements for this selection are presented and the selection process is described. Several candidates for the software component of the data acquisition and controls system are identified, requirements for evaluation and selection are presented, and the evaluation process is described.

Jordan, Eric A.↗

NASA Human Spaceflight Architecture Team Cis-Lunar Analysis

The Cis-Lunar Destination Team of NASA's Human Spaceflight Architecture Teait1 (HAT) has been perfom1ing analyses of a number of cis-lunar locations to infom1 architecture development, transportation and destination elements definition, and operations. The cis-lunar domain is defined as that area of deep space under the gravitation influence of the earth-moon system, including a set of orbital locations (low earth orbit (LEO]. geosynchronous earth orbit [GEO]. highly elliptical orbits [HEO]); earth-moon libration or "Lagrange·· points (EMLl through EMLS, and in particular, EMLI and EML2), and low lunar orbit (LLO). We developed a set of cis-lunar mission concepts defined by mission duration, pre-deployment, type of mission, and location, to develop mission concepts and the associated activities, capabilities, and architecture implications. To date, we have produced two destination operations J concepts based on present human space exploration architectural considerations. We have recently begun defining mission activities that could be conducted within an EM LI or EM L2 facility.

Lupisella, M.↗

The Role of Cis-Lunar Space in Future Global Space Exploration

Cis-lunar space offers affordable near-term opportunities to help pave the way for future global human exploration of deep space, acting as a bridge between present missions and future deep space missions. While missions in cis-lunar space have value unto themselves, they can also play an important role in enabling and reducing risk for future human missions to the Moon, Near-Earth Asteroids (NEAs), Mars, and other deep space destinations. The Cis-Lunar Destination Team of NASA's Human Spaceflight Architecture Team (HAT) has been analyzing cis-lunar destination activities and developing notional missions (or "destination Design Reference Missions" [DRMs]) for cis-lunar locations to inform roadmap and architecture development, transportation and destination elements definition, operations, and strategic knowledge gaps. The cis-lunar domain is defined as that area of deep space under the gravitational influence of the earth-moon system. This includes a set of earth-centered orbital locations in low earth orbit (LEO), geosynchronous earth orbit (GEO), highly elliptical and high earth orbits (HEO), earth-moon libration or "Lagrange" points (E-ML1 through E-ML5, and in particular, E-ML1 and E-ML2), and low lunar orbit (LLO). To help explore this large possibility space, we developed a set of high level cis-lunar mission concepts in the form of a large mission tree, defined primarily by mission duration, pre-deployment, type of mission, and location. The mission tree has provided an overall analytical context and has helped in developing more detailed design reference missions that are then intended to inform capabilities, operations, and architectures. With the mission tree as context, we will describe two destination DRMs to LEO and GEO, based on present human space exploration architectural considerations, as well as our recent work on defining mission activities that could be conducted with an EML1 or EML2 facility, the latter of which will be an emphasis of this paper, motivated in part by recent interest expressed at the Global Exploration Roadmap Stakeholder meeting. This paper will also explore the links between this HAT Cis-Lunar Destination Team analysis and the recently released ISECG Global Exploration Roadmap and other potential international considerations, such as preventing harmful interference to radio astronomy observations in the shielded zone of the moon.

Bobskill, Marianne R.↗

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.↗