Plug and Play Mission Operations

Plug and Play Mission Operations Trevor Sorensen Hawaii Space Flight Laboratory University of Hawaii at Manoa 2820 East-West Rd., POST 501 Honolulu, HI 96822 808-956-4715 [email protected]

Bruce Yost NASA Ames Research Center Mail Stop 202-3 Moffett Field, CA 94035 650-604-0681 [email protected]

Eric Pilger Hawaii Space Flight Laboratory University of Hawaii at Manoa 2820 East-West Rd., POST 501 Honolulu, HI 96822 808-956-6321 [email protected]

Miguel Nunes Hawaii Space Flight Laboratory University of Hawaii at Manoa 1680 East West Rd. POST 501 Honolulu, HI 96822 808-956-0441 [email protected]

Joan Differding NASA Ames Research Center Mail Stop 269-3 Moffett Field, CA 94035 650-604-2005 [email protected]

5. APPLICATIONS TRACK ..................................... 6 6. FUTURE OF SMALL SAT OPS - COSMOS ........ 7 7. SUMMARY ....................................................... 10 REFERENCES ....................................................... 11 GLOSSARY OF ACRONYMS ................................. 11 BIOGRAPHY ........................................................ 12

Abstract—Ongoing and planned smallsat programs within NASA, the DoD, and academia have indicated a need to be able to routinely and efficiently operate multiple small spacecraft in support of science and technology missions. However, as the number of these missions is expected to grow rapidly, the associated costs to develop and operate unique ground control stations, tools, and networks may become prohibitive to the sponsoring organizations or universities. In order to inform and raise the awareness of the smallsat space operations community, the University of Hawai’i, NASA Ames Research Center, San Jose State University (SJSU) and American Institure of Aeronautics and Astronautics (AIAA) held a workshop entitled Plug ‘n’ Play Mission Operations (PPMO) which held May 16-17, 2011 at the SJSU campus in San Jose, California. The purpose of the workshop was to foster collaboration and leveraging of existing and developing capabilities that may be collectively utilized by the smallsat community for space operations. Although the emphasis of the workshop was on small satellites, many of the techniques discussed would be applicable to large spacecraft mission operations as well. The workshop explored the adoption of standards and existing capabilities as well as the creation of new technologies that will enable space mission developers to plan, design, and operate their spacecraft using a common architecture in order to reduce cost and overall mission risk. The PPMO workshop investigated the various needs of the smallsat communities (military, civil and educational space) and also touched on existing systems and capabilities (such as GSFC’s GMSEC, JPL’s AMMOS, and NRL’s CGA used in the MC3 program) and those under development (such as HSFL’s COSMOS and ESA’s GENSO). The workshop also held facilitated discussions organized into categories along the lines of Approaches (programmatic and related issues), Implementation (technical solutions and architectures), and Applications (concept of operations, mission types and users). This paper presents the results of this workshop and the path forward.

1. INTRODUCTION Miniaturization of electronics and increases in computing power have resulted in a huge increase in the number and importance of small satellites in recent years. CubeSats, nanosats, and even picosats are being built by dozens of companies, agencies, and universities world-wide. Although building and even deploying small satellites has become affordable, operating them, especially in large numbers, is still a challenge. The existence of almost as many solutions as developers of small satellites has resulted in unnecessary “reinventing of the wheel.” This has prompted several organizations to consider ways to easily re-use effective software applications for new satellite missions in a way that can done with minimum cost and effort, especially for university-class satellites. One solution is being developed by the Hawaii Space Flight Laboratory (HSFL) at the University of Hawaii at Manoa. HSFL won a 3-year NASA EPSCoR grant in 2010 entitled “Development of an Open-architecture Mission Operations System to Support Multiple Small Spacecraft Missions” with NASA Ames Research Center (ARC) as the collaborative agency. The end-product of this grant is the Comprehensive Open-architecture Space Mission Operations System (COSMOS). COSMOS is designed to be easily adapted to new satellites and mission operation centers, such as at HSFL and ARC. COSMOS is also being designed to accept external software applications as “Plugand-Play” modules. A similar solution is also being worked at other organizations through the country.

TABLE OF CONTENTS 1. INTRODUCTION .................................................1 2. IMPORTANCE OF PPMO ..................................2 3. APPROACHES TRACK........................................3 4. IMPLEMENTATION TRACK ...............................4 978-1-4577-0557-1/12/$26.00 ©2012 IEEE

1

HSFL and ARC decided to hold a workshop to help identify and unify the community interested in this topic so that their efforts can be mutually supportive. The San Francisco Section of the American Institute of Aeronautics and Astronautics (AIAA) and San Jose State University (SJSU) later joined in hosting the “Plug-and-Play” Mission Operations (PPMO) workshop, which was held on the campus of SJSU in San Jose, California on May 16-17, 2011. [1]

(1) Approaches – especially suited for managers and planners and covered the following topics: 

Standardization: Pros and Cons



Ground Data System Approaches



Architectures and Standard SW Packages



Leveraging Infrastructure: Ground Stations, Networks, Ops Facilities

(1) To identify the organizations that are interested in responsive and effective operations of spacecraft, especially multiple small spacecraft, using ground systems that are designed especially for porting to new mission operations centers (MOCs) and for modifying for new spacecraft.



Automation: Costs and Benefits



Current & Future Solutions

(2) Determine the current state of the art in such mission operations systems (which are most likely to be Plugand-Play architectures), with identification of such existing systems.



Environments



Protocols/Interfaces



Support Functions



Tools



Standards

The purposes and goals of the workshop were:

(2) Implementation – especially suited for software and hardware engineers and covered the following topics:

