Architecture Centric Evoluation and Evaluation (ACE2) and the reference architecture for space data systems
Explore the source record for details and available documents.
cost savings↗
SEARCH · Engineering Papers
Results for “architectures”
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.
Safety Critical Software Architecture: A Partitioned Software Architecture for Robotic Spacecraft
No abstract available
Software Architecture,↗
Fabrics in Space Architecture: History and Examples of Textile Architecture for Advance Space Habitats
No abstract available
space suit↗
Different Classes of TPS Architectures and the Influence of Material and Architecture on Failure Mode Evolution and Mars Sample Return: Grand Challenge for EDL
No abstract available
Grand Challenge for EDL↗
Space Station needs, attributes and architectural options study. Volume 7-4A: Data book, architecture, technology and programmatics, part A
Various parameters of the orbital space station are discussed. The space station environment, data management system, communication and tracking, environmental control, and life support system are considered. Specific topics reviewed include crew work stations, restraint systems, stowage, computer hardware, and expert systems.
Source record↗
Space station needs, attributes and architectural options study. Volume 7-4B: Data book, architecture, technology and programmatics, part B
The remote manipulating system, the pointing control system, and the external radiator for the core module of the space station are discussed. The principal interfaces for four basic classes of user and transportation vehicles or facilities associated with the space station were examined.
Source record↗
Component architecture - the software architecture for mission requirements
This paper presents the challenges in developing a dynamic service such as FEI to support various mission requirements while being able to reduce cost on maintenance without sacrificing reliability and performance.
component software product lines design patterns↗
OSAM Tech Transfer Architectures Overview: Architectures and Modular Concepts
Explore the source record for details and available documents.
OSAM↗
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.↗
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↗
Software Defined Radio Architecture Contributions to Next Generation Space Communications
Space communications architecture concepts, comprising the elements of the system, the interactions among them, and the principles that govern their development, are essential factors in developing National Aeronautics and Space Administration (NASA) future exploration and science missions. Accordingly, vital architectural attributes encompass flexibility, the extensibility to insert future capabilities, and to enable evolution to provide interoperability with other current and future systems. Space communications architectures and technologies for this century must satisfy a growing set of requirements, including those for Earth sensing, collaborative observation missions, robotic scientific missions, human missions for exploration of the Moon and Mars where surface activities require supporting communications, and in-space observatories for observing the earth, as well as other star systems and the universe. An advanced, integrated, communications infrastructure will enable the reliable, multipoint, high-data-rate capabilities needed on demand to provide continuous, maximum coverage for areas of concentrated activity. Importantly, the cost/value proposition of the future architecture must be an integral part of its design; an affordable and sustainable architecture is indispensable within anticipated future budget environments. Effective architecture design informs decision makers with insight into the capabilities needed to efficiently satisfy the demanding space-communication requirements of future missions and formulate appropriate requirements. A driving requirement for the architecture is the extensibility to address new requirements and provide low-cost on-ramps for new capabilities insertion, ensuring graceful growth as new functionality and new technologies are infused into the network infrastructure. In addition to extensibility, another key architectural attribute of the space communication equipment's interoperability with other NASA communications systems, as well as those communications and navigation systems operated by international space agencies and civilian and government agencies. In this paper, we review the philosophies, technologies, architectural attributes, mission services, and communications capabilities that form the structure of candidate next-generation integrated communication architectures for space communications and navigation. A key area that this paper explores is from the development and operation of the software defined radio for the NASA Space Communications and Navigation (SCaN) Testbed currently on the International Space Station (ISS). Evaluating the lessons learned from development and operation feed back into the communications architecture. Leveraging the reconfigurability provides a change in the way that operations are done and must be considered. Quantifying the impact on the NASA Space Telecommunications Radio System (STRS) software defined radio architecture provides feedback to keep the standard useful and up to date. NASA is not the only customer of these radios. Software defined radios are developed for other applications, and taking advantage of these developments promotes an architecture that is cost effective and sustainable. Developments in the following areas such as an updated operating environment, higher data rates, networking and security can be leveraged. The ability to sustain an architecture that uses radios for multiple markets can lower costs and keep new technology infused.
Lessons Learned↗
Exploration Systems Development Mission Directorate: Moon to Mars Architecture Definition Document
The National Aeronautics and Space Administration (NASA) explores the unknown in air and space, innovates for the benefit of humanity, and inspires the world through discovery. Extending the reach of humanity through the human exploration of the Moon, Mars, and beyond is key to that mission. NASA’s Moon to Mars Strategy and Objectives document establishes long-term goals and objectives for crewed deep space exploration; however, satisfying NASA’s Moon to Mars Objectives requires an innovative approach to the definition, management, and execution of NASA’s Moon to Mars Architecture. An architecture offers a high-level unifying structure and defines a system. It provides rules, guidelines, and constraints that define a cohesive and coherent framework that identifies constituent parts, relationships, and connections and establishes how those parts fit and work together. This Architecture Definition Document (ADD) establishes the process for the decomposition of objectives empowers the agency’s success in achieving human exploration of the cosmos. NASA updates this document annually to reflect the maturation of the architecture and the progress NASA and partners make toward achieving exploration objectives. The ADD is not a manifest or requirements document. Instead, it serves as a tool for the programs, projects, and engineers who will implement and execute NASA’s bold ambitions for crewed exploration of deep space. As established in the Moon to Mars Strategy and Objectives, “Why” we explore encompasses three pillars: Science, Inspiration, and National Posture. Ensuring success in all three areas requires an architectural approach that incorporates innovation, collaboration, and partnerships that can be sustained across a multi-decadal effort. This second revision (Rev-B) of the ADD, developed to support NASA’s 2024 Architecture Concept Review (ACR), incorporates several key updates to support the continued evolution of the architecture. Since the last revision of the ADD, NASA has significantly improved the clarity of the objective decomposition, which distills exploration objectives into the characteristics and needs and use cases and functions needed to achieve them. The updated decomposition incorporates findings from internal studies and diverse stakeholder feedback. A model-based systems engineering approach ensures coherence and consistency, removing inconsistency and repetition. Revision B also incorporates advancements to NASA’s Mars architecture, including insight into initial capabilities, systems, and operations necessary to support the Humans to Mars segment. Updates to objective decomposition for Mars add significant detail to the ADD and hint at areas of forward work and future study. An appendix adds greater depth in the future decisions needed for Mars that will drive lunar needs. They are not the only decisions to be made, but they will have huge effects on subsequent decisions. NASA continues to introduce new exploration systems into the architecture. Two new elements — initial surface habitat and lunar surface cargo lander—successfully passed mission concept review in 2024 as a result of extensive analysis, concept refinement, and studies. These elements and their respective reference missions appear in this revision. NASA also continues to apply architecture processes to cross-agency efforts and coordination with external stakeholders by including definitions of architecture technology gaps — essential areas for engagement across and beyond the agency. The technology gaps appendix identifies areas that need attention and innovation to enable future exploration. In publishing this information, NASA communicates the technologies and capabilities that may benefit from partnership with industry, academia, other U.S. government agencies, and international space agencies. Ultimately, NASA established the Moon to Mars Architecture approach to communicate and facilitate humanity’s journey into the universe according to the principles and recurring tenets of NASA’s Moon to Mars Strategy and Objectives. The NASA architecture team thanks their many stakeholders, participants, and partners for their efforts to review and provide feedback. Their support has been critical to the success of this approach.
Elements↗
Architecture Robustness in NASA’s Moon to Mars Capability Development – FY23 Data Results
In preparation for humanity’s return to the Moon, it is important to advance technologies and capabilities that will allow for sustainability on the lunar surface and prepare for human missions to Mars. As charged in Space Policy Directive-1, NASA’s Artemis program will advance and develop technologies on the lunar surface that can be leveraged towards a safe and successful human round-trip mission to Mars. NASA’s Exploration Systems Development Mission Directorate Capabilities Integration Team (ESDMD CIT) is advancing a continuous effort to identify and map gaps between capabilities and anticipated human spaceflight architecture elements. As upcoming exploration missions approach, the architectural design tradespace increasingly narrows. This paper provides an updated exploration of certain architectural and element design choices for upcoming missions to the Moon and Mars, comparing and contrasting capability gaps and classes of capability gaps that are architecture robust with those that are not. In doing so, we identify certain capabilities as relevant, and therefore robust, across varying architectural possibilities while identifying other capabilities as only applicable to specific architectural pathways. Capabilities that are applicable to multiple elements across the architecture have more architectural breadth because of their increased likelihood of remaining relevant even if changes are made to some elements they are mapped to. Correspondingly, capabilities that are applicable to specific elements across the architecture but are necessary under almost any eventuality have more architectural depth because of their increased likelihood of remaining relevant even if architecture changes are made. One of the key analyses in this paper is an exploration of architecture robustness as a function of capability area, as defined by the NASA Technology Taxonomy. These results are then evaluated and analyzed across human spaceflight architecture elements to gain a greater understanding of the relationships between exploration capabilities and the systems that will eventually be implemented. Additional insights regarding investment strategies are also considered. General conclusions about these relationships are drawn.
Gaps↗
Exploration Architecture with Quantum Inertial Gravimetry and In-Situ ChipSat Sensors
The Dual Exploration Architecture is a mission concept that combines remote sensing and in-situ observations into a single mission to answer planetary science questions that can only be answered with both types of data. Adoption of dual exploration architectures may short circuit the long, slow cycle of missions to inaccessible bodies by eliminating the need for separate precursor and follow-up missions. Additionally, the dual architecture possesses inherent flexibility that enables the design of adaptive, event-driven missions that are very different from traditional, largely pre-planned missions. Five key observations about the state and trends of planetary science exploration lead us to the dual architecture: increasing complexity of observations; scarcity of future mission opportunities; desire to capture transitory events; continued miniaturization of spacecraft components; and the Mars exploration cycle. Our goal in this study is to explore missions that can only happen using the dual architecture concept and find technology development needs that must be filled for those missions to compete. A survey of historical and current missions finds that opportunities for exploration are becoming less frequent, causing the flexibility and dual-nature elements of each mission to become more common. The dual exploration architecture takes these trends to their far conclusion, attempting to eliminate precursor and follow-up missions while still returning more scientific payoff. A study of the future of planetary science goals through the decadal survey reveals broad applicability of dual missions to solve mysteries that cannot be answered with a traditional mission architecture. These missions fall into three broad classes: choosing a local target from a global survey; dynamic/reactive science; and global in-situ networks. Two example missions of each class are notionally described. A deeper look at these dual architecture classes reveals four technology development needs that must be addressed for wide adoption of dual missions: passive landers; guided atmospheric probes; robust sensing packages; and small, precise orbital instruments. This study pursues a specific focus on two examples of such enabling technologies: the ChipSat and cold atom gravimetry. The ChipSat is a fully functional spacecraft-on-a-chip system that has broad versatility in the dual architecture mission space. Initial studies show that ChipSats could survive as passive impactor landers on bodies up to the size of Europa. Furthermore, COTS (Commercial Off-The-Shelf) components could provide an in-situ sensor suite that readily answers a number of pressing planetary science questions. Cold atom gravimetry uses inertial sensors based on light-pulse atom interferometry in a small form factor to map the gravity field of a body to precision equaling what would normally require two full spacecraft to achieve. The cold atom gravimeter provides an example of how advanced remote sensing capability can enable dual missions by providing greater returns in a significantly smaller package. Using the above two technologies, we study an example dual-architecture mission to both characterize and sample the subsurface oceans at Europa. The greatest scientific return in terms of detecting extraterrestrial life is in those regions where Europa’s ice crust is thin. The identification of regions with thin ice should therefore precede the selection of surface targets and dispatch of probes to those targets. This two-step process, if accomplished by separate flagship-scale missions, might take decades. As a result, a combined mission to both identify thin areas of Europa’s ice and follow up with surface observations at those regions is a good candidate for the dual-exploration architecture. This example mission consists of an orbiter spacecraft carrying a cold atom gravimeter capable of sensing or inferring the ice thickness on regional to local scales, along with a number of ChipSat probes capable of landing on the moon. The small size and weight of the ChipSats allows large numbers of them to be carried, ensuring that enough can be dropped to ensure survival of a minimum number of probes and potentially allowing for the in-situ sampling of multiple locations on the moon. The example missions and Europa case study show that amazing scientific return can obtained from dual-exploration architecture missions with a single launch by breaking the long timescales of planetary exploration and providing the flexibility to capturing transitory events and collect data across the local, regional, and global scales.
Exploration↗
Evaluation of Dual-Launch Lunar Architectures Using the Mission Assessment Post Processor
The National Aeronautics and Space Administrations (NASA) Constellation Program is currently designing a new transportation system to replace the Space Shuttle, support human missions to both the International Space Station (ISS) and the Moon, and enable the eventual establishment of an outpost on the lunar surface. The present Constellation architecture is designed to meet nominal capability requirements and provide flexibility sufficient for handling a host of contingency scenarios including (but not limited to) launch delays at the Earth. This report summarizes a body of work performed in support of the Review of U.S. Human Space Flight Committee. It analyzes three lunar orbit rendezvous dual-launch architecture options which incorporate differing methodologies for mitigating the effects of launch delays at the Earth. NASA employed the recently-developed Mission Assessment Post Processor (MAPP) tool to quickly evaluate vehicle performance requirements for several candidate approaches for conducting human missions to the Moon. The MAPP tool enabled analysis of Earth perturbation effects and Earth-Moon geometry effects on the integrated vehicle performance as it varies over the 18.6-year lunar nodal cycle. Results are provided summarizing best-case and worst-case vehicle propellant requirements for each architecture option. Additionally, the associated vehicle payload mass requirements at launch are compared between each architecture and against those of the Constellation Program. The current Constellation Program architecture assumes that the Altair lunar lander and Earth Departure Stage (EDS) vehicles are launched on a heavy lift launch vehicle. The Orion Crew Exploration Vehicle (CEV) is separately launched on a smaller man-rated vehicle. This strategy relaxes man-rating requirements for the heavy lift launch vehicle and has the potential to significantly reduce the cost of the overall architecture over the operational lifetime of the program. The crew launch occurs first, four days prior to the optimal trans-lunar injection (TLI) departure window. This is done to allow for launch delays in the Altair/EDS launch. During this time, the Orion vehicle is required to conduct orbit maintenance while loitering in low Earth orbit (LEO). The alternative architectures presented aim to eliminate the need for costly orbit maintenance maneuvers while loitering in LEO. In all of the alternative architectures considered, it is assumed that the Altair and Orion vehicles are nominally launched 90 minutes apart, depart the Earth separately, and complete the rendezvous and docking sequence at the Moon. In this lunar orbit rendezvous (LOR) strategy, both the Altair and Orion vehicles will require separate EDS stages, and each will be required to perform lunar orbit insertion (LOI). This has the effect of balancing payload requirements between the two launch vehicles at the Earth. In this case, the overall payload mass is increased slightly, but the increased mission costs could potentially be offset by requiring the construction of two rockets similar in size and nature, unlike the current Constellation architecture. Three dual-launch architecture options with LOR were evaluated, which incorporate differing methodologies for mitigating the effects of launch delays at the Earth. Benefits and drawbacks of each of the dual-launch architecture options with LOR are discussed and the overall mission performance is compared with that of the existing Constellation Program lunar architecture.
Stewart, Shaun M.↗
Marshall Application Realignment System (MARS) Architecture
The Marshall Application Realignment System (MARS) Architecture project was established to meet the certification requirements of the Department of Defense Architecture Framework (DoDAF) V2.0 Federal Enterprise Architecture Certification (FEAC) Institute program and to provide added value to the Marshall Space Flight Center (MSFC) Application Portfolio Management process. The MARS Architecture aims to: (1) address the NASA MSFC Chief Information Officer (CIO) strategic initiative to improve Application Portfolio Management (APM) by optimizing investments and improving portfolio performance, and (2) develop a decision-aiding capability by which applications registered within the MSFC application portfolio can be analyzed and considered for retirement or decommission. The MARS Architecture describes a to-be target capability that supports application portfolio analysis against scoring measures (based on value) and overall portfolio performance objectives (based on enterprise needs and policies). This scoring and decision-aiding capability supports the process by which MSFC application investments are realigned or retired from the application portfolio. The MARS Architecture is a multi-phase effort to: (1) conduct strategic architecture planning and knowledge development based on the DoDAF V2.0 six-step methodology, (2) describe one architecture through multiple viewpoints, (3) conduct portfolio analyses based on a defined operational concept, and (4) enable a new capability to support the MSFC enterprise IT management mission, vision, and goals. This report documents Phase 1 (Strategy and Design), which includes discovery, planning, and development of initial architecture viewpoints. Phase 2 will move forward the process of building the architecture, widening the scope to include application realignment (in addition to application retirement), and validating the underlying architecture logic before moving into Phase 3. The MARS Architecture key stakeholders are most interested in Phase 3 because this is where the data analysis, scoring, and recommendation capability is realized. Stakeholders want to see the benefits derived from reducing the steady-state application base and identify opportunities for portfolio performance improvement and application realignment.
Belshe, Andrea↗