Search NASA⌕ Search

SEARCH · Search NASA

Results for “space mission interoperability”

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 37 records · Page 2

Space mission support by NASA Space Network

Normal NASA operational considerations and Phase 1 of Space Network (SN) interoperability foresees S band cross support between user spacecraft and space networks or partnering agencies. A typical interoperable scenario for an S band user spacecraft of a partner space agency with the NASA SN is presented. ESA's Hermes Manned Spaceplane exemplifies a typical interoperable user. In order to demonstrate the support potential of the NASA SN, the internal and external interfaces of the TDRSS (Tracking and Data Relay Satellite System), ATDRSS (Advanced TDRSS), and supporting elements are examined. Communications and operational requirements for a typical mission supported by the NASA SN are discussed.

Godfrey, Robert↗

Space Communications and Navigation (SCaN) Integrated Network Architecture Definition Document (ADD): Executive Summary - Volume 1

The SCaN Program has defined an integrated network architecture that fully meets the Administrator s mandate to the Program, and will result in a NASA infrastructure capable of providing the needed and enabling communications services to future space missions. The integrated network architecture will increase SCaN operational efficiency and interoperability through standardization, commonality and technology infusion. It will enable NASA missions requiring advanced communication and tracking capabilities such as: a. Optical communication b. Antenna arraying c. Lunar and Mars Relays d. Integrated network management (service management and network control) and integrated service execution e. Enhanced tracking for navigation f. Space internetworking with DTN and IP g. End-to-end security h. Enhanced security services Moreover, the SCaN Program has created an Integrated Network Roadmap that depicts an orchestrated and coherent evolution path toward the target architecture, encompassing all aspects that concern network assets (i.e., operations and maintenance, sustaining engineering, upgrade efforts, and major development). This roadmap identifies major NASA ADPs, and shows dependencies and drivers among the various planned undertakings and timelines. The roadmap is scalable to accommodate timely adjustments in response to Agency needs, goals, objectives and funding. Future challenges to implementing this architecture include balancing user mission needs, technology development, and the availability of funding within NASA s priorities. Strategies for addressing these challenges are to: define a flexible architecture, update the architecture periodically, use ADPs to evaluate options and determine when to make decisions, and to engage the stakeholders in these evaluations. In addition, the SCaN Program will evaluate and respond to mission need dates for technical and operational capabilities to be provided by the SCaN integrated network. In that regard, the architecture defined in this ADD is scalable to accommodate programmatic and technical changes.

Younes, Badri A.↗

Interoperable End-To-End Space Communications Architecture Using CCSDS Building Blocks

End-to-end space communication architectures must connect system elements that may be in space, on the ground in mission operations centers, or are shared assets such as ground communications stations. End-to-end connectivity involves space communications over RF links, but also cross support services, terrestrial network circuits, and a variety of application layer protocols for commanding, telemetry, and mission operations. CCSDS has developed a large suite of interoperable, and cross-supportable, protocols for these purposes. Each of these defines a specific “layer” of functionality, such as: RF modulation, space link error coding, cross support frame delivery, or network layer routing. CCSDS has recently published a Space Communication Cross Support Architecture Requirements Document (SCCS-ARD) that describes how many of these standards fit together and how they are intended to be used. This paper provides an overview of this document, presented so as to explain the concepts so that others may use them. These concepts will be described from several key viewpoints.

Shames, Peter M.↗

Interoperable End-To-End Space Communications Architectures Using CCSDS Building Blocks

End-to-end space communication architectures must connect system elements that may be in space, on the ground in mission operations centers, or are shared assets such as ground communications stations. End-to-end connectivity involves space communications over RF links, but also cross support services, terrestrial network circuits, and a variety of application layer protocols for commanding, telemetry, and mission operations. CCSDS has developed a large suite of interoperable, and cross-supportable, protocols for these purposes. Each of these defines a specific “layer” of functionality, such as: RF modulation, space link error coding, cross support frame delivery, or network layer routing. CCSDS has recently published a Space Communication Cross Support Architecture Requirements Document (SCCS-ARD) that describes how many of these standards fit together and how they are intended to be used. This paper provides an overview of this document, presented so as to explain the concepts so that others may use them. These concepts will be described from several key viewpoints.

