Search NASA⌕ Search

SEARCH · Search NASA

Results for “Infrastructure deployment”

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 199 records · Page 11
All sourcesNASA NTRSDOE OSTI
NASA NTRS2016

The Earth Observing System (EOS) Ground System: Leveraging an Existing Operational Ground System Infrastructure to Support New Missions

The Earth Observer System (EOS) was officially established in 1990 and went operational in December 1999 with the launch of its flagship spacecraft Terra. Aqua followed in 2002 and Aura in 2004. All three spacecraft are still operational and producing valuable scientific data. While all are beyond their original design lifetime, they are expected to remain viable well into the 2020s. The EOS Ground System is a multi-mission system based at NASA Goddard Space Flight Center that supports science and spacecraft operations for these three missions. Over its operational lifetime to date, the EOS Ground System has evolved as needed to accommodate mission requirements. With an eye towards the future, several updates are currently being deployed. Subsystem interconnects are being upgraded to reduce data latency and improve system performance. End-of-life hardware and operating systems are being replaced to mitigate security concerns and eliminate vendor support gaps. Subsystem hardware is being consolidated through the migration to Virtual Machine based platforms. While mission operations autonomy was not a design goal of the original system concept, there is an active effort to apply state-of-the-art products from the Goddard Mission Services Evolution Center (GMSEC) to facilitate automation where possible within the existing heritage architecture. This presentation will provide background information on the EOS ground system architecture and evolution, discuss latest improvements, and conclude with the results of a recent effort that investigated how the current system could accommodate a proposed new earth science mission.

Earth Science Mission Operations (ESMO)↗
NASA NTRSDate not supplied

Reducing Barriers in Space Weather Research and Operations with Next-Generation Simulation Services at the Community Coordinated Modeling Center (CCMC)