(3) Look at systems that are currently in development which may meet this need. (4) Identify issues (interfaces, protocols, proprietary and security issues, etc.) that will be faced by such systems and possible first order solutions to be investigated.

(3) Applications – especially suited for users and operators and covered the following topics:

(5) Identify and characterize possible future applications for such systems.



User requirements

(6) Networking between the players in this field and the possible establishment of collaborations that will benefit the participants and the industry as a whole



Fleet control



Simulation and modeling

(7) Improve the usefulness and applicability of COSMOS.



Enhanced ground segment

(8) Produce an AIAA white or conference paper on the results of the workshop.



Enhanced communications

This paper presents a summary of the results of the PPMO Workshop and briefly looks at the path forward in an attempt to build on the benefits obtained from the workshop.

There were approximately 50 participants from various NASA centers, DoD, industry, and universities. On the first day there was a common session where the purposes of the workshop were presented along with the perspectives of the major stakeholders in successfully being able to operate multiple small satellites: NASA, National Reconnaissance Office (NRO), Department of Defense/Space Test Program (DoD/STP), and universities. This was followed by future objectives (near-term efforts underway) including an overview of the COSMOS Project, as well as other university efforts and the problem of frequency allocation when multitudes of small satellites are being proposed.

2. IMPORTANCE OF PPMO We are currently witnessing a universal trend rolling through space segment architectures that can be easily visualized by the steady reduction of satellite size and mass coupled with a constant increase in space systems capabilities. This unique dynamic is due to a confluence of technological factors similar to and including Moore’s Law (“The number of transistors per square inch on integrated circuits doubles every 18 months since the integrated circuit was invented”). Smaller spacecraft can process more data, perform more observations, and downlink more information due to continual, almost exponential advancements in computational power, solar cell efficiencies and energy storage technologies, advanced software applications, and

Following this common session involving all the workshop participants, the workshop was split into three concurrent tracks that addressed different perspectives of the PPMO problem: 2

the ability to inexpensively launch small spacecraft as secondary (or even tertiary) spacecraft on otherwise large, expensive launch vehicles.

described a TDRS-MA transponder developed by Vulcan for use in CubeSats.

In addition to the proliferation of these smaller, cheaper spacecraft, innovative space architectures are now also being seriously considered and even tested in space. These new architectures include cooperative, multi-spacecraft swarms or constellations that are theoretically capable of executing missions or collecting measurements and observations that are well outside of the traditional, single large spacecraft architecture and performance realms. However, these exciting developments within the space segment are not without challenges. While the ability to reduce the size, weight and power of a spacecraft does indeed have direct cost implications, which are primarily manifested in the reduced cost of access to space, the space operations community must be prepared to support and operate these constellations or swarms of large numbers of small spacecraft in an equivalent low cost fashion. Simply scaling the traditional methods currently in use by many government or even commercial agencies would be prohibitively costly and would severely dilute the benefit of the low cost, small spacecraft platform. Therefore, similar revolutions invoking standard interfaces, high levels of automation, and other related technologies must be brought to bear on the ground segment part of the equation to fully realize the next generation of low cost, robotic spacecraft. A fertile concept developed to stimulate this transformation is a philosophy loosely named Plug-and-Play Mission Operations where custom software and extensive testing can be significantly reduced or even eliminated, thus shortening development schedules, reducing overall mission risk and minimizing costs associated with the deployment and utilization of potentially many, many small spacecraft performing many diverse functions.

Connor Lange and Justin Foley from Cal Poly San Luis Obispo presented their work on automating the operation of Cal Poly’s three satellites using LabVIEW and increasing data return using ESA’s GENSO.



Chris Webster from Ames Research Center presented the Mission Control Technologies service-oriented platform for developing end-user applications and displays for use in ground data systems.



Darren Garber and Kenny Haag from Millennium Space Systems discussed a common sense approach to mission design.

Choosing an Approach Functional architecture is key. An important point to remember in designing a mission is to start with the functional architecture. The physical architecture must always support the functional architecture. An example of a physical architecture not supporting the functional architecture is a spacecraft that can collect a lot of data on board, but can only downlink a small subset of that data over the available communications links. Keeping the functional architecture at the forefront can prevent this sort of disconnect. The real trades are between all the resources on the table and the over-all risk, instead of performance, cost, and schedule. Communications and operations should be included up front when designing a mission. Communications and operations experts need to be included in development of the concept of operations and in the design of the spacecraft. Operations engineers/planners should be engaged early in the concept development and preparing of proposals. Operations engineers are needed to keep the spacecraft and system engineers on track. It is critical to spend the time on concept of operations and design reference missions. The desire to save initial cost of the spacecraft can cause expensive operations work-arounds down the line. For example, leaving a sensor off of the spacecraft to save money can result in later high operations costs to calculate the measurements or to operate without the information.

3. APPROACHES TRACK This track was led by Joan Differding of the NASA Ames Research Center and was targeted at project leaders and mission managers who are looking for the over-all designs and methods that will lead to successful missions. Suggested discussion points going in to the workshop included the pros and cons of standardization, best practices in data system architectures, how to leverage existing infrastructure, and the costs and benefits of automation. The focus for the discussion was less on the specific features of various approaches and more on the trade space: What decisions lead to choosing a particular approach, what costs and benefits resulted from that choice, and what were the lessons learned. The track attendees heard four presentations, each of which touched on subsets of these topics. 



