11015-25_Space_Cloud_Computing_v3_jcl.doc

Cloud-based computation and networking for space Brett Carvera, Timothy Esposito*a, Dr. James Lykeb aEmergent Space Technologies, Inc., 7901 Sandy Spring Rd, Suite 511, Laurel, MD 20707-3589; bAir Force Research Laboratory, 3550 Aberdeen Ave SE Bldg. 425, Kirtland AFB, NM 87117-5776 Abstract Cloud computing has transformed the evolution of software for much of information technology (IT) industry. Focusing on developing microservices rather than complete platforms has significant advantages, including enterprise interoperability, resiliency, and reduced system development and sustainment costs. Amazon Web Services (AWS), Google Cloud Platform, OpenStack, and Kubernetes are examples of public and private cloud technologies that commercial and government enterprise systems are migrating to. Unfortunately, these technologies do not extend to endpoints like Warfighter arm-mounted tablets and spacecraft. The goal of the Space Cloud Computing (SCC) project is to develop technologies that provide a corollary to public/private cloud concepts for all asset endpoints to enable new Warfighter planning and tasking concepts and superior levels of situational awareness. This paper explores the computation and networking challenges and solutions for such a platform in the space domain.

Keywords: cloud computing, high performance computing, flight software, distributed networking, distributed storage, satellites, constellations

1. INTRODUCTION

Cloud-based computing has been driven into prevalence through commoditization of computing and networking resources, due in large part to the trends in virtualization of computation, storage, and networking. With virtualization, the computing and networking substrates can be abstracted from their actual underlying physical (bare metal) form, freeing data centers to incrementally replace equipment in a way transparent to most users. This separation promotes rapid replacements of equipment to take place as Moore’s Law [] improvements in density and performance of microelectronics usher in new generations of equipment. Furthermore, localization of where computing is actually done is largely unimportant, allowing workloads to shift (also transparently) to the sites most economically advantageous to users (who vote with their purchasing decisions) and service providers (who may shift to cheaper, faster servers or sites where energy costs are more favorable) alike. For military users, security concerns complicate this fluidity and transparency, and many of the servers remain captive to their organizations. The concerns of security are not unique to the military, and service providers such as Amazon, who developed the well-known Amazon Web Services enterprise, are quick to point out their ability to differentially secure two trillion “data objects”[] to private and commercial customers, involving complex ownership and access policies. These clouds are expanding nonetheless to eventually include the government (work well in progress at the time of this writing []). The landscape evolves rapidly, while cybersecurity and traditional data security models have not, creating at minimum a complicated technical, logistics, and regulatory path forward to a logical projection of a very strong if not total migration of most “de-localizable” computation to a cloud form.

Since much computation can be de-localized, why should we not seek to place it in more places, including in the “space layer” itself, literally in orbit? Even if de-localization does not matter, we would begin to encounter a number of other constraints that do. A space-based cloud computing solution needs to address the presently limited possibilities of networking in space and availability of compute, storage, and sensor resources) is only part of the problem. The inability to rapidly move information even amongst the platforms and networks we have is in some ways as much the problem. Dozens of military communications architectures involve satellite communications, many of which are not interoperable, even those employing ground terminals that access the same satellites [sitcom1]. These fielded networks are complex to setup, provision, and operate individually, and bringing more of them together even if soluble address one facet of a more complex problem, namely the movement of information. Storing and processing information, to the point of fusing many sources to extract actionable knowledge are equally daunting tasks, even if the security mechanisms can be negotiated. Information is a “mess”, and to first order simply throwing more spacecraft in orbit does not appear to resolve any of these problems.

The movement of much of the world to “clouds”, the evolution of entirely new genres and categories of knowledge sources (e.g., social media), and the sweeping nature of mobile devices and their facility to negotiate these data sources and services (on top of the legacy sources and outlets) have inspired military planners to seek a “Combat Cloud”. The USAF Air Combat Command (ACC) has been one of the more vocal proponents[]. Eggert [] in a visionary talk proposed the Combat Cloud as a new paradigm for how information is gathered, fused, made accessible to war fighters who need it. In this cloud, all data would be discoverable, with concepts for sensing as a service, where data would itself by intelligently virtualized across several sources. Futhermore, this cloud would exploit social media, to the point of becoming a “Facebook for combat”. The role of communications or more specifically the movement of information was stressed (“if data can’t meet data, there is no fusion”). Hence, we can infer that as an idealized concept, the Combat Cloud would not only provide the key pillars of information processing (e.g., communications, storage, and processing) on demand, but somehow deal with security barriers and bind semantics to the data in ways that would be necessary to make such a cloud responsive automatically in the time of need.