Space weather forecasting capabilities are becoming increasingly important to the health of advanced technological infrastructure. The Community Coordinated Modeling Center (CCMC, https://ccmc.gsfc.nasa.gov) serves as a key liaison in the US space weather program between the research and operations communities by providing a wide range of tools and capabilities that help to evaluate, compare, exercise, and archive the results of simulations of a growing list of space weather models. With its unique toolset, CCMC supports space weather research and model development that advances our understanding of space weather phenomena and improves forecasting skill, while also facilitating development of space weather applications and deployment of operational capabilities. Guided by experience from over 20 years of providing simulation services, feedback from its research, operational and educational users world-wide, recommendations from CCMC Advisory Group and Programmatic Review Panel, the CCMC has begun work on the next generation system for its simulation services and model output archives. The new system has been envisioned to employ state-of-the-art technologies and standards to provide a user-oriented experience while improving ease of access, transparency, interoperability with partner systems, and enhancing reliability by incorporating advanced automation for performance monitoring and intelligent failover. In the presentation, we will give an overview of the current CCMC ecosystem and discuss updates to some of the key services of the system, including Runs-on-Request, Instant Runs, and Continuous Runs. We will also describe how a planned expansion and standardization of data archival activities will enhance the role of CCMC as a world-class provider of heliophysics information for the research and analysis of space weather. It is our hope that this evolution of the services can further reduce the barriers and burdens on researchers, forecasters and decision makers who rely on CCMC for their daily research and operations.

Space Weather↗
NASA NTRS2013

Unique Offerings of the ISS as an Earth Observing Platform

The International Space Station offers unique capabilities for earth remote sensing. An established Earth orbiting platform with abundant power, data and commanding infrastructure, the ISS has been in operation for twelve years as a crew occupied science laboratory and offers low cost and expedited concept-to-operation paths for new sensing technologies. Plug in modularity on external platforms equipped with structural, power and data interfaces standardizes and streamlines integration and minimizes risk and start up difficulties. Data dissemination is also standardized. Emerging sensor technologies and instruments tailored for sensing of regional dynamics may not be worthy of dedicated platforms and launch vehicles, but may well be worthy of ISS deployment, hitching a ride on one of a variety of government or commercial visiting vehicles. As global acceptance of the urgent need for understanding Climate Change continues to grow, the value of ISS, orbiting in Low Earth Orbit, in complementing airborne, sun synchronous polar, geosynchronous and other platform remote sensing will also grow.

Cooley, Victor M.↗
NASA NTRS2010

The Evolvable Advanced Multi-Mission Operations System (AMMOS): Making Systems Interoperable

The Advanced Multi-Mission Operations System (AMMOS) provides a common Mission Operation System (MOS) infrastructure to NASA deep space missions. The evolution of AMMOS has been driven by two factors: increasingly challenging requirements from space missions, and the emergence of new IT technology. The work described in this paper focuses on three key tasks related to IT technology requirements: first, to eliminate duplicate functionality; second, to promote the use of loosely coupled application programming interfaces, text based file interfaces, web-based frameworks and integrated Graphical User Interfaces (GUI) to connect users, data, and core functionality; and third, to build, develop, and deploy AMMOS services that are reusable, agile, adaptive to project MOS configurations, and responsive to industrially endorsed information technology standards.

MGSS↗
NASA NTRS2026

A Multi-Tier Autonomous Aerial Architecture for Wildfire Detection, Characterization, and Communication in Infrastructure-Denied Environments

Wildfire response depends on how fast an ignition can be confirmed and located, especially in remote regions where ground-based communication and monitoring may be limited. Geostationary sensors provide frequent observations but at kilometer-scale resolution, which is too coarse to resolve small fires in remote terrain. Ground camera networks require sightlines and infrastructure that back-country areas lack. To address these limitations, this work proposes a Multi-Tier Autonomous Wildfire Intelligence System that combines wide-area monitoring with targeted, high-resolution sensing. A solar-powered high-altitude long endurance (HALE) platform operating at approximately 60,000 ft provides persistent wide-area thermal and optical surveillance, running onboard edge inference to screen candidate ignitions and reduce false positives and downlink bandwidth. When a candidate ignition is detected, low-altitude uncrewed aircraft systems (UAS) can be deployed to conduct localized observations, including high-resolution imaging and atmospheric measurements such as wind and plume observation. By combining persistent detection with local sensing, the proposed architecture is designed to provide first responders with timely, high-resolution information about fire location and behavior to aid in emergency decision making.

Wildfire management, UAS, drones↗
NASA NTRS2017

Remote Advanced Payload Test Rig (RAPTR) Portable Payload Test System for the International Space Station (ISS)

The RAPTR was developed to test ISS payloads for NASA. RAPTR is a simulation of the Command and Data Handling (C&DH) interfaces of the ISS (MIL-STD 1553B, Ethernet and TAXI) and is designed to facilitate rapid testing and deployment of payload experiments to the ISS. The ISS Program's goal is to reduce the amount of time it takes a payload developer to build, test and fly a payload, including payload software. The RAPTR meets this need with its user oriented, visually rich interface. Additionally, the Analog and Discrete (A&D) signals of the following payload types may be tested with RAPTR: (1) EXPRESS Sub Rack Payloads; (2) ELC payloads; (3) External Columbus payloads; (4) External Japanese Experiment Module (JEM) payloads. The automated payload configuration setup and payload data inspection infrastructure is found nowhere else in ISS payload test systems. Testing can be done with minimal human intervention and setup, as the RAPTR automatically monitors parameters in the data headers that are sent to, and come from the experiment under test.

Calvert, John↗
NASA NTRSDate not supplied

Gateway Autonomy for Enabling Deep Space Exploration

The Gateway spacecraft is an important stepping-stone to exploration of the solar system, integrating commercial and international partners into a tightly coupled system, enabling cislunar activities, and implementing key technologies for missions to Mars. Autonomy is a capability area necessary to handle long communication outages where intervention from Earth is impossible, to prepare to operate with long communication delays that will be common in interplanetary travel, and to make spaceflight more affordable and accessible by reducing sustaining operations costs. The Gateway Concept of Operations states that one of Gateway’s goals is to “focus on infrastructure and systems that will allow autonomous operations aboard the Gateway with robotics, automated systems, advanced communications, and distributed computing.” Gateway’s Vehicle Systems Manager (VSM) and associated Autonomous Spacecraft Management Architecture (ASMA) are key products towards delivering autonomous capability. The primary functions of the control architecture are Mission Management and Timeline Execution, Resource Management, Fault Management, and Vehicle Control and Operation (VCO). In each of these areas, there is an initial level of capability to be delivered at launch, with plans to continue development and grow to greater capability. The initial deployment of VSM will focus on maintaining vehicle safety by focusing on full fault management capabilities and deploying only enough resource and timeline planning functionality to support that. The final deployment of VSM will add significant planning and control optimization functionality to support nominal operations for up to 21 days without ground support, even accommodating fault and failure conditions. While the VSM is the vehicle-level representation of autonomous reasoning, distributed automation is essential to provide the right scope and abstraction of information to process. Module and system support of automation and simplicity of interfaces are two important design paradigms that Gateway is focusing on to garner a systems approach to autonomy. Distribution of reasoning can increase complexity, so Gateway is also taking a strict hierarchical approach to information flow and decision making. VSM is not the only capability necessary to achieve an autonomous spacecraft. Robotics support for maintenance of the spacecraft will be essential to provide continued vehicle functionality even when crew is not present. Technical and programmatic challenges exist when implementing autonomous robotics operations. These challenges include sufficient network flexibility to support data transfer to the rest of the vehicle to coordinate module-to-module robotic walk-offs and finding the proper interfaces to allow sufficient dexterity. Communication system upgrades planned for Gateway include Delay Tolerant Networking to best utilize the complex network of relays that will be part of mature cislunar operations. Distributed computing and management will provide failure tolerance, robustness, and growth of capabilities while still allowing significant reuse of heritage software on heritage systems as well as reuse of common applications across a spacecraft to minimize new development, but this requires adherence to key standards and interfaces. The Gateway program has demonstrated significant progress towards these capabilities and has identified challenges other spacecraft developers should be aware of from the start.

Molly Anderson↗
NASA NTRSDate not supplied

Gateway Autonomy for Enabling Deep Space Exploration

The Gateway spacecraft is an important stepping-stone to exploration of the solar system, integrating commercial and international partners into a tightly coupled system, enabling cislunar activities, and implementing key technologies for missions to Mars. Autonomy is a capability area necessary to handle long communication outages where intervention from Earth is impossible, to prepare to operate with long communication delays that will be common in interplanetary travel, and to make spaceflight more affordable and accessible by reducing sustaining operations costs. The Gateway Concept of Operations states that one of Gateway’s goals is to “focus on infrastructure and systems that will allow autonomous operations aboard the Gateway with robotics, automated systems, advanced communications, and distributed computing.” Gateway’s Vehicle Systems Manager (VSM) and associated Autonomous Spacecraft Management Architecture (ASMA) are key products towards delivering autonomous capability. The primary functions of the control architecture are Mission Management and Timeline Execution, Resource Management, Fault Management, and Vehicle Control and Operation (VCO). In each of these areas, there is an initial level of capability to be delivered at launch, with plans to continue development and grow to greater capability. The initial deployment of VSM will focus on maintaining vehicle safety by focusing on full fault management capabilities and deploying only enough resource and timeline planning functionality to support that. The final deployment of VSM will add significant planning and control optimization functionality to support nominal operations for up to 21 days without ground support, even accommodating fault and failure conditions. While the VSM is the vehicle-level representation of autonomous reasoning, distributed automation is essential to provide the right scope and abstraction of information to process. Module and system support of automation and simplicity of interfaces are two important design paradigms that Gateway is focusing on to garner a systems approach to autonomy. Distribution of reasoning can increase complexity, so Gateway is also taking a strict hierarchical approach to information flow and decision making. VSM is not the only capability necessary to achieve an autonomous spacecraft. Robotics support for maintenance of the spacecraft will be essential to provide continued vehicle functionality even when crew is not present. Technical and programmatic challenges exist when implementing autonomous robotics operations. These challenges include sufficient network flexibility to support data transfer to the rest of the vehicle to coordinate module-to-module robotic walk-offs and finding the proper interfaces to allow sufficient dexterity. Communication system upgrades planned for Gateway include Delay Tolerant Networking to best utilize the complex network of relays that will be part of mature cislunar operations. Distributed computing and management will provide failure tolerance, robustness, and growth of capabilities while still allowing significant reuse of heritage software on heritage systems as well as reuse of common applications across a spacecraft to minimize new development, but this requires adherence to key standards and interfaces. The Gateway program has demonstrated significant progress towards these capabilities and has identified challenges other spacecraft developers should be aware of from the start.

Molly Anderson↗
NASA NTRSDate not supplied

Options for Offloading a 90-Ton Common Habitat from its Lander on the Surface of Mars

The Common Habitat is a large, long-duration habitat being explored as part of a conceptual study (not an active NASA program) that uses an SLS core stage liquid oxygen (LOX) tank as its primary structure. Measuring 8.4 meters in diameter and 15.6 meters in length, it is manufactured as a habitat and launched as such into space. It is intended for use on the Moon as part of a permanently occupied outpost, on Mars as part of an outpost that will be occupied for hundreds of days at a time, and in deep space as part of the Deep Space Exploration Vehicle where it will support crewed missions up to 1200 days in duration. A study of internal orientation and crew size resulted in a Common Habitat configuration sized for a crew of eight with a three-deck horizontal orientation. There are obvious challenges associated with the delivery of such a large habitat, which may mass as much as 90-tons when initially deployed. The Mars destination in particular imposes extreme challenges due to Martian gravity. This paper identifies initial options for the offloading of a 90-ton Common Habitat from a lander spacecraft on the surface of Mars. On Mars, the Common Habitat is part of a surface outpost where a Habitation Zone includes the Common Habitat docked to a two-chamber airlock node, up to two logistics modules, and up to two pressurized rovers. It is connected by underground conduit to a radiator farm and communications tower assembly. These elements and other surface infrastructure, including robotic systems for surface preparation, are landed prior to the Common Habitat. In the baseline Common Habitat Architecture, the Common Habitat is delivered on the third heavy cargo flight. The Habitation Zone configuration dictates that the Common Habitat needs to be offloaded from the lander. All of the docked elements require direct access to the surface and the Common Habitat must actually be placed in a trench to lower its docking ports to be level with those of the mated elements. Additionally, the habitat must be emplaced in a horizontal configuration, while for any conceivable Earth launch system it must be launched in a vertical configuration. It is true that the Common Habitat must be offloaded from its lander on both the Moon and Mars and a common offloading system must therefore work in both destinations. Mars, however, is considered the driving case for offloading in most, but not all, aspects. A four-day internal study in 2021 recommended that a modified Starship be used to land the Common Habitat on Mars and considered multiple approaches to offload the Common Habitat from the payload section and lower it to the surface. The topic was presented at a public hackathon organized by the Johnson Space Center’s Emerge Employee Resource Group. One team took on the challenge and proposed a concept in some ways similar to the previously considered jib crane. Despite the excellent innovation in the team’s work, a number of study refinements are necessary to truly establish feasibility. These and other future work needed to mature the concept are discussed in this work.

Lander Offloading↗
NASA NTRS2006

Planning to Explore: Using a Coordinated Multisource Infrastructure to Overcome Present and Future Space Flight Planning Challenges

Few human endeavors present as much of a planning and scheduling challenge as space flight, particularly manned space flight. Just on the operational side of it, efforts of thousands of people across hundreds of organizations need to be coordinated. Numerous tasks of varying complexity and nature, from scientific to construction, need to be accomplished within limited mission time frames. Resources need to be carefully managed and contingencies worked out, often on a very short notice. From the beginning of the NASA space program, planning has been done by large teams of domain experts working months, sometimes years, to put together a single mission. This approach, while proven very reliable up to now, is becoming increasingly harder to sustain. Elevated levels of NASA space activities, from deployment of the new Crew Exploration Vehicle (CEV) and completion of the International Space Station (ISS), to the planned lunar missions and permanent lunar bases, will put an even greater strain on this largely manual process. While several attempts to automate it have been made in the past, none have fully succeeded. In this paper we describe the current NASA planning methods, outline their advantages and disadvantages, discuss the planning challenges of upcoming missions and propose a distributed planning/scheduling framework (CMMD) aimed at unifying and optimizing the planning effort. CMMD will not attempt to make the process completely automated, but rather serve in a decision support capacity for human managers and planners. It will help manage information gathering, creation of partial and consolidated schedules, inter-team negotiations, contingencies investigation, and rapid re-planning when the situation demands it. The fist area of CMMD application will be planning for Extravehicular Activities (EVA) and associated logistics. Other potential applications, not only in the space flight domain, and future research efforts will be discussed as well.

Balaban, Edward↗
NASA NTRS2016

High Data Rate Architecture (HiDRA)

One of the greatest challenges in developing new space technology is in navigating the transition from ground based laboratory demonstration at Technology Readiness Level 6 (TRL-6) to conducting a prototype demonstration in space (TRL-7). This challenge is com- pounded by the relatively low availability of new spacecraft missions when compared with aeronautical craft to bridge this gap, leading to the general adoption of a low-risk stance by mission management to accept new, unproven technologies into the system. Also in consideration of risk, the limited selection and availability of proven space-grade components imparts a severe limitation on achieving high performance systems by current terrestrial technology standards. Finally from a space communications point of view the long duration characteristic of most missions imparts a major constraint on the entire space and ground network architecture, since any new technologies introduced into the system would have to be compliant with the duration of the currently deployed operational technologies, and in some cases may be limited by surrounding legacy capabilities. Beyond ensuring that the new technology is verified to function correctly and validated to meet the needs of the end users the formidable challenge then grows to additionally include: carefully timing the maturity path of the new technology to coincide with a feasible and accepting future mission so it flies before its relevancy has passed, utilizing a limited catalog of available components to their maximum potential to create meaningful and unprecedented new capabilities, designing and ensuring interoperability with aging space and ground infrastructures while simultaneously providing a growth path to the future. The International Space Station (ISS) is approaching 20 years of age. To keep the ISS relevant, technology upgrades are continuously taking place. Regarding communications, the state-of-the-art communication system upgrades underway include high-rate laser terminals. These must interface with the existing, aging data infrastructure. The High Data Rate Architecture (HiDRA) project is designed to provide networked store, carry, and forward capability to optimize data flow through both the existing radio frequency (RF) and new laser communications terminal. The networking capability is realized through the Delay Tolerant Networking (DTN) protocol, and is used for scheduling data movement as well as optimizing the performance of existing RF channels. HiDRA is realized as a distributed FPGA memory and interface controller that is itself controlled by a local computer running DTN software. Thus HiDRA is applicable to other arenas seeking to employ next-generation communications technologies, e.g. deep space. In this paper, we describe HiDRA and its far-reaching research implications.

DTN↗
NASA NTRS2002

NASA Aviation Safety Program Weather Accident Prevention/weather Information Communications (WINCOMM)

Weather is a contributing factor in approximately 25-30 percent of general aviation accidents. The lack of timely, accurate and usable weather information to the general aviation pilot in the cockpit to enhance pilot situational awareness and improve pilot judgment remains a major impediment to improving aviation safety. NASA Glenn Research Center commissioned this 120 day weather datalink market survey to assess the technologies, infrastructure, products, and services of commercial avionics systems being marketed to the general aviation community to address these longstanding safety concerns. A market survey of companies providing or proposing to provide graphical weather information to the general aviation cockpit was conducted. Fifteen commercial companies were surveyed. These systems are characterized and evaluated in this report by availability, end-user pricing/cost, system constraints/limits and technical specifications. An analysis of market survey results and an evaluation of product offerings were made. In addition, recommendations to NASA for additional research and technology development investment have been made as a result of this survey to accelerate deployment of cockpit weather information systems for enhancing aviation safety.

Feinberg, Arthur↗
NASA NTRS2021

On-demand Command and Control of ASTERIA with Cloud-based Ground Station Services

ASTERIA (Arcsecond Space Telescope Enabling Research in Astrophysics) was a 6-unit CubeSat technology demonstration mission that deployed from the International Space Station on November 20th, 2017. After successfully completing its 90-day primary mission that demonstrated arcsecond-level line-of-sight pointing and focal plane thermal stability for exoplanet detection, it entered an extended mission performing onboard software demonstrations to mature technology both in space and on the ground. One of the technologies was a completely cloud-based ground system leveraging Amazon Web Services (AWS) Ground Station service.Announced in December 2018 and launched in May 2019, AWS Ground Station is a fully managed ground station service that aims to reduce the overhead associated with developing and maintaining ground system infrastructure throughout the mission lifecycle. AWS Ground Station makes available the suite of features required for any ground system in support of low-Earth orbit (LEO) and medium-Earth Orbit (MEO) satellite operations on-demand and without setting up or maintaining long-term contracts. Charges are incurred on a per-minute basis for antenna usage during scheduled tracks. Support is available for S-band uplink and downlink, along with X-band narrowband and wideband downlink. Missions that use the service may reserve tracks with any licensed AWS Ground Station antennas located across each service region and have direct access to any AWS services in support of mission operations.The cloud-based architecture built around the AWS Ground Station service greatly enhanced ASTERIA mission operations by enabling end-to-end pass automation, on-demand contact scheduling and contingency planning, along with more efficient data downlink through station availability and station-to-station handovers. It incorporated open-source software, particularly NASA's AMMOS Instrument Toolkit (AIT) and Open Mission Control Technologies (OpenMCT), along with the AWS application programming interfaces (API) to the Ground Station, Elastic Compute Cloud (EC2) and Simple Storage Service (S3) services. After showcasing operability in August 2019, the team continued using and improving this novel ground system architecture until the end of mission in December 2019. This paper describes the cloud-based ground system, how it was designed, tested, and evaluated with an in-orbit spacecraft, the operational capabilities that it enabled, along with lessons learned and recommendations for future missions.

Fesq, Lorraine↗
NASA NTRS2024

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↗
NASA NTRS2006

Antenna Technologies for Future NASA Exploration Missions

NASA s plans for the manned exploration of the moon and Mars will rely heavily on the development of a reliable communications infrastructure on the surface and back to Earth. Future missions will thus focus not only on gathering scientific data, but also on the formation of the communications network. In either case, unique requirements become imposed on the antenna technologies necessary to accomplish these tasks. For example, surface activity applications such as robotic rovers, human extravehicular activities (EVA), and probes will require small size, lightweight, low power, multi-functionality, and robustness for the antenna elements being considered. Trunk-line communications to a centralized habitat on the surface and back to Earth (e.g., surface relays, satellites, landers) will necessitate wide-area coverage, high gain, low mass, deployable antennas. Likewise, the plethora of low to high data rate services desired to guarantee the safety and quality of mission data for robotic and human exploration will place additional demands on the technology. Over the past year, NASA Glenn Research Center has been heavily involved in the development of candidate antenna technologies with the potential for meeting these strict requirements. This technology ranges from electrically small antennas to phased array and large inflatable structures. A summary of this overall effort is provided, with particular attention being paid to small antenna designs and applications. A discussion of the Agency-wide activities of the Exploration Systems Mission Directorate (ESMD) in forthcoming NASA missions, as they pertain to the communications architecture for the lunar and Martian networks is performed, with an emphasis on the desirable qualities of potential antenna element designs for envisioned communications assets. Identified frequency allocations for the lunar and Martian surfaces, as well as asset-specific data services will be described to develop a foundation for viable antenna technologies which might address these requirements and help guide future technology development decisions.

Miranda, Felix A.↗
NASA NTRS2012

Cloud Computing for Mission Design and Operations

The space mission design and operations community already recognizes the value of cloud computing and virtualization. However, natural and valid concerns, like security, privacy, up-time, and vendor lock-in, have prevented a more widespread and expedited adoption into official workflows. In the interest of alleviating these concerns, we propose a series of guidelines for internally deploying a resource-oriented hub of data and algorithms. These guidelines provide a roadmap for implementing an architecture inspired in the cloud computing model: associative, elastic, semantical, interconnected, and adaptive. The architecture can be summarized as exposing data and algorithms as resource-oriented Web services, coordinated via messaging, and running on virtual machines; it is simple, and based on widely adopted standards, protocols, and tools. The architecture may help reduce common sources of complexity intrinsic to data-driven, collaborative interactions and, most importantly, it may provide the means for teams and agencies to evaluate the cloud computing model in their specific context, with minimal infrastructure changes, and before committing to a specific cloud services provider.

cloud computing↗
NASA NTRS2021

On-demand Command and Control of ASTERIA with Cloud-based Ground Station Services

ASTERIA (Arcsecond Space Telescope Enabling Research in Astrophysics) was a 6-unit CubeSat technology demonstration mission that deployed from the International Space Station on November 20th, 2017. After successfully completing its 90-day primary mission that demonstrated arcsecond-level line-of-sight pointing and focal plane thermal stability for exoplanet detection, it entered an extended mission performing onboard software demonstrations to mature technology both in space and on the ground. One of the technologies was a completely cloud-based ground system leveraging Amazon Web Services (AWS) Ground Station service. Announced in December 2018 and launched in May 2019, AWS Ground Station is a fully managed ground station service that aims to reduce the overhead associated with developing and maintaining ground system infrastructure throughout the mission lifecycle. AWS Ground Station makes available the suite of features required for any ground system in support of low-Earth orbit (LEO) and medium-Earth Orbit (MEO) satellite operations on-demand and without setting up or maintaining long-term contracts. Charges are incurred on a per-minute basis for antenna usage during scheduled tracks. Support is available for S-band uplink and downlink, along with X-band narrowband and wideband downlink. Missions that use the service may reserve tracks with any licensed AWS Ground Station antennas located across each service region and have direct access to any AWS services in support of mission operations. The cloud-based architecture built around the AWS Ground Station service greatly enhanced ASTERIA mission operations by enabling end-to-end pass automation, on-demand contact scheduling and contingency planning, along with more efficient data downlink through station availability and station-tostation handovers. It incorporated open-source software, particularly NASA's AMMOS Instrument Toolkit (AIT) and Open Mission Control Technologies (OpenMCT), along with the AWS application programming interfaces (API) to the Ground Station, Elastic Compute Cloud (EC2) and Simple Storage Service (S3) services. After showcasing operability in August 2019, the team continued using and improving this novel ground system architecture until the end of mission in December 2019. This paper describes the cloud-based ground system, how it was designed, tested, and evaluated with an inorbit spacecraft, the operational capabilities that it enabled, along with lessons learned and recommendations for future missions.

Fesq, Lorraine↗
NASA NTRS2022

NASA's Responsible AI Plan

Artificial Intelligence (AI) is an integral part of today’s process of conducting science and technology development. At NASA, AI has become an integral and important tool for researchers, engineers, data scientists, and technologists in pursuing the ground-breaking discoveries that we are known for, including the command and controlling of our spacecraft and other supporting infrastructures. Consequently, research and engineering efforts incorporating AI have permeated almost every area of our work. It is contributing to NASA’s drive toward the future, not just of space science, but for society here at home. We are dedicated to continuing the use of AI in a safe and fully transparent approach so that the public can have high confidence in the outcomes and benefits. We believe that the plan outlined here will be responsive and contribute to the call for openness across the federal government. NASA is committed to responsible use of AI in all of its activities and in all phases of development and deployment of its space and terrestrial programs missions. NASA does not deliberately focus on “AI Research” as a separate field (we have no single “AI office” or “AI program”), rather NASA uses AI to build tools for its programs. This plan, being put forward, adheres to the Responsible AI (RAI) principles set and laid down by the White House in its Presidential Executive Order 13960. Our research, engineering and technical communities have been made aware of these guidelines and we are committed to an on-going process of educating and monitoring its implementation to ensure adherence to those principles. The vast majority of NASA’s use cases, which number almost 75 today, are geared toward analyzing the petabytes of data that NASA collects from its fleet of spacecraft across all disciplines, in human space exploration, and in aeronautics, etc.

Artificial Intelligence↗