Communications is a bottleneck. Communications in space is not the same as in the laboratory because of such factors as the electro-magnetic environment, relative velocity, and distance. It is important to understand all the data handling tasks that need to take place and how those are commanded and communicated. The end-to-end data path needs to be carefully calculated. Think outside the box - remember that you are designing for space and consider space-specific needs. Cost constraints often push the use of commercial off-the-shelf (COTS) components. However, applying earth-based solutions to space only goes so far. Remember to address the space-

Kevin Lynaugh from Vulcan Technologies talked about communications architectures: the challenges inherent in meeting diverse communications requirements and solutions that have been developed by Vulcan. He 3

unique problems with communications, since these will often need specific solutions, rather than COTS re-use. Challenge the assumptions of what is possible in space. For example, low Earth orbit (LEO) to ground might not be the only communication path. LEO to geostationary orbit (GEO), e.g., TDRS, paths are also possible, if affordable.

benefit of adopting the standard must be apparent to the adoptees. Simply being good will not be enough.

4. IMPLEMENTATION TRACK This track was led by Eric Pilger of HSFL and dealt with actual solutions to the problems seen in developing a Plugand-Play architecture. Hardware and software solutions, both implemented and in development, and any issues that which would need resolution, were discussed.

Costs and Benefits Automation—Automation can save costs, but there are often strong drivers against it. There are a lot of automation solutions already in place, but there is still major inertia in the area of requiring humans in the loop. There is an expectation that people have to personally provide care and feeding for the spacecraft. Big teams may be needed for complex operations (commissioning, anomalies, etc.) but automation can be used effectively in many simple scenarios. Justin Foley was able to double downlink capability of the Cal Poly satellites by automating the repetitive process that was required for communicating with the satellites.

Topics of Interest After some discussion among the attendees, it was decided that the following topics merited discussion. Work Environments—The cornerstone of Open Implementations is the vast array of solutions already available for a variety of operating and development environments. However, the small sat environment presents a unique challenge in terms of available hardware, environmental constraints and system requirements. What are these constraints, and how do they impact our choice of environments? What environments are already available, and which would we like to see made available? This topic covered both development and operations.

Re-use—Common barriers to re-use include old-style monolithic solutions where the whole system must be used to derive of the benefit of any one part and financial incentives for developers to create new applications in their entirety. As a result, displays are being re-designed and reimplemented over and over, and databases designed fresh every time. Or in contrast, projects are being forced to use legacy systems that no longer meet their requirements because the cost of building a new system is too high. Solutions can be found in platforms on which people can easily develop what they need. Facebook is a good example of such a platform. Chris Webster described Mission Control Technologies, which is a platform for developing re-useable displays in mission operations environments.

Standards—An important element of Open Implementations is adherence to easily implemented, widely available standards. To what sort of standards should we be adhering? What standards do we need to support? What standards do we need to invent? Tools—Well developed software tools greatly speed the implementation of any solution. What software tools are available, or being developed, that meet the unique needs of Plug and Play Operations? To what extent do we adapt tools that already exist? What do we need to develop from scratch?

Collective Benefits—Be cautious with solutions that require buy-in to achieve benefit, such as group and collective systems (e.g. GENSO) and standards (e.g., CCSDS). For these approaches to be beneficial, they require that barriers to adoption are minimized. For example, GENSO provides its greatest benefit to members if it has many member ground stations. However, GENSO has had low profile because it is ESA and not open source. It is targeted at a limited set of hardware. As result, the GENSO community is still small. If it were open source, if it applied networkbased redundancy and if it employed a wider range of hardware drivers, it could attract more members. If GENSO were in widespread use so that more antennas are involved, then wider coverage would be available. CCSDS is an international standards body that seeks widespread adoption of their standards in a wide range of areas. However, some of the “standards” provide too much flexibility in how they are applied, so the resulting usage is not really standard and doesn’t support interoperability. In other cases the standard is more like guidelines or best practices, so the end product still has to be created new for each use. In these cases, application of the standard does not end up saving time or money, and these costs become barriers to adoption. The

Support—Open Implementations are built on a foundation of support elements, both in hardware and software. What building blocks do we already have for constructing the complex systems we need to develop and operate Plug and Play missions? What do we need to create? Communications—This topic, clearly one of the most important of any mission, is also the one most beset with problems for the small sat community. Current solutions all suffer from some or all of; too little data, at too high a cost, with too much red tape. The solutions that are currently used are not going to scale to the 100’s (or 1000’s) of small sat launches. Whatever will we do? Speakers Eight attendees presented one or more solutions to some of the issues above that they either already have, or are working on. A short summary of each is presented below, in alphabetical order. 4

(1) William Clancy – NASA Ames Research Center – The OCA Management System: OCAMS is a system for automating the routine data transfers that happen between the ISS and Ground. It has developed a standard language and set of procedures for commanding transfers to occur. It is implemented with a set of software Agents and GUI’s, using XML and XHTML, over standard network protocols.

(7) Chris Webster - NASA Ames Research Center – Mission Control Technologies (MCT): MCT is a Java based tool kit for putting together display interfaces based on a large database of multiple telemetry streams. Streams can be easily viewed in different ways by being directed to different “views” (textual, graphical, property). Different views can then be easily arranged in to interfaces. Additionally, the development kit allows the invention of new views, thereby allowing users to extend the capabilities of MCT.

(2) Bob Feretich – RAF Research, San Jose – Inertial Navigation System: Bob has been working with students at SJSU to develop an INS that will fit in a high powered rocket. His design leverages simple OTS components to provide the necessary Inertial Measurement Unit. His presentation emphasized the use of the Xenomai Real-Time co-kernel to provide true real time performance in concert with a regular Linux kernel (Angstrom).