Xxxxxxx

In this paper, we consider some of the structural mechanisms necessary for a combat cloud to work. We strictly on the what we will call the information triad: movement (communications), storage, and processing. We will consider for example, how information from some sources might be routed for processing at other destinations to be used at still other locations. We will attempt to demonstrate that done properly, there may be cases where the delocalization benefits of cloud systems can improve how the warfighter might obtain advantage. We do not attempt to define the semantics or algorithms of fusion and decision making. In our way of thinking, and algorithm (in the Turing machine sense) can be executed on any computer, and as such even the most sophisticated decision heuristic is reducing to a set of computing instructions. This concept liberates us to think strictly about these cloud problems in terms of the bulk of the computation, the difficulty (but not detailed content) of the computation, and the consequences of doing the equivalent computation locally, off-site, even off-planet.

Networking technologies that need advancements include standards and protocols, cross-link transceiver technologies, and a tiered approach to adopting and validating capabilities. A four-stage approach was proposed at the Space Cloud Protocol Technology (SCOPT) workshop1, which is described below and depicted in Figure 1:

1. Stage 0: Persistent connection to Internet through multiple services

2. Stage 1: Single-domain private network with a set number of maximum clients supported

3. Stage 2: The Stage 1 networks are interwoven and defined as overlays on a substrate network

4. Stage 3: Extended on demand network; a.k.a. Space Cloud

Figure 1. Space networking stages to reach full space cloud. Reliability and latency improvements are realized as space-based cloud computing network topologies advance through the stages.

* timothy.esposito@emergentspace.com; phone 1 301 345-1535 x229; emergentspace.com

Space mission capabilities are always limited by the available resources on a spacecraft. That is why most missions merely collect sensor data and then download it for processing on the ground using dedicated science operations centers or ground-based cloud computing services. For more opportunistic or complex mission scenarios, such as deep space science or robotics exploration, leveraging resources on networked assets is a game changer. It should not matter where the compute, storage, or sensor resources reside. Figure 2 depicts a generalized abstraction of available resources on the network. A flight software (FSW) service can leverage any combination of resources that would be selected using criteria of capabilities, capacities, bandwidth, latencies, priorities, and long-term resource availability. For instance, you would not want to store data on a node that is simply passing by and you would not have a chance to access it at a later time. It is expected that assets would have a mix of computational abilities. Tasks need to be considerate of CPU architecture and operating systems. Some assets may even contain a mix of graphics processing units (GPU) and field-programmable gate arrays (FPGA). These considerations make resource scheduling a complex activity that needs to be addressed in a SCC architecture.

Figure 2. Generalized abstraction for location agnostic elastic cloud. Flight software services can choose to leverage a mix of compute, storage, and sensor resources on the accessible network.

Deriving the computation cost of using any resource can be expressed as a task flow graph (TGF), with a simplified version shown in Figure 3. Energy and latency are two of the significant parameters in the computation costs. The more hops there are the higher the latencies will be.

Figure 3. Task flow graph for computing problem. Computations are expressed in terms of energy and latency, where edges represent communications costs.

2. Existing Challenges There are numerous challenges associated with a space-based cloud computing platform. Resource limitations, networking, and lack of standards of computing platforms and flight software frameworks are a few of the particular challenges addressed in this section.

Ground-based Cloud Computing Infinite Resource Model The capabilities of ground-based cloud computing platforms, including both public and private, are very good at tracking resource utilization, but not limiting it. This is the case because public cloud providers are able to deploy significantly more computing resources than what a single customer will need. Amazon AWS is a prime example of this scenario. Cloud teams and tools will monitor available hardware resources closely and deploy more as needed when capacities are being reached. This approach supports revenue driven models very well where there is an abundance of computing power, storage, and networking available in large server farms distributed throughout the country and world. Cloud-based software and services on a space platform cannot follow the same set of features.

After inspecting several private and public cloud computing platforms, particularly OpenStack2, Kubernetes3, and AWS Elastic Compute Cloud (EC2), it was found that there were many similarities to the services. Table 1 describes the breakdown of services in ground-based solutions. Note that the service names don’t match any of the products, but they are reflective of their function.

