Ground station virtualization with Azure Orbital

Ron Vincent

Microsoft

Oct 06, 2022

Ground station virtualization with Azure Orbital

By Joey Frazee, Hrishi Shelar, and Ron Vincent

Accessing spaceborne data is becoming easier and more ubiquitous. With the reduction of size, mass, power, and cost of satellites and increasingly powerful, high-fidelity sensors, satellite access is becoming more common and the volume of spaceborne data is growing exponentially. The need for a flexible, cost-effective ground segment, including storage and compute, is taking on greater importance.

In this article, we discuss Azure Orbital Ground Station—a fully managed, virtualized ground station-as-a-service for managing and transmitting data from earth observation satellites and spacecraft—and provide an end-to-end reference architecture for the virtualized ground station and corresponding ground processing capabilities. You’ll find several options, advice on how to evaluate your needs, and pointers to additional content as you build out your plan to take advantage of this impactful opportunity.

An introduction to ground stations

The ground segment of a spacecraft system includes a launch facility, remote terminals, and a ground station.

The ground segment supports the space segment for command and control, spacecraft health monitoring, and tracking and calculating the spacecraft's position. The conventional role of the ground stations is to provide signal receiving and sending, signal processing, data format conversion and distribution, and ground station management.

Ground stations are similar in concept to Internet routers in that they forward traffic from one location to another, however they also have some significant differences. For example, satellites only pass over ground stations for a limited period of time, and ground stations have more components than a router. They are composed of the antenna system, transmitting and receiving equipment, a data-user interface, mission data recovery, a station control center, and a system clock. While these components are traditionally physical hardware, we can instead virtualize them just like we can virtualize hardware in a data center. What are the benefits of virtualization? How is this done?

Virtualized Ground Station Benefits

Virtualization changes the paradigm for aerospace development. In the old paradigm, proof-of-concepts in the lab relied on hardware assets and on-premises computing. Scaling these physical assets proves difficult as you must redeploy this system in each new region and reexperience all the pains associated with bespoke hardware and connecting them to your central mission control system (MCS).

In the new model, these same proof-of-concepts instead connect the lab to the cloud and leverage cloud-native tools. You can train your operators and control your lab assets through the same interfaces used for nominal operations. Then, using technology like virtual radio frequency (RF) and connected edge devices like Azure Stack Edge, prove out compatibility and leap from lab to flight in a minimal-step fashion. Global scaling becomes painless as you easily deploy to new regions and duplicate data services. Not only do you attain speed and reliability, but your expenditure is perfectly matched to your on-demand needs as you pay-as-you-go. You can confidently move from CAPEX to OPEX by taking advantage of a Platform as a Service offering in Azure.

Preserve your operational context

Virtualization is not only about embracing cutting edge technology and providing connectivity, but also making it easy for operators to move to the Azure cloud without having to rewrite their playbook.

Azure fully embraces virtualized RF technology. We implement digitizers at our ground stations that convert analog or physical RF to digital representations of RF using high speed sampling techniques to achieve large bandwidths. Furthermore, we comply with the standards of the recently formed DIFI consortium which specify how to format and send virtualized RF. This standard of interoperability guarantees compatibility with modem vendors who are also part of DIFI.

Many operators have built mission-critical hardware and software systems that build upon years of lessons learned and best practices. In some systems, operators may want to perform command and RF verification in a loopback before sending commands to the spacecraft. Virtualization lets you test in-lab with simulations, build a solution for flight, and scale these systems efficiently.

Manage your constellation and R&D with ease

Azure Orbital’s API simplifies management over various classes of spacecraft. The contact profiles are not spacecraft specific and can be leveraged across generations, enabling graceful transitions of operations. As mentioned above, you can extend this power to the lab and bring it in to production without friction.

When a ground station is virtualized, APIs are developed which can be consumed in an app. Those APIs can also be abstracted into higher level APIs, monetized, and deployed in an automated fashion. For example, with Azure Orbital, the REST APIs can be used in a Mission Control application which can be stored in source control, updated through a pull request, integrated with continuous integration, and then deployed as part of a deployment pipeline. This app can then be monitored in post-production deployment.

Azure Orbital Ground Station Architecture

In the diagram above, you can see how Azure Orbital manages all of the complexities of operating a global ground station network and frees the operator to focus on the mission. Antenna control and tracking, monitoring, and other similar components are orchestrated in the Azure Orbital Virtual Network. Data processing pipelines, mission control software, and mission specific items are deployed by the customer in their virtual networks.

Azure Orbital Ground Station is built on a robust hardware and software stack with a monitoring solution that alerts teams worldwide to errors or failures. Our response is comprised of a team of dedicated on-call engineers and vendor support centers.