(8) Mark Wood - Hawai‘i Space Flight Laboratory – COSMOS Mission Operations Support Tool (MOST): MOST, the first Tool developed by the COSMOS project, has as its primary function the display of telemetry data from a satellite or its simulator. It owes its heritage to the LUNOPS program used for the Clementine mission. [3] Developed with the QT graphical development environment, it is designed to be easily configurable to different satellites through a combination of a JSON based satellite description and an XML interface description.

(3) Kevin Lynaugh – Vulcan Wireless – Software Defined Radios (SDRs): This is an area in which dramatic development is occurring. Kevin spoke of Vulcan’s contributions to this effort and displayed the transceiver that is around the size of a deck of cards. These devices are tunable through a wide range of frequencies completely through software control. They also implement any required encoding or decoding and can be designed to appear as simply a network adapter to the Onboard Computer.

Track Conclusions Each of the areas of interest were addressed during the track, and the conclusions in each area are summarized below.

(4) Miguel Nunes – Hawai‘i Space Flight Laboratory – COSMOS Operations Test Bed: One element of the HSFL COSMOS EPSCoR project is the design of an open-sourced hardware and software test bed to support all aspects of satellite design and operations. Miguel presented his design ideas for this project and the progress to date. Two aspects of this project would affect the community as a whole. First, the COSMOS team plans to create a suite of open-source software and hardware that would then be affordable by even high school groups wishing to put together their own satellite facilities. Secondly, they hope to create a simulation environment that could be used remotely with interaction by the satellite development community to test algorithms and designs.

Work Environments—The state-of-the-art is fairly satisfactory. You can choose from a variety of operating systems on almost any processor you want, and you can even get a mix of Real Time and normal Linux using something like Xenomai. Languages are not as fully supported yet because some of the important things you need, like the JPL ephemeris, are not available in Java. However, the community is getting closer, and you can always do the work yourself if it is absolutely necessary. Standards—A large body of existing standards work just fine. However, some of the evolving standards for space are still problematic. Unlike TCP/IP, no generally available software support exists for CCSDS. Similarly, no readily available inexpensive hardware exits for Spacewire.

(5) Eric Pilger – Hawai‘i Space Flight Laboratory – COSMOS Software Project: The COSMOS EPSCoR project has as its primary goal the creation of an Open Software and Hardware environment for the design, development and operation of small satellites. On the software side the initial three year project plans to establish a framework of Support Libraries and Protocols, a suite of basic Programs and Agents, and a few GUI based Tools. In hardware, the goal will be to create a basic test platform with simulated versions of all the actual hardware that would go on a satellite.

Tools—A growing array of software tools are becoming available. Support—A growing body of support packages are becoming available as well. Communications—Despite the good news provided by SDR’s like Vulcans’, this is still our most troublesome area. The current licensing procedure is problematic at best, and will never work for future “swarms” of satellites. Likewise, it is not clear how operators will deal with the logistics of “swarms” passing overhead. Additionally, even as the size of satellites continues to shrink, the amount of data they can produce is growing. The current crop of 3U CubeSats are growing beyond UHF, and probably even S-Band. The

(6) John Ploschnitznig – Riverside Research – Automated Collection Planning Tool (ACPT): Available free of charge to governmental agencies, ACPT is an integrated tool for automatically combining many aspects of AGI’s Satellite Tool Kit (STK). An extensive list of requests can be entered and then the optimal collection strategy calculated. 5

operations and communication engineers are going to have to start thinking completely out of the box on this one.

The SMC is also developing 2-3U CubeSats with the primary objective to understand the operation of NanoSats and as a secondary objective as a space-weather mission.

In this vein of thinking out of the box a suggestion was made by John Ploschitznig that the possibility of using the existing cell networks be investigated. Additional antennas could be placed on each cell tower, only directed upward. It was not clear to the assembled group if this was in any way workable, but it demonstrates the extent to which we will have to change our thinking in order to solve the looming communications problem.

Low Cost, Mobile, Instant Ground Station Systems (MC3) —Dr. Jim Newman from the Naval Post Graduate School and Naval Research Laboratory (NRL) introduced the Mobile CubeSat Command and Control (MC3). It is a low cost, mobile, instant ground station system that can be easily networked over the Interned to increase the operations array. The MC3 will also support academic applications. The MC3 interfaces with top-level architectures for satellite operations using dual antennas in a portable unit that can be installed anywhere as needed. It includes appropriate levels of security and can be controlled remotely or locally, where locally the operator will have priority. It is connected via a Virtual Private Server (VPS) to a central node in Blossom Point.

5. APPLICATIONS TRACK The Applications track was led by Sam Myers Sims from The Aerospace Corporation. Sims is part of the Space Test Program (STP) and Mission Design Support (MDS) for access to space programs. The focus of this track was the identification of user requirements and thoughts regarding operations planning in terms of the following areas: 

Fleet control



Simulations and modeling



Enhanced ground segment



Enhanced communications

NRL has developed the Common Ground Architecture (CGA) to support all aspects of the satellite development lifecycle from box level testing through operations and also the MC3. CGA is based on databases and scripts and allows for automated ground operations. This automates the ground station support by loading mission plans and where only engineers have to work, lowering the operations cost. The MC3 also includes the drivers for different radios and motors and different configurations envisioned (e.g. MC3 colony II bus).

Concepts While the technological landscape of small, multiple spacecraft operated in a coordinated manner is still in development, a number of near- and long-term applications have been described and discussed to serve as guideposts for the development of PPMO architectures and concepts. A selection of those discussed during the PPMO Workshop summarized in the following paragraphs.