Table 1. Breakdown of Cloud Computing Services. Commonality of functions was found in multiple cloud computing platforms.

A space-based cloud computing platform can utilize some of the same concepts, but there are some key differences that need to be considered. The space-based platform is expected to be largely autonomous, so the application programming interface (API) or client interfaces are not expected to be web interfaces that focus on provisioning and managing allocated resources. Different allocation and resource priority models are needed. You would also expect a very controlled handshake model for new assets accessing system capabilities or joining the network. The process won’t be filling out a web form, you enter your credit card, and then you are free to start using resources.

Obtaining knowledge of resources and scheduling needs to be a very dynamic and distributed process because assets will frequently join and leave the local network. Data centers and computing resources in data centers for ground-based solutions tend to be mostly fixed, so resource knowledge and scheduling is very predictable and deterministic. In the space-based solution, endpoints accessing the system can include user or Warfighter terminals in the field, orbiting spacecraft, robotics, unmanned aerial vehicles (UAV), spacecraft mission operations centers (MOC), or any other autonomous vehicle or system.

The highly dynamic nature of resource availability also requires special considerations for storage and compute orchestration. Ground-based solutions will almost always have high-speed and usually fiber optic networks. Algorithms to determine nodes to use for storage in a space platform must be very bandwidth conscious. It must also have knowledge of orbital mechanics, cross-link transceivers, ground stations, and antennas. Compute service limitations must extend just beyond networking where functions like transferring full virtual machine (VM) images may be prohibitive. Space platforms will also have a mix of CPU architectures (e.g. x86, ARM, RISC, SPARC) that must be a consideration if executables are being exchanged for compute environments.

Monitoring a ground-based cloud platform is simple because a user will have direct access to APIs and networks. A space-based platform must support functions for autonomous options and the delivery on monitoring data to neighborhood nodes and the MOCs.

Networking challenges are significant for a space-based cloud computing platform. As previously mentioned, bandwidth is a significant limitation. All neighbor nodes are expected to have different link capabilities and protocols in use. Links having different speed capabilities will certainly expect congestion issues. Any networking service must be designed to operate in a heterogenous environment.

Delay Tolerant Networking One of the specific challenges of networking in a space-based platform is that links will have periodic observable windows. Many disruptions are due to the nature of spacecraft orbits where links are broken during parts of orbits where the planetary or other body obstructs the line of sight. NASA has worked on specifications and technologies to solve this specific issue, which is called Delay or Disruption Tolerant Networking (DTN)4. Figure 4 depicts a concept of all the possible links that could exist across the solar system.

Figure 4. Disruption Tolerant Networking Concept. DTN protocols are design to enable the Solar System Internet. Image courtesy of NASA.

A DTN implementation called the Interplanetary Overlay Network (ION)5 was developed and implemented by NASA. It includes software services for implementation multiple Consultive Committee for Space Data Systems (CCSDS)6 standards, including CCSDS File Delivery Protocol (CFDP), Bundle Protocol (BP), and Licklider Transmission Protocol (LTP). As more spacecraft and vehicles implement these CCSDS standards for DTN functionality, space-based cloud computing concepts can be realized.

Limited Flight Software Standards Most ground-based cloud computing platforms work heavily with 64-bit x86 processor architecture and the Linux operating system. While there are multiple flavors of Linux distributions, configurations, and cloud container customizations, there is some homogeneity that enables cross-platform support for executable code. There are a smaller number of CPU architectures available, but there are many FSW frameworks available. Developing a software solution that can span multiple CPU and FSW framework combinations is a concern from an interoperability perspective.

The Core Flight Software (cFS)7 is one solution that attempts to partially solve the platform interoperability problem from a framework perspective. It allows developers to write FSW applications with abstractions from any platform dependencies. It uses an API that takes much of the POSIX API. Any solution for sharing executables for VM images would still need to consider CPU architecture compatibility.

3. Enabling Technologies This section will cover some of the enabling technologies to make the space-based cloud computing concept a reality. While DTN was discussed as a challenge, the ION and related CCSDS standards can also be considered an enabling technology.