Shames, Peter M.↗

Software-Defined Radio for Space-to-Space Communications

A paper describes the Space- to-Space Communications System (SSCS) Software- Defined Radio (SDR) research project to determine the most appropriate method for creating flexible and reconfigurable radios to implement wireless communications channels for space vehicles so that fewer radios are required, and commonality in hardware and software architecture can be leveraged for future missions. The ability to reconfigure the SDR through software enables one radio platform to be reconfigured to interoperate with many different waveforms. This means a reduction in the number of physical radio platforms necessary to support a space mission s communication requirements, thus decreasing the total size, weight, and power needed for a mission.

Fisher, Ken↗

A Deeper Dive Into the Meaning and Implications of Interoperability for LunaNet Communications and Navigation Services

As part of planning efforts for cislunar exploration and science missions, space agencies have been collaborating with each other to enable communications, networking, Position, Navigation, and Timing (PNT) systems to exchange information and provide services to spacecraft and space systems in transit, in orbit, and on the surface, thus helping each other to achieve their common goals. To achieve commonality and lower cost for mutual benefit, the strategy of interoperability is being adopted to help all the pieces fit together and function smoothly. Interoperability gives cislunar users the ability to operate in a collaborative environment similar to the terrestrial Internet, allowing them to share information, navigate safely despite increasing radio frequency congestion, and follow common processes and procedures for effective joint operations. Unlike prior government-dominated efforts, this ecosystem is expected to include commercial for-profit businesses, non-profit organizations, and academic institutions. Ultimately, the goal is to enable a cislunar ecosystem of service providers and users to contribute and/or utilize infrastructure and capabilities to accomplish mission objectives spanning the full range of human endeavours while supporting a variety of business models. This paper reports on the results of an effort to assist in efforts to frame the development of the international LunaNet architecture by providing a canonical definition of interoperability broad enough to meet these needs, examine architectural and operational implications of the definition, and explore interoperability strategies and tactics for deploying and evolving these services. It describes key systems-of-systems (SoS) (Network-of-Networks) interoperability concepts in the context of sustainment of the ecosystem over time as systems evolve in technologies, standards and Standards Development Organizations, component and subsystem upgrades, and user applications

LunaNet↗

Architecting the Communication and Navigation Networks for NASA's Space Exploration Systems

NASA is planning a series of short and long duration human and robotic missions to explore the Moon and then Mars. A key objective of the missions is to grow, through a series of launches, a system of systems communication, navigation, and timing infrastructure at minimum cost while providing a network-centric infrastructure that maximizes the exploration capabilities and science return. There is a strong need to use architecting processes in the mission pre-formulation stage to describe the systems, interfaces, and interoperability needed to implement multiple space communication systems that are deployed over time, yet support interoperability with each deployment phase and with 20 years of legacy systems. In this paper we present a process for defining the architecture of the communications, navigation, and networks needed to support future space explorers with the best adaptable and evolable network-centric space exploration infrastructure. The process steps presented are: 1) Architecture decomposition, 2) Defining mission systems and their interfaces, 3) Developing the communication, navigation, networking architecture, and 4) Integrating systems, operational and technical views and viewpoints. We demonstrate the process through the architecture development of the communication network for upcoming NASA space exploration missions.

Bhassin, Kul B.↗

High Level Architecture Distributed Space System Simulation for Simulation Interoperability Standards Organization Simulation Smackdown

