SEARCH · Search NASA
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.
The test procedure used and the test results obtained during the long range thermal performance tests of the LARGO Solar Hot Water System under natural environmental conditions are presented. Objectives of these tests were to determine the amount of energy collected, the amount of power required for system operation, system efficiency, temperature distribution, and system performance degradation.
Autonomous Power Expert (APEX) computer program is prototype expert-system program detecting faults in electrical-power-distribution system. Assists human operators in diagnosing faults and deciding what adjustments or repairs needed for immediate recovery from faults or for maintenance to correct initially nonthreatening conditions that could develop into faults. Written in Lisp.
The algorithm to architecture mapping model (ATAAM) is a Petri net based model which provides a strategy for periodic execution of a class of real-time algorithms on multicomputer dataflow architecture. The execution of large-grained, decision-free algorithms on homogeneous processing elements is studied. The ATAAM provides an analytical basis for calculating performance bounds on throughput characteristics. Extension of the ATAMM as a strategy for cyclo-static scheduling provides for a truly distributed ATAMM multicomputer operating system. An ATAAM testbed consisting of a centralized graph manager and three processors is described using embedded firmware on 68HC11 microcontrollers.
In support of future deep space manned missions, an autonomous/automated vehicle, providing crew autonomy and an autonomous response planning system, will be required due to the light time delays in communication. Vehicle capabilities as a whole must provide for tactical response to vehicle system failures and space environmental effects induced failures, for risk mitigation of permanent loss of communication with Earth, and for assured crew return capabilities. The complexity of human rated space systems and the limited crew sizes and crew skills mix drive the need for a robust autonomous capability on-board the vehicle. The HAL 9000 Space Operating System[2] designed for such missions and space craft includes the first distributed real-time planning / re-planning system. This paper will detail the software architecture of the multiple planning engine system, and the interface design for plan changes, approval and implementation that is performed autonomously. Operations scenarios will be defined for analysis of the planning engines operations and its requirements for nominal / off nominal activities. An assessment of the distributed realtime re-planning system, in the defined operations environment, will be provided as well as findings as it pertains to the vehicle, crew, and mission control requirements needed for implementation.
The NASA Earth Science Data Information Systems Project funds and operates 12 Distributed Active Archive Center(s) (DAAC) throughout the United States. Of these 12 centers, the Physical Oceanography DAAC (PO.DAAC) is committed to providing long term archival, distribution and stewardship for NASA physical oceanographic data, primarily derived from space-born satellite systems, but also including a growing set of recent and future in situ observations from the SPURS-1 and SPURS-2 campaigns. Notable NASA missions supported include: Seasat, TOPEX/Poseidon, NSCAT, QuikSCAT, ISS-RapidScat, Jason-1, Jason-2/OSTM, GRACE, Aquarius, GHRSST, and MODIS. The following interagency and international missions are also supported by PO.DAAC: AVHRR, Coriolis, DMSP, MetOp-A, MetOp-B, Oceansat-2. The PO.DAAC currently holds 525 datasets in public distribution, spanning the following observational parameters: sea surface temperature, sea surface salinity, ocean color, ocean surface currents, ocean surface wind speed, ocean surface wind direction, sea surface height, significant wave height, ocean water mass/thickness, and sea ice age. A hundred of these datasets are available in near-real-time. Datasets are distributed through a variety of open-source access protocols including FTP, OPeNDAP, and THREDDS. FTP will soon be phased out in favor of a recently introduced HTTPS PO.DAAC Drive interface that supports WebDAV and interoperable machine-to-machine communication. OPeNDAP supports remote data/metadata query, subset, and download. THREDDS provides the features of OPeNDAP with the additional feature of temporal aggregation. PO.DAAC also offers proprietary tools and services to further enhance the data discovery, visualization and analysis experience, including but not limited to: State of the Ocean, Web Services (data/metadata discovery and extraction), HiTIDE Level-2 subsetter, Live Access Server (LAS), Webification (w10nsci), and Rich Site Summary (RSS) Datacasting. To assist with provenance of datasets, PO.DAAC has implemented DOIs for the data it distributes so that they can be properly cited. There is a user forum and helpdesk that contains data recipes and via which users can get guidance. In summary, this presentation aims to provide a general overview of PO.DAAC’s web portal and data holdings along with a set of illustrative examples leading prospective data users into the practical utility of its tools and services.
The NASA LeRC in Cleveland, Ohio has completed the development and integration of a Power Management and Distribution (PMAD) DC Testbed. This testbed is a reduced scale representation of the end to end, sources to loads, Space Station Freedom Electrical Power System (SSF EPS). This unique facility is being used to demonstrate DC power generation and distribution, power management and control, and system operation techniques considered to be prime candidates for the Space Station Freedom. A key capability of the testbed is its ability to be configured to address system level issues in support of critical SSF program design milestones. Electrical power system control and operation issues like source control, source regulation, system fault protection, end-to-end system stability, health monitoring, resource allocation, and resource management are being evaluated in the testbed. The SSF EPS control functional allocation between on-board computers and ground based systems is evolving. Initially, ground based systems will perform the bulk of power system control and operation. The EPS control system is required to continuously monitor and determine the current state of the power system. The DC Testbed Control System consists of standard controllers arranged in a hierarchical and distributed architecture. These controllers provide all the monitoring and control functions for the DC Testbed Electrical Power System. Higher level controllers include the Power Management Controller, Load Management Controller, Operator Interface System, and a network of computer systems that perform some of the SSF Ground based Control Center Operation. The lower level controllers include Main Bus Switch Controllers and Photovoltaic Controllers. Power system status information is periodically provided to the higher level controllers to perform system control and operation. The data acquisition function of the control system is distributed among the various levels of the hierarchy. Data requirements are dictated by the control system algorithms being implemented at each level. A functional description of the various levels of the testbed control system architecture, the data acquisition function, and the status of its implementationis presented.
Autonomous decision-making significantly increases mission effectiveness by mitigating the effects of communication constraints, like latency and bandwidth, and mission complexity on multi-spacecraft operations. To advance the state of the art in autonomous Distributed Space Systems (DSS), the Distributed Spacecraft Autonomy (DSA) team at NASA's Ames Research Center is developing within five relevant technical areas: distributed resource and task management, reactive operations, system modeling and simulation, human-swarm interaction, and ad hoc network communications. DSA is maturing these technologies - critical for future large autonomous DSS - from concept to launch via simulation studies and orbital deployments. A 100-node heterogenous Processor-in-the-Loop (PiL) testbed aids distributed autonomy capability development and verification of multi-spacecraft missions. The DSA software payload deployed to the D-Orbit SCV-004 spacecraft demonstrates multi-agent reconfigurability and reliability as part of an ESA-sponsored in-orbit technology demonstration. Finally, DSA's primary flight mission showcases collaborative resource allocation for multipoint science data collection with four small spacecraft as a payload on NASA's Starling 1.0 satellites.
Presented here is the Spacecraft Command Language (SCL) concept of the unification of ground and space operations using a distributed approach. SCL is a hybrid software environment borrowing from expert system technology, fifth generation language development, and multitasking operating system environments. Examples of potential uses for the system and current distributed applications of SCL are given.
The planning processes for the International Space Station (ISS) Program are quite complex. Detailed mission planning for ISS on-orbit operations is a distributed function. Pieces of the on-orbit plan are developed by multiple planning organizations, located around the world, based on their respective expertise and responsibilities. The "pieces" are then integrated to yield the final detailed plan that will be executed onboard the ISS. Previous space programs have not distributed the planning and scheduling functions to this extent. Major ISS planning organizations are currently located in the United States (at both the NASA Johnson Space Center (JSC) and NASA Marshall Space Flight Center (MSFC)), in Russia, in Europe, and in Japan. Software systems have been developed by each of these planning organizations to support their assigned planning and scheduling functions. Although there is some cooperative development and sharing of key software components, each planning system has been tailored to meet the unique requirements and operational environment of the facility in which it operates. However, all the systems must operate in a coordinated fashion in order to effectively and efficiently produce a single integrated plan of ISS operations, in accordance with the established planning processes. This paper addresses lessons learned during the development of these multiple distributed planning systems, from the perspective of the developer of one of the software systems. The lessons focus on the coordination required to allow the multiple systems to operate together, rather than on the problems associated with the development of any particular system. Included in the paper is a discussion of typical problems faced during the development and coordination process, such as incompatible development schedules, difficulties in defining system interfaces, technical coordination and funding for shared tools, continually evolving planning concepts/requirements, programmatic and budget issues, and external influences. Techniques that mitigated some of these problems will also be addressed, along with recommendations for any future programs involving the development of multiple planning and scheduling systems. Many of these lessons learned are not unique to the area of planning and scheduling systems, so may be applied to other distributed ground systems that must operate in concert to successfully support space mission operations.
The planning processes for the International Space Station (ISS) Program are quite complex. Detailed mission planning for ISS on-orbit operations is a distributed function. Pieces of the on-orbit plan are developed by multiple planning organizations, located around the world, based on their respective expertise and responsibilities. The pieces are then integrated to yield the final detailed plan that will be executed onboard the ISS. Previous space programs have not distributed the planning and scheduling functions to this extent. Major ISS planning organizations are currently located in the United States (at both the NASA Johnson Space Center (JSC) and NASA Marshall Space Flight Center (MSFC)), in Russia, in Europe, and in Japan. Software systems have been developed by each of these planning organizations to support their assigned planning and scheduling functions. Although there is some cooperative development and sharing of key software components, each planning system has been tailored to meet the unique requirements and operational environment of the facility in which it operates. However, all the systems must operate in a coordinated fashion in order to effectively and efficiently produce a single integrated plan of ISS operations, in accordance with the established planning processes. This paper addresses lessons learned during the development of these multiple distributed planning systems, from the perspective of the developer of one of the software systems. The lessons focus on the coordination required to allow the multiple systems to operate together, rather than on the problems associated with the development of any particular system. Included in the paper is a discussion of typical problems faced during the development and coordination process, such as incompatible development schedules, difficulties in defining system interfaces, technical coordination and funding for shared tools, continually evolving planning concepts/requirements, programmatic and budget issues, and external influences. Techniques that mitigated some of these problems will also be addressed, along with recommendations for any future programs involving the development of multiple planning and scheduling systems. Many of these lessons learned are not unique to the area of planning and scheduling systems, so may be applied to other distributed ground systems that must operate in concert to successfully support space mission operations.
The Multimission Ground Data System (MGDS) at NASA's Jet Propulsion Laboratory has brought improvements and new technologies to mission operations. It was designed as a generic data system to meet the needs of multiple missions and avoid re-inventing capabilities for each new mission and thus reduce costs. It is based on adaptable tools that can be customized to support different missions and operations scenarios. The MGDS is based on a distributed client/server architecture, with powerful Unix workstations, incorporating standards and open system architectures. The distributed architecture allows remote operations and user science data exchange, while also providing capabilities for centralized ground system monitor and control. The MGDS has proved its capabilities in supporting multiple large-class missions simultaneously, including the Voyager, Galileo, Magellan, Ulysses, and Mars Observer missions. The Operations Engineering Lab (OEL) at JPL has been leading Customer Adaptation Training (CAT) teams for adapting and customizing MGDS for the various operations and engineering teams. These CAT teams have typically consisted of only a few engineers who are familiar with operations and with the MGDS software and architecture. Our experience has provided a unique opportunity to work directly with the spacecraft and instrument operations teams and understand their requirements and how the MGDS can be adapted and customized to minimize their operations costs. As part of this work, we have developed workstation configurations, automation tools, and integrated user interfaces at minimal cost that have significantly improved productivity. We have also proved that these customized data systems are most successful if they are focused on the people and the tasks they perform and if they are based upon user confidence in the development team resulting from daily interactions. This paper will describe lessons learned in adapting JPL's MGDS to fly the Voyager, Galileo, and Mars Observer missions. We will explain how powerful, existing ground data systems can be adapted and packaged in a cost effective way for operations of small and large planetary missions. We will also describe how the MGDS was adapted to support operations within the Galileo Spacecraft Testbed. The Galileo testbed provided a unique opportunity to adapt MGDS to support command and control operations for a small autonomous operations team of a handful of engineers flying the Galileo Spacecraft flight system model.
The first phase of the Multi-kw dc Power Distribution Technology Program is reported and involves the test and evaluation of a technology breadboard in a specifically designed test facility according to design concepts developed in a previous study on space vehicle electrical power processing, distribution, and control. The static and dynamic performance, fault isolation, reliability, electromagnetic interference characterisitics, and operability factors of high distribution systems were studied in order to gain a technology base for the use of high voltage dc systems in future aerospace vehicles. Detailed technical descriptions are presented and include data for the following: (1) dynamic interactions due to operation of solid state and electromechanical switchgear; (2) multiplexed and computer controlled supervision and checkout methods; (3) pulse width modulator design; and (4) cable design factors.
A report discusses a cryogenic reaction control system (RCS) that integrates a Joule-Thompson (JT) device (expansion valve) and thermodynamic vent system (TVS) with a cryogenic distribution system to allow fine control of the propellant quality (subcooled liquid) during operation of the device. It enables zero-venting when coupled with an RCS engine. The proper attachment locations and sizing of the orifice are required with the propellant distribution line to facilitate line conditioning. During operations, system instrumentation was strategically installed along the distribution/TVS line assembly, and temperature control bands were identified. A sub-scale run tank, full-scale distribution line, open-loop TVS, and a combination of procured and custom-fabricated cryogenic components were used in the cryogenic RCS build-up. Simulated on-orbit activation and thruster firing profiles were performed to quantify system heat gain and evaluate the TVS s capability to maintain the required propellant conditions at the inlet to the engine valves. Test data determined that a small control valve, such as a piezoelectric, is optimal to provide continuously the required thermal control. The data obtained from testing has also assisted with the development of fluid and thermal models of an RCS to refine integrated cryogenic propulsion system designs. This system allows a liquid oxygenbased main propulsion and reaction control system for a spacecraft, which improves performance, safety, and cost over conventional hypergolic systems due to higher performance, use of nontoxic propellants, potential for integration with life support and power subsystems, and compatibility with in-situ produced propellants.
Distributed space systems are a mission architecture consisting of multiple spacecraft as a cohesive system which provide multipoint sampling, increased mission coverage, or improved sample resolution, while reducing mission risk through redundancy. To fully realize the potential of these systems, eventually scaling to hundreds or thousands of spacecraft, distributed space systems need to be operated as a single entity, which will enable a variety of novel scientific space missions. The Distributed Spacecraft Autonomy (DSA) project is a software project which aims to mature the technology needed for those systems, namely autonomous decision-making and swarm networking. The DSA project leverages a containerized swarm test framework to simulate spacecraft software, which can identify emergent behavior early in development. Container virtualization allows distributed spacecraft systems to be simulated entirely in software on a single computer, avoiding the overhead associated with conventional approaches like hardware facsimiles and virtual machines. For this approach to be effective, the simulated system behavior must not be artificially influenced by the swarm test framework itself. To address this, we present a series of benchmarks to quantify virtual network bandwidth available on a single-host computer and contextualize this against the network and application behavior of the DSA swarm test framework.
The operation and capabilities of a new integrated instrumentation and control system are described. The system will, under one main program, both acquire data from a conducted test and automatically control the test sequence. The system layout has a multiplexer front end and control-function electronics at the test area, while the system control computer, recording devices, and monitors are located remotely. The system's data, control, and communication signals are transmitted via fiber-optic lines. Diagrams are presented illustrating the control and data displays.
A bio-nanobattery is an electrical energy storage device that utilizes organic materials and processes on an atomic, or nanometer-scale. The bio-nanobattery under development at NASA s Langley Research Center provides new capabilities for electrical power generation, storage, and distribution as compared to conventional power storage systems. Most currently available electronic systems and devices rely on a single, centralized power source to supply electrical power to a specified location in the circuit. As electronic devices and associated components continue to shrink in size towards the nanometer-scale, a single centralized power source becomes impractical. Small systems, such as these, will require distributed power elements to reduce Joule heating, to minimize wiring quantities, and to allow autonomous operation of the various functions performed by the circuit. Our research involves the development and characterization of a bio-nanobattery using ferritins reconstituted with both an iron core (Fe-ferritin) and a cobalt core (Co-ferritin). Synthesis and characterization of the Co-ferritin and Fe-ferritin electrodes were performed, including reducing capability and the half-cell electrical potentials. Electrical output of nearly 0.5 V for the battery cell was measured. Ferritin utilizing other metallic cores were also considered to increase the overall electrical output. Two dimensional ferritin arrays were produced on various substrates to demonstrate the feasibility of a thin-film nano-scaled power storage system for distributed power storage applications. The bio-nanobattery will be ideal for nanometerscaled electronic applications, due to the small size, high energy density, and flexible thin-film structure. A five-cell demonstration article was produced for concept verification and bio-nanobattery characterization. Challenges to be addressed include the development of a multi-layered thin-film, increasing the energy density, dry-cell bionanobattery development, and selection of ferritin core materials to allow the broadest range of applications. The potential applications for the distributed power system include autonomously-operating intelligent chips, flexible thin-film electronic circuits, nanoelectromechanical systems (NEMS), ultra-high density data storage devices, nanoelectromagnetics, quantum electronic devices, biochips, nanorobots for medical applications and mechanical nano-fabrication, etc.
Sustained human presence on the surface of the Moon and future missions to Mars require increased independence from surface crews and Earth-based mission control to operate efficiently, safely, and reliably. The time for surface crews to perform tasks will be limited. Extravehicular activities by surface personnel are burdensome and time-consuming, even when a continuous human presence on the surface occurs. Identifying and balancing human/automation roles and tasks and infusing automation and autonomy practices early in a system’s lifecycle will be essential to achieve mission objectives. Among these objectives are attaining a sustained human presence, improving performance and mission effectiveness, reducing operations and maintenance (O&M) costs, and ensuring operations that are robust to communication delays. To achieve these objectives, an operational shift toward increased automation and autonomy with less reliance on humans is needed. Uncrewed lunar surface operations and support activities occur when surface crews are not present or are independent of surface crew timeline activities requiring no surface crew oversight or intervention. These uncrewed surface opportunities can also be planned to minimize crew workload that avoids routine maintenance and support tasks, thus maximizing crew exploration time. Uncrewed preparations such as staging and prepositioning equipment and materials before the crew arrives could improve crew task efficiency. Additional opportunities exist to conduct uncrewed science, exploration, and utilization. Uncrewed surface architecture functions can include science and exploration; habitation; launch and landing support; surface communication and navigation; surface power generation and distribution; human surface mobility; lifting, handling, manipulating; excavation, construction, and site preparation; logistics management; maintenance and repair; surface resource utilization; integrated site operations and shared support services (e.g., site scheduling/prioritization, dust mitigation/contamination control, and surface safety). Early robotic lunar surface campaigns will provide information on the availability of resources, such as oxygen and water, and demonstrate surface-based technologies. After the Artemis III human lunar return mission, a series of landers will deliver surface systems, cargo, supplies, science packages, spare parts, and commodities. A balance of crewed and uncrewed surface operations will enable a sustained lunar surface presence at the South Pole of the Moon at a site that will be known as the Artemis Base Camp (ABC). It is envisioned that base camp operations on and around the Moon will then help prepare for the mission durations and activities needed to support the first human mission to Mars. Before long-duration crew missions to the base camp can occur, the necessary surface infrastructure will be pre-deployed and verified operational. Surface assets will be teleoperated and remotely managed from Earth. Additionally, robotic and short-duration crewed missions to the ABC will ensure the site’s merit to achieve long-term science objectives, availability of usable resources, and that terrain, seasonal variations, and illumination conditions are acceptable. ABC will consist of different areas where specific functions and services are rendered, including: • Launch and Landing Area • Habitation Area • Power Production Area • Resource Areas Launch and Landing Area—The launch and landing area will support associated functions for the arrival and departure of vehicles, such as crewed landing and ascent and uncrewed cargo deliveries and offloading. It will evolve from an unimproved site at the beginning of the exploration campaign to a more sustainable landing and launch area that can support repeated arrivals and departures. Initial uncrewed Lunar Terrain Vehicle (LTV) surface operations may include emplacement of navigation beacons and communication equipment, real-time video and photography of landing/liftoff events, and element repositioning, such as portable utility power (PUP) (applicable for other landed assets at other areas). Site preparations, such as surface leveling, soil compaction, and berm/path construction, may be needed for a more sustainable launch and landing area capable of accommodating vehicles that are increasingly more reusable and reduce the effects of plume surface interactions and ejecta impacts on nearby surface assets. During the ABC missions, cargo and logistics will be delivered to the lunar surface via robotic cargo landers before the crew arrives. These shipments, which can arrive in pressurized logistics carriers, will deliver the logistics necessary to support a crewed mission and include items such as food, water, equipment spares, etc. Providing the capability to retrieve, offload, and transport the logistics closer to the ABC site before the arrival of the crew will increase the overall efficiency of crew operations once they arrive. In the sustained phase of exploration, other supporting services may be needed, such as lander propellant servicing, surface power services, commodity refreshes, and additional inspection, maintenance, and repair capabilities, to sustain a cadence of extended personnel stays and cargo arrivals and departures. Habitation Area—Uncrewed support to surface habitation could involve supporting activation and pre-entry operations of the habitat while the crew is in orbit at the Gateway outpost preparing for a surface landing. Surface Habitat (SH) uncrewed operations may include bringing the cabin environment to a habitable temperature and air mix and activating other critical crew support systems. Potential crop production uncrewed tasks in the SH could also include autonomous watering and tending. Additionally, when the crew departs, the SH enters dormancy for the long period of uncrewed operation. A logistical staging area could also be collocated near the SH. If so, staging operations for crew supplies, waste re-location, and recycling operations may be opportunities for uncrewed operations. Power Production Area—The Fission Surface Power (FSP) element and its supporting distribution equipment provide power to surface elements as needed across the ABC to supplement day-to-day operations and survive lunar nights. Uncrewed support of this power system includes any initial LTV-assisted deployments of cables and other distributed equipment, associated electrical connections, and system testing and activation operations. Robotically performing some inspections, maintenance, or repair tasks on the power distribution equipment could reduce the surface crew workload. Resource Area— Uncrewed resource prospecting, mapping, and characterizing possible resource sites is likely to be time-consuming and represents an opportunity for uncrewed operations between crewed missions. Uncrewed mobile equipment operations will be needed in the extreme environments of permanently shadowed locations where resource extractions occur. As In-Situ Resource Utilization (ISRU) pilot plant operations begin, uncrewed surface support activities with available mobile and portable assets (LTV, PUP, etc.) will better support these operations. Any produced commodities can be stored at a centralized storage location for future use. Also associated with these operations is the use of mobile robotic excavators for resource acquisition and robotic/autonomous regolith processing. The waste tailings generated during excavation and regolith processing would also need to be transported and deposited at a dedicated location. Surface assets will continue operating between crew visits to maintain surface capabilities, conduct lunar surface science, technology demonstrations, and public outreach opportunities. Additionally, certain sustaining tasks that would consume valuable crew time could be performed before crew arrival, or after their departure. This capability may offer more affordable options to construct, activate, test, and maintain a broad set of surface assets. Telerobotically operated human surface mobility systems, such as the LTV and Pressurized Rover (PR), can be utilized for various tasks. Surface environmental conditions pose a distinct challenge for all these activities. Surface illumination and localized shadows are one such factor. Night-survival operations could consist of thermal management, battery pre-charging, and load shedding. Some surface systems may hibernate through the night and then awake and continue nominal operations. Uncrewed mobile assets may use a more adaptive approach to optimize their power and operations; one method is to follow the sunlight. Night-survival operations may be initiated remotely by teleoperation, automated, or accomplished by supervised autonomous operation. The ability to pre-deploy and control remote assets in orbit or on Mars before the arrival of the mission crew is a key capability that can be simulated on the moon. The base camp provides a venue where these advanced operational concepts, technologies, and autonomous methods and techniques, including the incorporation of time delays to simulate Earth-Mars latency can be replicated to help buy down future Mars mission risks. This paper will examine the evolution of uncrewed lunar surface operations and support activities. It will also discuss the lunar surface environmental conditions (thermal, lighting, terrain, topography, communications) along with the challenges they pose on uncrewed surface operations, and the performance of these activities with limited to minimal human interaction and/or teleoperation. Since lunar missions include Mars mission analogs, such investigation provides the framework for future uncrewed Mars mission support.
For NASA's Resource Prospector (RP) Lunar Rover Mission, we are moving away from a control center concept, to a fully distributed operation utilizing control nodes, with decision support from anywhere via mobile devices. This operations concept will utilize distributed information systems, notifications, mobile data access, and optimized mobile data display for off-console decision support. We see this concept of operations as a step in the evolution of mission operations from a central control center concept to a mission operations anywhere concept. The RP example is part of a trend, in which mission expertise for design, development and operations is distributed across countries and across the globe. Future spacecraft operations will be most cost efficient and flexible by following this distributed expertise, enabling operations from anywhere. For the RP mission we arrived at the decision to utilize a fully distributed operations team, where everyone operates from their home institution, based on evaluating the following factors: the requirement for physical proximity for near-real time command and control decisions; the cost of distributed control nodes vs. a centralized control center; the impact on training and mission preparation of flying the team to a central location. Physical proximity for operational decisions is seldom required, though certain categories of decisions, such as launch abort, or close coordination for mission or safety-critical near-real-time command and control decisions may benefit from co-location. The cost of facilities and operational infrastructure has not been found to be a driving factor for location in our studies. Mission training and preparation benefit from having all operators train and operate from home institutions.