Non-Geostationary Orbit Communication Constellations Networking and DTN specifically were already identified as key challenges. For low-Earth orbit (LEO) and terrestrial vehicles, non-geostationary orbit (NGSO) communications constellations can significantly enhance space-based cloud computing concepts. There are existing solutions for Internet connectivity using higher geostationary orbits, but they suffer from higher latencies (multiple seconds for data roundtrip) and no global coverage. Lower altitude orbits are capable of transmitting data at higher speeds and latencies as low as 25 milliseconds. Global coverage is achieved by launching many satellites and using cross-link communications. One example is the OneWeb8 program that is planning about 600 satellites in its constellation. The Starlink9 program is an even more ambitious effort where they initially got FCC approval to launch 4,425 satellites in March 2018 and later 7,518 additional satellites in November 2018. These NGSO communications constellations will remove the need for delay tolerant operations with assets that can connect to these communications networks. Another advantage of these networks is that TCP/IP protocols will most likely be leveraged that will make application and FSW services development simpler.

Security is a concern, especially for military or commercial applications that transmit sensitive or personal information. Space-qualified High Assurance Internet Protocol Encryptor (HAIPE)10 devices can add trusted cryptography with a National Security Agency (NSA) Type 1 encryption certification.

Message Standards

There are challenges to overcome while traversing networks and protocols, but ultimately the goal is to transmit data structures using established serialization/deserialization methods and protocol encapsulation. Data bridges and routers are required to traverse networks and handle the encapsulation methods.

The Universal Command and Control Interface (UCI)11 is a set of message specifications initially defined for UAV scenarios. It is currently being extended to support many Space Command and Control (SC2) functions. The messages will cover many of the functions needed for space-based cloud computing.

Modular Open Systems Approach Making space systems interoperable to meet future needs is very important. Nobody has a crystal ball and can predict actually what systems and capabilities will be needed in the future, but using certain design principles can reduce stove-pipe and single-purpose solutions without any extensibility. United States Department of Defense (DoD) has published acquisition guidelines for developing or procuring open systems called the Modular Open Systems Approach12. It lists specific guidelines to follow, including:

· Establish an Enabling Environment: The program manager establishes and full product lifecycle strategy and business strategies, including the mandate of open standards and protocols.

· Employ Modular Design: The four design principles described are cohesive, encapsulated (hide inner workings of module’s behavior and data), self-contained, and highly binned (broad definitions for commonality and reuse).

· Designate Key Interfaces: The most important key interfaces should be identified from less critical functions, such as those needed for net-centric functions. Key interfaces are expected to have a higher level of reliability, such as guaranteed 100% uptime.

· Use Open Standards: This avoids vendor lock-in solutions and the standards should be mature, widely used, and readily available.

· Certify Conformance: A system should be verified and validated using conformance certification and test plans. A test suite would verify requirements are met and open standards are used properly.

Following these MOSA guidelines will be critical to enabling space-based cloud computing concepts.

Cross-Link Communications

Most satellites have an antenna for communications with a ground station antenna only. Other satellites have cross-links that operate only with a single frequency to meet the needs of a particular mission. Those constellations will generally have limited capability for third-party satellites to join the network and leverage those cross-link transceivers for direct communications. One study proposed the use of software-defined radio to enable inter-satellite communications solutions for small satellites13. This study describes a new communications paradigm called NeXt Generation (xG) network that utilize Dynamic Spectrum Access (DSA) and Cognitive Radios (CR). The approaches help with efficient usage of spectrum and can avoid signal interference.

Communications beams are directional, particularly for small satellites that will have limited power to use for radio transmittal. If you are providing a space-based service where nodes can join and leave your network, there must be discovery capabilities that can be challenging with unknown position information. The Jet Propulsion Laboratory (JPL) is developing an inter-satellite omnidirectional optical communicator (ISOC) antenna that will enable small satellites to communicate at Gbps speeds over distances of up to thousands of kilometers14. A rendering of the ISOC is shown in Figure 5. It is capable of full duplex operations and maintaining simultaneous links with multiple satellites. Because of its shape, no beam steering is required. Less moving parts means it will not require setup times for communications and there are less opportunities for mechanical failures. The ISOC can be a valuable technology enabler for space-based cloud computing.

Figure 5. Inter-spacecraft Optical Communicator. The ISOC is capable of high-speed communications with maintaining simultaneous duplex links to multiple spacecraft.

Chiplet Based Heterogeneous Processing