Modeling and Simulation plays a very important role in mission design. It not only reduces design cost, but also prepares astronauts for their mission tasks. The SISO Smackdown is a simulation event that facilitates modeling and simulation in academia. The scenario of this year s Smackdown was to simulate a lunar base supply mission. The mission objective was to transfer Earth supply cargo to a lunar base supply depot and retrieve He-3 to take back to Earth. Federates for this scenario include the environment federate, Earth-Moon transfer vehicle, lunar shuttle, lunar rover, supply depot, mobile ISRU plant, exploratory hopper, and communication satellite. These federates were built by teams from all around the world, including teams from MIT, JSC, University of Alabama in Huntsville, University of Bordeaux from France, and University of Genoa from Italy. This paper focuses on the lunar shuttle federate, which was programmed by the USRP intern team from NASA JSC. The shuttle was responsible for provide transportation between lunar orbit and the lunar surface. The lunar shuttle federate was built using the NASA standard simulation package called Trick, and it was extended with HLA functions using TrickHLA. HLA functions of the lunar shuttle federate include sending and receiving interaction, publishing and subscribing attributes, and packing and unpacking fixed record data. The dynamics model of the lunar shuttle was modeled with three degrees of freedom, and the state propagation was obeying the law of two body dynamics. The descending trajectory of the lunar shuttle was designed by first defining a unique descending orbit in 2D space, and then defining a unique orbit in 3D space with the assumption of a non-rotating moon. Finally this assumption was taken away to define the initial position of the lunar shuttle so that it will start descending a second after it joins the execution. VPN software from SonicWall was used to connect federates with RTI during testing and the Smackdown event. HLA software from Pitch Technology and MAK Technology were used to edit and extend FOM and provide HLA services for federation execution. The SISO Smackdown event for 2011 was held in Boston, Massachusetts. The federation execution lasted for one hour, and the event was very successful in catching the attention of university students and faculties.

Li, Zuqun↗

Moving Toward Space Internetworking via DTN: Its Operational Challenges, Benefits, and Management

The international space community has begun to recognize that the established model for management of communications with spacecraft - commanded data transmission over individual pair-wise contacts - is operationally unwieldy and will not scale in support of increasingly complex and sophisticated missions such as NASA's Constellation project. Accordingly, the international Inter-Agency Operations Advisory Group (IOAG) ichartered a Space Internetworking Strategy Group (SISG), which released its initial recommendations in a November 2008 report. The report includes a recommendation that the space flight community adopt Delay-Tolerant Networking (DTN) to address the problem of interoperability and communication scaling, especially in mission environments where there are multiple spacecraft operating in concert. This paper explores some of the issues that must be addressed in implementing, deploying, and operating DTN as part of a multi-mission, multi-agency space internetwork as well as benefits and future operational scenarios afforded by DTN-based space internetworking.

Delay Tolerant Networking↗

Wireless Network Communications Overview for Space Mission Operations

The mission of the On-Board Wireless Working Group (WWG) is to serve as a general CCSDS focus group for intra-vehicle wireless technologies. The WWG investigates and makes recommendations pursuant to standardization of applicable wireless network protocols, ensuring the interoperability of independently developed wireless communication assets. This document presents technical background information concerning uses and applicability of wireless networking technologies for space missions. Agency-relevant driving scenarios, for which wireless network communications will provide a significant return-on-investment benefiting the participating international agencies, are used to focus the scope of the enclosed technical information.

Fink, Patrick W.↗

Packet telemetry and packet telecommand - The new generation of spacecraft data handling techniques

Because of rising costs and reduced reliability of spacecraft and ground network hardware and software customization, standardization Packet Telemetry and Packet Telecommand concepts are emerging as viable alternatives. Autonomous packets of data, within each concept, which are created within ground and space application processes through the use of formatting techniques, are switched end-to-end through the space data network to their destination application processes through the use of standard transfer protocols. This process may result in facilitating a high degree of automation and interoperability because of completely mission-independent-designed intermediate data networks. The adoption of an international guideline for future space telemetry formatting of the Packet Telemetry concept, and the advancement of the NASA-ESA Working Group's Packet Telecommand concept to a level of maturity parallel to the of Packet Telemetry are the goals of the Consultative Committee for Space Data Systems. Both the Packet Telemetry and Packet Telecommand concepts are reviewed.

Hooke, A. J.↗