“The Soldier is the Ground Terminal” – Satellite Control is Distributed to the End User—Mr. Nick Chando from the Army Space and Missile Defense Command (SMDC) presented the interest in the-field support of the disarmed soldier. The goal is to give as much capability to the soldier (the end user) in the ground when they are left with a low power radio and by using small spacecraft. A Vulcan SDR is being developed for a 3U and 6U CubeSat and a future project is in development for a constellation of 16 CubeSats in a near equatorial orbit to be used as relays and with the objective of increasing autonomy with little ground work.

Cheaper Space Operations with Nanosatellites while Keeping Operational Requirements—Capt. Peter Mastro from the Air Force Space and Missile Systems Center (SMC)/XR. The SMC is interested in solutions for mission operations that satisfy cost optimization and the following requirements for Operational Mission Operations: 

Compatible with information assurance and encryption requirements,



Communication frequencies that support higher data rates (like UHF, VHF), and compatible with existing operation architectures,



Lower man-hours required for operations, expecting large number of spacecraft in a specific constellation,



Accept short spacecraft acquisition times as a successful contact with the spacecraft, for low altitude constellation missions.

A Small, Low Cost, Technology (Non-Operationally Focused) Ground Segment—Rick Murphy from the DoD Space Test Program (STP) talked about how STP is taking proactive measures to standardize spacecraft design and construction and is also looking for the future standards being adopted like the Evolved Expendable Launch Vehicle (EELV) Secondary Payload Adapter, also known as ESPA. Understanding that CubeSats will not go away soon and that different payloads are being developed for use in CubeSats, the Army is dedicating more and more resources into the development of such satellites. The STP is looking for lower cost operations and development that are still compatible with different small spacecraft and technology development missions by being flexible and extensible.

6

Amateur Band Frequencies—Mr. Jared Clements from the AFRL University Nanosats Program presented the Nanosats Program and showed how it is working with 25 universities and leveraging CubeSat development and technologies. Eleven different proposals are selected each year for development and are put on the Space Experiments Review Board (SERB) to fly. The proposals and the students get $110k for 2 years. The program also has the ability to network and cooperate with other universities, including international universities. The main requirement to be selected is that the missions are to be military relevant.

deformable aperture for remote observations, distributed apertures, fractional satellites, small telescopes and more importantly the ability to operate a large swarm of CubeSats simultaneously. All these initiatives are being seriously considered. In all cases distributed and networked ground systems are of major importance for mission operations support. Final Comments about the Applications Track Another dimension considered during the Applications track is the repurposing of existing ground assets to be compatible with advanced technologies as they come into operation. This could result in a major push if in fact universities and/or others could be provided access to inactive or obsolete government assets.

There is a strong emphasis on promoting the usage of Amateur radio band frequencies because it is easy to obtain compared to other licenses. No license is required for the 900MHz or 2.4GHz when operating below a certain power level. This means low cost but also low bandwidth.

Finally, it was suggested that the various end users identify areas of overlap, and then cooperate on certain systems development activities in order to accelerate the realization of a capable, scalable, set of standards for ground architectures that will support the numerous applications that are currently envisioned, while attempting to anticipate the future applications that are yet unknown.

Meteorology Band – 460-470 MHz—Dr. Chuck Swenson from the Utah State University Space Dynamics Laboratory is proposing the usage of the Meteorology band (460 to 470 MHz) for CubeSats. There are various problems with the frequencies allocation in the more frequently used bands (especially the S-band). Just the frequency allocations can also a problem because the CubeSat orbit can easily change according to the launch.

6. FUTURE OF SMALL SAT OPS - COSMOS The HSFL at the University of Hawaii at Manoa, in collaboration with NASA Ames Research Center, is developing COSMOS, a set of software tools and hardware that is designed to primarily support the development and operations of one or more small spacecraft. [2] COSMOS will be particularly suited for organizations with limited development and operations budget, such as universities. COSMOS is a suite of software and hardware tools that enables the operations team to interface with the spacecraft, ground control network, payload and other customers in order to perform mission operations functions. COSMOS is being designed to easily be adapted for new spacecraft or installation in new mission operations centers (MOCs). Some of the basic elements of COSMOS have been developed at least to the prototype stage, while other elements are still in the conceptual stage. Although all the basic mission operations functions will be developed as part of COSMOS, it is also being designed to accept external modules (applications) as part of its “Plug-and-Play” architecture.

There is available 8.1MHz of spectrum inside the specified band that is very valuable as long as the density spectrum is kept. The meteorology band allows for decent downlink rates and today many dishes are compatible with this band/frequency. The idea of standardizing the Nanosatellites communications into this band was suggested, as a step forward to make this happen as soon as possible, so the design of the spacecraft would be done accordingly. This reduces and eliminates the licensing issues for small groups like universities. Nanosatellites and the Ability to Operate a Swarm of CubeSats Simultaneously—Mr. John Hines is the manager of the Nanosats and Edison Small Spacecraft Demonstration Program at NASA Ames. These programs have defined a 3U CubeSat standard bus, the GeneSat that was used on other missions. Some of the issues encountered in the small satellite operations are thermally related but more critically with the communications bandwidth because there is more and more data that needs to be transmitted. The software-defined radios are being used and will be more common for small satellites. New Nanosat missions are being developed at NASA Ames like the Collapsible Dobson Space Telescope and the PhoneSat that envisions putting an Android phone in space.

The COSMOS system will initially be installed in the HSFL and ARC MOCs and used in support of their small LEO satellites. However, the versatility of COSMOS is demonstrated in that it is being modified to support an international lunar mission in a Phase 0 study. The primary COSMOS mission monitoring and control tool, MOST, is being used for monitoring and controlling the spacecraft, lander, and lunar rover.