Radiation hardened (RAD-hard) processors always lag behind in performance when compared to non RAD-hard CPUs. The time it takes to certify the RAD-hard CPUs and its manufacturing processes make it very expensive. This is necessary because spacecraft computers must survive the harsh ionizing radiation that cause latch-ups and single-event CPU upsets. To address this concern, AFRL and NASA teamed up to perform a study called the next-generation space processor (NGSP)15. The general agreed upon approach that multiple independent partner team members took was to place a complex system on a chip and use a farm of multi-core processors and array of interfaces. The research team devised a CPU solution concept to fractionate a complex design with the use and many smaller processors called a “chiplet.” CPU manufacturers like Intel and AMD always find creative ways to make their chips more powerful by adding more cores. Once a single chiplet is RAD-hardened and space qualified, integrators will have the flexibility to connect as many as they need to meet their mission needs.

Figure 6. Chiplet as an Integrated Circuit (IC). Many chiplets can be deployed to spacecraft bus to duplicate the integrated parallel processor capabilities on more complex multi-core chips.

While the chiplet design is cheaper and grants lots of flexibility to system integrators, it does suffer from speed due to serial bus interface and power consumption will be higher. From a FSW perspective, an additional benefit of a chiplet design is the ability or isolate compute tasks that can be treated as a sandboxed environment.

4. Space Cloud Computing Technology Project Overview

Emergent Space Technologies, Inc. (Emergent) is currently working on a research project for the Air Force Research Laboratory (AFRL) to build a FSW platform called Space Cloud Computing (SCC). It is being designed to address the challenges described in Section 2 and leverage the enabling technologies described in Section 3. SCC follows open architecture MOSA approaches and is meant to be a service provider that integrators can utilize as either their primary or secondary mission. Then projects that wish to utilize the SCC services can interact with them through a networking interface, whether that be through terrestrial links to a spacecraft MOC, direct MOC to spacecraft control, or through cross-link communications. The SCC FSW services are described in Table 2.

Table 2. SCC FSW Services. These are the core functions of the platform, on top of which goal-based planning scenarios are implemented.

It is not expected that all spacecraft in a network would perform all SCC functions. In a ground-based cloud computing platform, servers are specialized for storage or compute and the same principles can apply for a flight platform. Some nodes may have lots of storage while others contain specialized sensors. Figure 7 shows an operational view of the SCC services in action.

Figure 7. Operational View of Space Cloud Computing Concept. Traditional satellite programs focused on the use of all self-contained sensor systems where data is downlinked to the ground where all data fusion, computation, and analysis is performed on the ground. Future concepts need more responsiveness to perform computing, storage, sensor tasking, and networking on space platforms.

Cloud computing is a tool to meet a need, and as such, SCC alone does not meet any specific mission need. It is a mission enabler. SCC is expected to be a FSW framework where missions can either provide an SCC offering or leverage SCC services hosted on other spacecraft. Figure 8 depicts how a Warfighter goal-based planner would interact with SCC services. It would query the SCC planner services, which results in compute, sensor, and storage tasks getting scheduled and executed to meet the goals, and the loop is complete with alerts, messages, imagery, or other data returned back to the goal-based planner.

Figure 8. Goal-based and SCC Platform Asset-based Planning. The SCC services are responsible for resource (compute, storage, sensor, networking) planning only. Goal-based planning functions are customer developed functions that interface with SCC services.

Flight Software Agnostic Solution

One of the biggest reasons for not using a great technology is that it is not compatible with the platform a project has selected or is routinely used by a team that has lots of expertise and experiences with. Like holy wars, sometimes there is no convincing that can be done for a project to choose one FSW framework over another. In order to maximize SCC adoption, requirements were written for the services to support multiple FSW frameworks. All SCC FSW services are being developed to operate as standalone processes on multiple operating systems. Integrations with both cFS and Aspire16 high-speed messaging framework are being developed as lightweight service wrappers.

Managing data with multiple execution environments can pose some challenges. Telemetry and commands are handled differently in each FSW framework. The cFS Command and Data Dictionary (CCDD) tool17 is being used to model the telemetry and command database structures. The CCDD tool can then export the models to multiple formats, including cFS application header files. A new export feature will be developed for the xTEDS document format required by Aspire. The message payloads exchanged by services will be the same for all FSW framework implementations. All service messages are being defined as Google Protocol Buffer (GPB)18 definitions. GPB is a highly tested serialization and deserialization technology that compresses very well and automatically generates data access source code. These data structures are then encapsulated to support multiple frameworks and networking/transport protocols.

Test as you Fly