Finalizing the CCSDS Space-Data Link Layer Security Protocol: Setup and Execution of the Interoperability Testing

The protection of data transmitted over the space-link is an issue of growing importance also for civilian space missions. Through the Consultative Committee for Space Data Systems (CCSDS), space agencies have reacted to this need by specifying the Space Data-Link Layer Security (SDLS) protocol which provides confidentiality and integrity services for the CCSDS Telemetry (TM), Telecommand (TC) and Advanced Orbiting Services (AOS) space data-link protocols. This paper describes the approach of the CCSDS SDLS working group to specify and execute the necessary interoperability tests. It first details the individual SDLS implementations that have been produced by ESA, NASA, and CNES and then the overall architecture that allows the interoperability tests between them. The paper reports on the results of the interoperability tests and identifies relevant aspects for the evolution of the test environment.

Fischer, Daniel↗

SpaceVPX Interoperability Assessment

The existing VMEbus (VersaModular Eurocard bus) International Trade Association (VITA)-78 industry standard, also known as SpaceVPX, is an avionics board- and chassis-level standard derived from the OpenVPX standard as defined in VITA-65. While VITA-65 defines backplane and board-level profiles from COTS vendors to ensure interoperability of products used in developing systems and subsystems, the VITA-78 standard defines SpaceVPX to incorporate fault tolerance features that are required by many spaceflight systems. However, VITA-78 allows so much flexibility that interoperability between modules cannot be assured. This assessment provides guidelines on the use of, and extensions to, the VITA-78 standard to enable avionics interoperability for future NASA missions. The assessment team was comprised of subject matter experts (SMEs) from Goddard Space Flight Center (GSFC), the Jet Propulsion Laboratory (JPL), Johnson Space Center (JSC), and Langley Research Center (LaRC). The team included valuable external consulting support from a SME who was a key participant in the development of the VITA-78 standard. The team had extensive collaboration with the NASA Space Technology Mission Directorate (STMD) High Performance Spaceflight Computing (HPSC) project, specifically in the development of SpaceVPX interconnect findings, observations, and NESC recommendations. To provide an understanding of the breadth of implementations that SpaceVPX must accommodate, multiple NASA use cases were analyzed to assess the requirements for SpaceVPX implementations across a wide range of NASA missions (Appendix C). Applications included crewed missions, science missions, and orbital and surface robotic systems. Product surveys were conducted to assess the level of industry support for SpaceVPX, applications, and the variations in their implementations (Appendix D). In-depth analysis was conducted in the areas of: (a) power management and distribution, (b) form factors and daughtercards, (c) interconnect, and (d) fault tolerance. Leveraging the use cases, product surveys, and SMEs from multiple NASA Centers, these areas were analyzed to determine the range of implementations permitted by the VITA-78 standard and potential interoperability issues. Applicable findings and NESC recommendations were provided for each area. During this assessment, there were multiple opportunities to engage with other agencies to learn about their interest in SpaceVPX, their strategies for implementing SpaceVPX-based systems, and their internal development efforts. These engagements also generated findings and NESC recommendations. Based on this assessment analysis, NESC recommendations were made regarding the feature set and module profiles to support NASA SpaceVPX implementations. This feature set includes restrictions on features in VITA-78, and extensions to the standard. Key recommendations in this area include the use of 10 Gigabit Ethernet and Peripheral Component Interconnect Express (PCIe) as high bandwidth interconnect on the backplane, the retention of SpaceWire interconnect for control functions, and support for 3U (unit) and 6U, form factors for NASA systems. Restrictions were proposed on the usage of user-defined signals to promote interoperability, and specific power managements and distribution schemes for 3U systems. Beyond the technical implementation of SpaceVPX, recommendations were made on areas that warrant further investigation. Primary among these is the recommendation for NASA to collaborate with other space-going agencies and industry to incorporate recommendations into a future ‘dot spec’ of VITA-78. This would ensure wide adoption and availability of the modules that comply with the specification. The assessment includes appendices with candidate module profiles that can be considered as a starting point for this activity, and example systems based on the recommendations. Follow-on studies are recommended for architectures beyond SpaceVPX to address potential enhancements including condensed set of interconnect, software required to implement protocol layers on the interconnect (and other features), alternative power architectures, and system-level testability.

