Gateways – Translating between space and ground
June 10, 2021
Cloud software has changed space in nearly every conceivable way, yet it remains overshadowed by hardware’s historical dominance of the space narrative. This is the case for both space-based and ground-based hardware, from satellites, to ground networks to mission control. As software continues to eat space, we present a series of posts on some of the most unique aspects of Major Tom’s cloud-based architecture and how to add true value to satellite builders, owners, operators and end-users.
Industry Standards for Mission Operations
Today there exists a set of problems centered around the most critical function of a satellite mission; it’s day-to-day operations:
- Both ground station networks and on-premise ground station hardware exist on the market, but typically the software integration is at best a raw mod/demod interface, or if you’re lucky a raw IP socket.
- On top of current infrastructure, satellite operators typically need to implement their own ground-side telemetry parsing, command-and-control (C2), ground station pass scheduling, job scheduling, file transfer chunking, and more.
- For the very few ground station products that claim to integrate “out of the box” with a satellite’s telemetry and C2, the reality of fractured space-based data standards is that satellite companies are required to add risky and complex protocol translation layers either in their on-board software or in front of their ground station just to get it to work properly
- Satellite operators (especially new ones) typically hold off on implementing ground control software until they are near the end of the engineering of their satellite, adding risk and uncertainty for how the precious satellite data will arrive in their data centers.
Major Tom is the result of thinking about how to solve these problems. In this post, we explore our primary solution to the problems mentioned above – The Major Tom Gateway.
What is a Gateway?
We begin with an overview of Major Tom’s flexible architecture via an explanation of the Gateway and the Gateway API. Gateways are a common term in the space industry, typically referring to a ground station hub or terminal. In the case of Major Tom, a Gateway can be thought of as the translation layer between your satellite and Major Tom. Messages from Major Tom can contain information about the state of the world (such as Pass Events) or the actions of an Operator (such as clicking to execute a command). Messages to Major Tom contain information to help drive the UI, such as the progress of a file download, the telemetry from a satellite, or the status of a command being executed. The Gateway translates these messages to be read by the appropriate recipient.
Gateway vs. Gateway API
Major Tom does not natively support any communication protocols. Rather, we implement that support through the use of a Gateway. Again, a Gateway is an independent translation layer for communication and encryption protocols between spacecraft and Major Tom. Communication is sent across a WebSocket API (we refer to this as the Gateway API, not to be confused with the Gateway itself). Customers (and/or users) host their Gateway(s) in the cloud or in their own servers. User encryption keys as well as CCSDS or other protocols will also live in the Gateway. Using telemetry receipt as an example: when a Gateway receives raw telemetry, it decrypts and de-packetizes data, and then sends data over over the WebSocket API (Gateway API) in JSON format to Major Tom. Major Tom can then manipulate and send that data to a user. The Gateway can also act as a routing mechanism. For example, with respect to Payload and Telemetry, customers can send Payload information off to their own data processing pipeline that they have in their own cloud or on premise.
- Gateway = Independent software components that acts as a translation layer between the Satellite’s communication protocols and Major Tom’s protocols.
- Gateway API = The WebSocket API that connects Major Tom with the Gateway.
Benefits of Gateways
- Infinitely Flexible
- Separate Gateways can be created to support radically different space architectures. Gateways can be used to segment your channels of communication. For example, if you have multiple different “versions” of satellites, you could use a dedicated Gateway for each version. Or you may use a Gateway per ground station. Or you could put all flatsats on one Gateway and all orbital assets on another. The organization is flexible and up to the user. Check out our documentation for some ideas, the possibilities are endless.
- Faster development time
- C2, ground station pass scheduling, job scheduling, file transfer chunking are all pre-implemented, the only item that gateway has to do is command and telemetry parsing.
- Faster and easier integrations
- Ground station networks are pre-integrated (more information coming in a future post) – so APIs are clear for data in and out of Major Tom.
- Other integrations are also in the works, keep an eye on our blog and website for the latest information.
- Protocol-agnostic
- Most Command and Control (C2) solutions use a CCSDS implementation, meaning spacecraft need to adapt to a standard via changes in flight software or cumbersome and unproven ‘translation’ software needs to be written on the ground to move data from spacecraft to the C2 system. What this means in practice is that once a C2 system is chosen (in most cases well after spacecraft flight software has been written) the flight software needs to be updated to match the C2 standard. This introduces huge risk, effectively ‘resetting’ the flight heritage of the original flight software to “none”. Major Tom Gateways remove this risk for development and implementation, placing significantly less risk on space-borne assets AND removing complexity by re-using the Gateway code and Gateway API and making the changes on the ground, not in flight software.
- WebSocket APIs mean – no more importing or building cumbersome translations from C2 to Flight Software. The risk moves from space to the ground, since changing flight software protocols at the late stage is inherently risky.
- JSON is human-readable
- The icing on the cake is that because Gateways send data in JSON format, the files are incredibly easy and fast to read and can be easily manipulated
Gateway Details and Implementation
Major Tom doesn’t know what commands are specific to your satellite until it is configured. Customers or users write a Gateway (in any language—for example, we provide one for KubOS in Python) and talk to us over our Gateway API using the WebSocket protocol. Major Tom is truly out of the box operations software that reports data the way you expect it directly from your Flight Software applications. This includes, but is not limited to:
- Monitoring / thresholds for any subsystem telemetry
- File download / upload between multiple ground station passes
- Prioritized Job queue management
- Integrated Command and control shell
Gateways connect to the satellite in several ways:
- Directly (typically for flatsats)
- Through a ground station you control
- Through Major Tom’s Ground Station Network (GSN) interface. This is the Major Tom Feature that integrates with different ground station networks. The GSN Interface routes raw telemetry data from a GSN to the Gateway via the Gateway API. GSN integrations will be covered in a future post.
- To get started or learn more, click here for our documentation