Monitoring and control of the satellite is always done from the MOC where the primary interface is a tracking, telemetry, and commanding (TT&C) system. The TT&C connects directly to ground stations and is the one critical MOC component that operators always rely on. It contains the telemetry and command databases, data decommutation system, scripting environment, and telemetry page display system. Instead of writing ground control and monitoring software, the COSMOS19 TT&C system is being used to monitor the SCC service state-of-health telemetry and to write all test and operations procedures. If an operational mission were to choose the COSMOS TT&C system for operations, the existing procedures and displays can be leveraged. This also follows the “Test as you Fly” principle where test artifacts are used directly in operations.

5. Conclusions Space-based cloud computing challenges and enabling technologies were described. The SCC platform is an architecture currently in the design and development phase. MOSA open architecture principles are being followed with the plan for the larger community to deploy SCC services or SCC-compatible services. Ultimately, the service messages are the only interface required for interoperability and Emergent plans to share those messages openly with U.S. government partners and contractors. If service messages are cleared for export control, international partners would also have access to these messages. Publishing the SCC service messages enable third-parties to write their own service messages. As long as their implementation is proven to be interoperable with the use of a compliance test suite, then the project would be considered a success! Once space assets are deployed hosting SCC services, there are many planned and unforeseen future applications that can be implemented.

References

[1] Lyke, James, “Space Cloud Protocol Technology (SCOPT) #2 Workshop: Introductory Slides,” 12-13 December 2018.

[2] “OpenStack Software Overview,” https://www.openstack.org/software/ (17 March 2019).

[3] “Kubernetes Components,” https://kubernetes.io/docs/concepts/overview/components/ (17 March 2019).

[4] Mahoney, Erin, “Disruption Tolerant Networking,” 25 May 2018, https://www.nasa.gov/content/dtn (17 March 2019).

[5] “Interplanetary Overlay Network (ION) software for Delay Tolerant Networking (DTN),” https://sourceforge.net/projects/ion-dtn/ (17 March 2019).

[6] “CCSDS Publications”, https://public.ccsds.org/Publications/default.aspx (17 March 2019).

[7] “Core Flight System (cFS),” https://cfs.gsfc.nasa.gov (17 March 2019).

[8] “OneWeb Technology: Small Satellites,” https://www.oneweb.world/technology#keyshot-module (17 March 2019).

[9] “Starlink Satellite Constellation,” https://en.wikipedia.org/wiki/Starlink_(satellite_constellation) (17 March 2019).

[10] “High Assurance Internet Protocol Encryptor (HAIPE),” https://en.wikipedia.org/wiki/High_Assurance_Internet_Protocol_Encryptor (17 March 2019)

[11] “Universal Command and Control Interface (UCI), https://www.vdl.afrl.af.mil/programs/oam/uci.php (17 March 2019).

[12] “Systems Engineering: Modular Open Systems Approach,” 1 August 2018, http://acqnotes.com/acqnote/careerfields/modular-open-systems-approach (17 March 2019).

[13] R. Radhakrishnan, W. W. Edmonson, F. Afghah, R. M. Rodriguez-Osorio, F. Pinto Jr., and Scott C. Burleigh, “Survey of Inter-satellite Communication for Small Satellite Systems: Physical Layer to Network Layer View,” arXiv:1609.08583v2 [cs.NI] 28 Sep 2016.

[14] Velazco, Jose E., "Omnidirectional Optical Communicator," Proc. IEEE 978-1-5386-6854-2/19, 119-129 (2019).

[15] Gabriel Mounce, Jim Lyke, Stephen Horan, Wes Powell, Rich Dyle, and Rafi Some, “Chiplet Based Approach for Heterogenous Processing and Packaging Architectures,” IEEE Aerospace Conference (2016).

[16] Pnp Innovations, Inc., “Products: Aspire,” http://www.pnpinnovations.com/products.php (17 March 2019).

[17] “cFS Command and Data Dictionary (CCDD) Tool,” https://github.com/nasa/CCDD (17 March 2019).

[18] “Google Protocol Buffers,” https://developers.google.com/protocol-buffers/ (17 March 2019).

[19] Ball Aerospace, “COSMOS: The User Interface for Command and Control of Embedded Systems,” https://cosmosrb.com (17 March 2019).

Other

[20] [satcom1] Erwin, S., "To predict the future of military satellite communications, ‘follow the terminals," Space News, 28 June 2018

Updated 3/20/19