SpaceVPX↗

Earth-Independent Medical Operations (EIMO) Concept of Operations

Compared to the current paradigm for crew health in low-Earth orbit and Lunar missions that rely on constant communication with Mission Control, there is an anticipated shift in medical operations for deep-space exploration missions. This shift stems from mission constraints imposed by the considerable distance from Earth, which include resource limitations due to a lack of resupply, mass, power, volume, and data limitations, challenges imposed by communication latency and the inability to evacuate in case of emergencies. To transition towards a more self-reliant medical approach, a comprehensive strategy is essential to progressively enable crew autonomy and mitigate mission success risks in the challenging environment of space. This transformative shift is collectively referred to as "Earth-Independent Medical Operations" (EIMO), signifying the gradual transfer of medical care and decision-making from terrestrial resources to space-based assets. This transition is aimed at bolstering astronaut health and performance while simultaneously reducing the overall risks associated with space missions. The constraints related to EIMO necessitate an integrated development of medical systems, featuring interoperability with mission planning, vehicle design, spacesuit design, and data architecture. This integration is vital in establishing a robust medical infrastructure that not only supports the well-being of astronauts but also ensures the success of the mission as a whole. The Human Research Program (HRP) Exploration Medical Capability (ExMC) Element has developed a model-based Concept of Operations (ConOps) outlining an initial vision for EIMO. Within this ConOps, a comprehensive view is presented, encompassing stakeholder needs, system objectives, and system goals associated with EIMO. Additionally, it provides illustrative examples of the various activities (scenarios) for which the system will be employed during missions. The selection of these activities has been meticulous, aiming to encompass a wide spectrum of medical conditions, including those falling under different risk categories, such as low-likelihood-low-consequence, low-likelihood-high-consequence, and high-likelihood-low-consequence. The selection of these activities (scenarios) effectively encompasses the wide range of medical events situated within an assumed probability-consequence bell curve. In each scenario, at least one of the five main EIMO components identified is captured. Those EIMO components are: Pre-mission Planning, Acute and Emergent Management Decision Making, Prolonged Medical Management Decision Making, Supplies and Resource Management, and Task Load Management. The ConOps was developed by a multidisciplinary team consisting of systems engineers, scientists, and clinicians across NASA and aims to serve as an initial recommendation to gradually and safely enabling crew autonomy for Mars missions and beyond.

Earth Independent Medical Operations↗

Earth-Independent Medical Operations (EIMO) Concept of Operations (ConOps)

Compared to the current paradigm for crew health in low-Earth orbit and Lunar missions that rely on constant communication with Mission Control, there is an anticipated shift in medical operations for deep-space exploration missions. This shift stems from mission constraints imposed by the considerable distance from Earth, which include resource limitations due to a lack of resupply, mass, power, volume, and data limitations, challenges imposed by communication latency and the inability to evacuate in case of emergencies. To transition towards a more self-reliant medical approach, a comprehensive strategy is essential to progressively enable crew autonomy and mitigate mission success risks in the challenging environment of space. This transformative shift is collectively referred to as "Earth-Independent Medical Operations" (EIMO), signifying the gradual transfer of medical care and decision-making from terrestrial resources to space-based assets. This transition is aimed at bolstering astronaut health and performance while simultaneously reducing the overall risks associated with space missions. The constraints related to EIMO necessitate an integrated development of medical systems, featuring interoperability with mission planning, vehicle design, spacesuit design, and data architecture. This integration is vital in establishing a robust medical infrastructure that not only supports the well-being of astronauts but also ensures the success of the mission as a whole. The Human Research Program (HRP) Exploration Medical Capability (ExMC) Element has developed a model-based Concept of Operations (ConOps) outlining an initial vision for EIMO. Within this ConOps, a comprehensive view is presented, encompassing stakeholder needs, system objectives, and system goals associated with EIMO. Additionally, it provides illustrative examples of the various activities (scenarios) for which the system will be employed during missions. The selection of these activities has been meticulous, aiming to encompass a wide spectrum of medical conditions, including those falling under different risk categories, such as low-likelihood-low-consequence, low-likelihood-high-consequence, and high-likelihood-low-consequence. The selection of these activities (scenarios) effectively encompasses the wide range of medical events situated within an assumed probability-consequence bell curve. In each scenario, at least one of the five main EIMO components identified is captured. Those EIMO components are: Pre-mission Planning, Acute and Emergent Management Decision Making, Prolonged Medical Management Decision Making, Supplies and Resource Management, and Task Load Management. The ConOps was developed by a multidisciplinary team consisting of systems engineers, scientists, and clinicians across NASA and aims to serve as an initial recommendation to gradually and safely enabling crew autonomy for Mars missions and beyond.