The space technology game-changing challenges and the search for the new ways to do space technology can be motivated by initiatives like the Edison small satellite Demonstration Mission Program. Candidate mission capability demonstrations for Nanosatellites can be

COSMOS Architecture and Design The central pieces of this architecture are the visualization 7

tools, support tools, and underlying programs that produce and manipulate the data needed by the rest of the tool sets. It combines both the software and unique hardware needed to support mission operations, including an operations test bed (OTB) and simulators. The simulators are all software applications, and the OTB combines simulators with spacecraft hardware where possible to mimic as closely as possible the reaction of the spacecraft to commands and operational states.

relaxed as International Traffic in Arms Regulations (ITAR) restrictions are redefined or COSMOS is determined to not be an export-controlled product. COSMOS is a suite of software and hardware tools that enables the Mission Operations Team (MOT) to interface with the spacecraft, ground control network, payload and other customers in order to perform the mission operations function. The basic COSMOS functional architecture is shown in Figure 1. Within COSMOS the following major

Figure 1: COSMOS Functional Architecture The basic philosophy behind the construction of this functions are performed/supported: mission scheduling; architecture is that its elements (tools and other programs) contact operations; data management, mission analysis; will be easy to port to a new location and to modify for simulations (including the OTB); ground network operating with new satellites. This is enabled by being an monitoring and control; payload operations, flight dynamics “open architecture.” This approach means not only that the (including orbital and attitude); and support of system source code of its major elements and structure are management and quality assurance. The description given available, but also that it is designed to accept external here is for a full implementation of COSMOS to support modules (which may not have source code available) as flight operations, but some of the features may not be plug-ins through standard, well-defined interfaces in order required by a particular MOC or mission. to increase the overall capability of COSMOS for the desired application. However, it is recognized that there A computer is typically placed at each mission ground could be ITAR issues with COSMOS since it is designed to station to provide the interface between COSMOS and the help control satellites. Therefore, a more limited definition ground station for data management (both to and from the of “open architecture” is used than the common one of ground station), and to monitor and possibly control the having the source code in the public domain. Distribution of operations of the ground station. The various tools of the COSMOS source code can be limited to only those COSMOS provide the graphical interface between the MOT entities (US government agencies, companies, or and the COSMOS functions. The MOT communicates with universities) which are allowable within ITAR restrictions. spacecraft engineers to assist in state-of-health (SOH) However, for those entities, the COSMOS source code will matters, such as anomaly resolution, and reports of the be available. Hopefully, in the future this restriction can be condition of the spacecraft and receives in return any 8

constraints or tasking that may be required. The MOT also communicates with the various payload customers to receive reports on the status of the instruments and mission accomplishment goals, as well as to receive payload tasking requests. COSMOS uses websites or other means to allow the spacecraft engineers and customers to monitor the status of the mission directly without having to go through the MOT.

COSMOS Tools Overview The tools of COSMOS are the software applications with which the human operators interact to control COSMOS and the mission operations processes. Each of the tools is described below. COSMOS EXECUTIVE—There needs to be a way to monitor and control the operation of the entire COSMOS system and possible to launch or terminate various COSMOS tools. The COSMOS EXECUTIVE (CE) fulfills this function. It shows which elements of COSMOS are running, which mission/spacecraft they are controlling, their current status and level of activity. From the CE you can start up any of the COSMOS tools and transfer into that tool if desired as a new computer session, which will put the CE into background mode, possibly within a separate window if desired. The CE also provides another function – it is the way to monitor multiple satellites and ground stations simultaneously from a single tool.

The functional flow block diagram of COSMOS is shown in Figure 2. There are four major processes in mission operations that are supported by COSMOS: (1) Mission Planning and Analysis which also includes command sequencing and the simulators and operations testbed; (2) Contact Operations which includes pre-contact operations, real-time contact operations, and post-contact operations both in the MOC and the ground network; (3) Data Management which includes transfer of all data throughout COSMOS and between COSMOS external locations; data processing, such as engineering units conversion and Level 0 data processing; and data archiving; (4) Mission Analysis which includes support by the MOT to analyze and trend spacecraft and ground network SOH data, orbital and trajectory data, and mission accomplishment data to help determine the mission success Measures of Effectiveness (MOEs). The results of the Mission Analysis process are fed back to the mission planners, spacecraft engineers (especially for resolving spacecraft anomalies), mission management, and customers.

Mission Planning and Scheduling Tool (MPST)—The MPST converts mission status and tasking inputs into executable command loads or sequences, schedules, and timelines. The MPST provides a top-level interface to the mission planner (human) and consists of the following major tools: Scheduler (produces the long- and short-term plans and schedules), Timeliner (produces the timeline), and Command Script Generator (produces the command script or sequence that is uploaded to the spacecraft). An example of the application of the “Plug-and-Play” paradigm in COSMOS is the inclusion of the independent mission

Figure 2: COSMOS Functional Flow Block Diagram

Figure 2. COSMOS Functional Flow Block Diagram 9

planning module developed by Riverside Research called the Automated Collection Planning Tool (ACPT). This tool is built on AGI’s STK engine and is being used for the DoD’s Multispectral Thermal Imaging (MTI), TACSAT-3, and other missions. This optional module provides a powerful addition to the MPST to help plan remote sensing missions while considering constraints, criteria, priorities, and resource utilization.

from users, MOST and the customers. The output goes to the customers and the Data Management System (DMS). Data Management Tool (DMT) —Files are the primary method of data flow between elements of COSMOS. Central storage and dissemination of the files is through a Data Management System (DMS) whose function is to:

Operations Test Bed and Simulators—The COSMOS Operations Test-Bed uses an open-source system architecture that integrates hardware and software components and tools to operate a low cost Satellite System Simulator (e.g. FlatSat) which can be integrated into the MOC setup for command scripting testing, personnel training, mission rehearsals and anomaly resolution. The OTB has tools for satellite technology integration and development that allows for cheaper satellite subsystem integration and testing. The OTB tools are based on COTS that are affordable to universities while some tools are being developed under the COSMOS project using proven standards and made available to the small sat community. The OTB is part of the four major processes in mission operations that are supported by COSMOS, namely the Mission Planning and Scheduling, Real-time contact operations, mission analysis, and anomaly resolution.



Accept files for delivery to other parts of the system



Store files for long term access



Provide access to stored files



Forward files to other parts of the system

The DMS will be able to manage multiple spacecraft, distinguishing between them by spacecraft designator. It stores both informational data, and longitudinal data, such as payload data and telemetry. Longitudinal data are accessible by date of creation. The DMS is split between a Data Management Agent (DMA), and a Data Management Tool (DMT). The DMA stores files in a simple directory structure, receiving them via standard file transfer protocols. These files are available either through the local file system, in the case of the MOC, or through standard file transfer protocols. Control of the DMA is through a GUI-based control program, the DMT. The DMT allows monitoring and control of the DMA, as well as adding additional features for analyzing data storage and flow.

Mission Operations Support Tool (MOST)—This is the primary element of COSMOS and is the visualization tool designed specifically for supporting real-time operations. [4] However, MOST can also be used for supporting the following major operations functions: (1) spacecraft & payload monitor & control; (2) mission planning; (3) simulations & rehearsals; (4) trending & analysis; and (5) anomaly resolution. MOST is based on the LUNOPS program that was developed to support both LEO and lunar operations for the Clementine mission in 1994.[3] Features of LUNOPS were incorporated into the design of some JPL mission operations software.

7. SUMMARY The PPMO Workshop held at San Jose State University on May 16-17, 2011 successfully accomplished its objectives to the extent that was expected. However, the objectives defined before the workshop have not been completed – this workshop is considered to be just a first step to addressing the problem of performance- and cost-effective mission operations to support the burgeoning small satellite business.

Ground Segment Control Tool (GSCT)—This is a graphical interface for monitoring and controlling the ground network. GSCT includes all the pertinent information of each ground station, such as location, antenna type, contact information as well as a status for the ground station. The GSCT displays the ground station configuration for an upcoming contact (e.g., which files are waiting for upload, frequency setting, ephemeris file used for open-loop tracking). It also allows monitoring of the ground station status during a contact, displaying the antenna pointing angles, actual versus predicted antenna pointing, carrier signal detection and lock status, signal strength and data rate, etc. GSCT also allows the user in the MOC to send commands to the ground station as required. The GSCT is designed to view the ground segment/network data in a manner that allows the user to understand the information quickly and easily. It is possible to view all of the ground stations on a map with their statuses easily discernable. The input to GSCT comes

Some of the major stakeholders in small satellites and their operation such as NASA, NRO, and the DoD addressed the workshop. Many organizations were identified that are interested in responsive and effective operations of spacecraft, especially multiple small spacecraft, using ground systems that are designed especially for porting to new MOCs and for modifying for new spacecraft. The current state of the art was explored in such mission operations systems (which are most likely to be Plug-andPlay architectures), with identification of some existing systems, such as JPL’s AMMOS, GSFC’s GMSEC, NRL’s MC3, and ARC’s MCT. Systems are that currently in development that may meet this need were examined, such as HSFL’s COSMOS and ESA’s GENSO. During the workshop issues (interfaces, protocols, proprietary and security issues, etc.) were identified that will be faced by such systems and possible first order solutions 10

to be investigated. The workshop also identified and characterized possible future applications for such systems, such as for fleet (constellation) control, simulations and testing, and enhancements to the ground segment and communications.

ARC

Ames Research Center

CCSDS CE

Consultative Committee for Space Data Systems COSMOS Executive

CGA

Command Ground Architecture

Two major issues that were identified and discussed were standardization and communications, especially frequency allocation. Both of these in particular need considerably more attention in the future.

COSMOS COTS

Comperhensive Open-architecture Mission Operations System Commercial Off The Shelf

DMA

Data Management Agent

The workshop was very successful in networking between the players in this field and possible establishment of collaborations that will benefit the participants and the industry as a whole.

DMS

Data Management System

DMT

Data Management Tool

DoD

Department of Defense

EELV

Evolved Expendable Launch Vehicle

This paper is evidence of successfully accomplishing the objective to produce a white or conference paper on the results of the workshop.

EPSCoR ESA

Experimental Program to Stimulate Competitive Research European Space Agency

As stated earlier, the workshop did not conclude the objectives, but took a promising start in accomplishing them. This was a necessary start, but much more dialogue and collaboration is needed before the problems of “plug and play” mission operations are solved. The way forward includes additional workshops, some of which will be specialized instead of general as was the one in 2011. It is intended to also generate additional papers both on the results of the workshops and especially to report on the implementation of the methods identified by the workshops..

ESPA

EELV Secondary Payload Adapter

GENSO

Global Educational Network for Satellite Operations Geostationary Earth Orbit

GEO GMSEC

REFERENCES [1] PPMO Workshop Web site: http://ppmo.arc.nasa.gov/ [2] Sorensen, T.C., E.J. Pilger, M.S. Wood, M.A. Nunes, “Development of a Comprehensive Mission Operations System Designed to Operate Multiple Small Satellites,” SSC11-IX-3, 25th Annual AIAA/USU Conference on Small Satellites, Logan, UT, 8-11 August, 2011.