This robust hardware stack provides virtualization of RF to a standard degree across all Microsoft sites and a network that enables high-speed backhaul of data. Our API is built around space ground operation specific items such as central frequencies, bandwidths, channels, endpoints, and modem configurations. The service takes care of applying these settings on a pass-by-pass basis across our first-party and partner integrated sites.

Building the Global Virtualized Ground Segment

The very nature of satellites and orbits implies that the mission operations and ground segment elements must be global and cross-region. Utilizing the Azure cloud and Azure platform services makes that easy. With 60+ regions, Edge Zones, and several sovereign clouds, Azure provides worldwide coverage and empowers you to build your global system exactly as you need. Azure Orbital is built atop this global backbone, and our Microsoft ground station sites and third-party integrated ground stations connect directly to the nearest Edge Zones.

Here we describe four layers:

1. Mission Control System – This part of the system contains your mission control software which is a custom application or a Software-as-a-Service. Some questions to consider: Are you going fully automated? How many regions do you need? Where are your operators? Do you need Virtual Desktop Infrastructure? Azure contains many services for building and hosting an application with services such as Azure App Service , Azure Kubernetes Service, Azure Container Apps, etc. Azure Active Directory (AAD) provides identity management. Also, .NET can be used to build a thick client mission app which can be hosted in the cloud and accessed via Virtual Desktop Infrastructure technology such as Azure Virtual Desktop. Azure Event Hubs captures the spacecraft telemetry which can be used to analyze the contact.

2. Collection layer- Once the data is downlinked by a first-party Microsoft ground station or a third-party partner ground station, it needs to be captured in cloud storage in a particular Azure region. Some questions to consider: What orbits are you in and what latency and/or bandwidth do you need? Do you wish to use a third-party site? See Bandwidth pricing.

3. Processing layer- The processing of that data can be done with services like Azure Synapse Analytics, Azure Kubernetes Service (AKS), Azure Batch and many others. With many of these services, you can scale both compute and storage at the hyperscale of Azure. For example, with AKS, you can take advantage of CPUs and GPUs based on a wide variety of SKUs. What degree of high-performance compute do you need? Do you require high-performance technology such as GPUs/FPGA? What levels of cold vs hot storage? Do you want more processing regions to avoid moving data across the world? Do you need database synchronization? Or geo-redundancy?

4. Dissemination layer- Making your data available to customers is key to your success. You can use open-source technology such as the SpatioTemporal Asset Catalog (STAC) or commercial technology such as Esri’s ArcGIS to serve the Analysis Ready Datasets. Also, because of the global scale of Azure’s backbone network and location of ground stations, the data can be captured in one region and copied or moved to other regions with technology like Azure Storage Object Replication asynchronously. A question to consider: What is the anticipated level of egress to the biggest consumers? See Monitoring Azure Blob Storage.

Data flow architecture

The block diagram below shows an example data flow from the satellite, through the ground station, and eventually to the consuming user. In this document, Esri’s technology is used but the data can be consumed by a myriad of different services. With this end-to-end flow, Azure Orbital allows you to schedule contacts with satellites and downlink the data into a VM and stream to Azure Event Hubs. The raw data can be stored in Azure NetApp Files, an Azure Storage account (blob), or in a database such as Azure Database for PostgreSQL or Azure Data Lake. Depending on the satellite and sensor platform, the data is transformed from Level 0 to Level 2 dataset (see NASA Data Processing Levels) using a service like Azure Synapse Analytics. The specific satellite and sensor dictate the level to which level transformation is required. Next, ArcGIS Pro can transform the data into a Mosaic Dataset. The Mosaic Dataset is then turned into an image service with ArcGIS Enterprise (on VMs or Kubernetes). ArcGIS Image Server can serve the data directly as an image service or a user can consume the image service via ArcGIS Image for ArcGIS Online. The high-level process works as shown in the following steps:

Data is captured from the satellite’s sensors along with the telemetry.
Azure Orbital Ground Station via a Microsoft owned ground station or a partner ground station receives the data where it is located.
Satellite data arrives in a VM.
Telemetry is captured in Azure Event Hub.
Data is moved to Azure Data Lake, Storage Account, etc.
Azure Synapse Analytics performs raster processing on the data.
ArcGIS Pro users on a VM or with Azure Virtual Desktop perform analysis on the data.
The data is published as an Analysis Ready Dataset or derived datasets are published.
ArcGIS Online users consume the data as is or they use ArcGIS Image for ArcGIS Online to perform additional analysis on the data.

Additional high-level architecture flows are located here.

In summary, we presented an overview of the benefits of virtualizing a ground station and reference architectures for Azure Orbital Ground Station. We also interpreted the architecture and presented some questions for you and your business to consider.

If you’d like to try out Azure Orbital Ground Station, you can find the documentation here. Also, to join the Azure Space Partner Community, go here.