Earth Independent Medical Operations↗

The NASA Space Communications Data Networking Architecture

The NASA Space Communications Architecture Working Group (SCAWG) has recently been developing an integrated agency-wide space communications architecture in order to provide the necessary communication and navigation capabilities to support NASA's new Exploration and Science Programs. A critical element of the space communications architecture is the end-to-end Data Networking Architecture, which must provide a wide range of services required for missions ranging from planetary rovers to human spaceflight, and from sub-orbital space to deep space. Requirements for a higher degree of user autonomy and interoperability between a variety of elements must be accommodated within an architecture that necessarily features minimum operational complexity. The architecture must also be scalable and evolvable to meet mission needs for the next 25 years. This paper will describe the recommended NASA Data Networking Architecture, present some of the rationale for the recommendations, and will illustrate an application of the architecture to example NASA missions.

Israel, David J.↗

CCSDS SM and C Mission Operations Interoperability Prototype

This slide presentation reviews the prototype of the Spacecraft Monitor and Control (SM&C) Operations for interoperability among other space agencies. This particular prototype uses the German Space Agency (DLR) to test the ideas for interagency coordination.

Lucord, Steven A.↗

Deeper Dive into Interoperability and Its Implications for LunaNet Communications and Navigation Services

The Artemis program being developed by United States’ (US) National Aeronautics and Space Administration (NASA) is developing the capabilities to return humans to the Moon and establish an initial base camp and associated infrastructure with extensive contributions from international and commercial partners. In planning for cislunar exploration and science missions, space agencies are collaborating to enable communications, networking, and Positioning, Navigation, and Timing (PNT) systems—called LunaNet—to exchange information and provide services to cislunar spacecraft and space systems, thus helping each other to achieve their shared goals. To achieve commonality and lower cost for mutual benefit, the strategy of interoperability is being adopted to help fit all the pieces together and function smoothly. Facilitating interoperability should benefit lunar missions by providing the ability to operate in a collaborative environment similar to the terrestrial Internet. Interoperability allows them to share information, navigate safely despite increasing radio frequency congestion, and follow common processes and procedures for effective joint operations. Unlike prior government-dominated efforts, this ecosystem is expected to include and benefit for-profit (commercial) businesses, non-profit organizations, and academic institutions as active stakeholders. Ultimately, the goal is to enable a cislunar ecosystem of service providers and users to contribute to and/or utilize infrastructure and capabilities to achieve mission objectives that span the full range of human endeavors while supporting a variety of business models. This approach enables a Systems of Systems (SoS), such as a Network-of-Networks, to be sustainable in the context of the LunaNet ecosystem as systems evolve over time in technologies, standards, components, and user applications. This paper reports on the results of an effort to help frame the development of the international LunaNet architecture by providing a canonical definition of interoperability broad enough to meet these needs, examining architectural and operational implications of the definition, and exploring interoperability strategies and tactics to deploy and evolve the services proposed for cislunar exploration and science missions.

interoperability↗