GSCT

Goddard Mission Services Evolution Center program Ground Segment Control Tool

GSFC

Goddard Space Flight Center

GUI

Graphical User's Interface

HSFL

Hawai‘i Space Flight Laboratory

INS

Inertial Navigation System

ITAR

International Traffic in Arms Regulations

JPL

Jet Propulsion Laboratory

JSON

Java Script Object Notation

LEO

Low Earth Orbit

MC3

Mobile CubeSat Command and Control

MCT

Mission Control Technologies

[3] Sorensen, T.C., et al, “Effective Science Mission Planning and Operations - The Clementine Approach,” Paper RAL.GS.31, 1st Annual Reducing the Cost of Space Ground Systems and Operations Symposium, Rutherford-Appleton Laboratories, UK, June 1995.

MDS

Mission Design Support

MOC

Mission Operations Center

MOE

Measure of Effectivness

MOST

Mission Operations Support Tool

[4] Sorensen, T.C., E.J. Pilger, M.S. Wood, E.D. Gregory, M.A. Nunes, “Development of the Mission Operations Support Tool (MOST),” AIAA 2010-2230, SpaceOps 2010 Conference, Huntsville, AL, 25-30 April, 2010.

MOT

Mission Operations Team

MPST

Mission Planning and Executive Tool

MTI

Multispectral Thermal Imaging

NASA NRL

National Aeronautics and Space Administration Naval Research Laboratory

NRO

National Reconnaissance Office

OCAMS OTB

Orbital Communications Adapter Monitoring System Operations Test Bed

PPMO

Plug and Play Mission Operations

GLOSSARY OF ACRONYMS ACPT

Automated Collection Planning Tool

AFRL AIAA

Air Force Research Laboratory

AMMOS

American Institute of Aeronautics and Astronautics Advanced Multi-Mission Operations System 11

SDR

Software Defined Radio

SERB

Space Experiments Review Board

SJSU

San Jose State University

SMC

Space and Missile Systems Center

SMDC

Army Space and Missile Defense Command

SOH

State-Of-Health

STK

Satellite Tool Kit

STP

Space Test Program

SW

Software

TCP/IP TDRS

Transmission Control Protocol/Internet Protocol Tracking and Data Relay Satellite

UHF

Ultra High Frequency

VPS

Virtual Private Server

XML

Extensible Markup Language

Mr. Bruce Yost is the acting Program Manager for the Edison Small Spacecraft Flight Demonstration Program within the Office of the Chief Technologist at NASA. He began his career at the Kennedy Space Center working in payload processing on the Space Shuttle and has also worked at NASA HQs. After moving to Ames Research Center, he has worked on International Space Station (ISS) payloads and, recently has served as a project and mission manager in the Nanosatellite Missions Office where he held mission management responsibilities for NASA’s cubesat spacecraft dating back to Genesat. Joan Differding received her B.A. in Physics from Swarthmore College in 1985 and an M.S. in Medical Information Sciences from Stanford University in 1988. She is the Director of the MultiMission Operations Center (MMOC) at the NASA Ames Research Center in Moffett Field, California. The MMOC supports operations of Ames space missions such as LCROSS, Kepler, SOFIA, LADEE and IRIS. She has been at Ames for 17 years and has lead software development teams and information standardization efforts on the Constellation Program, the Mars Exploration Rovers mission and Ames wind tunnel operations projects.

BIOGRAPHIES

Originally from Australia, Dr. Sorensen received a D.E. degree in Aerospace Engineering from University of Kansas in 1979. His doctoral project was on Pioneer Venus at NASA Ames. At NASA JSC he was a Space Shuttle guidance and control engineer, worked in Mission Control as assistant Flight Director, and finally was a software engineering manager supporting Shuttle missions. In 1990 he joined Bendix Field Engineering in Alexandria, Virginia, as Observations Manager of the DoD’s LACE satellite. In 1994, he was the Lunar Mission Manager for the DoD/NASA Clementine lunar mission for which he received the NASA Medal for Exceptional Scientific Achievement. He was the program manager for the NRL Space Systems R&D contract under which the USAF MSTI-3 satellite was operated. He was then technical architect and for development of Honeywell’s global satellite ground network, DataLynx. From 2000-2007 he was on the faculty of the KU Aerospace Engineering Department. In 2007 he joined the University of Hawaii as a Specialist and project manager in the Hawaii Space Flight Laboratory. He is a Fellow of the American Astronautical Society, a Fellow of AIAA, and is the Director of the AIAA Space and Missiles Group.

Eric Pilger received a B.A. in Astrophysics from Williams College in 1982 and an M.S. in Astronomy from The University of Hawai‘i Manoa in 1986. He was with the NASA Infrared Telescope Facility for 8 years where he developed software for instrumentation and telescope control. He then moved to the Hawai‘i Institute of Geophysics and Planetology as a Software Engineer where he has developed numerous applications for remote data acquisition, analysis and visualization. For the last 3 years, he has also served the role of Lead Software Engineer for the Hawai‘i Space Flight Laboratory.

12

Miguel Nunes received his B.S. in Aerospace Engineering from the Instituto Superior Técnico (IST) from the Technical University of Lisbon, Portugal and his M.S. in Mechanical Engineering from the University of Hawai’i at Manoa (UHM), USA. He is currently enrolled in the doctoral program in the Mechanical Engineering department at UHM. Since 2009, Miguel has worked as a Research Assistant at the Hawai’i Space Flight Laboratory in the development of the HawaiiSat-1 as the lead Thermal Engineer, Space Mission Analyst and Software developer. More recently he started the development of the Operations Test Bed for the COSMOS project.

13