Test and integrate ground segment with AWS Ground Station digital twin

Amazon Web Services (AWS) customers building software-defined ground segment solutions with the AWS Ground Station now have more confidence in their solution: they can integrate their DevOps practices with AWS Ground Station’s digital twin feature, which became generally available in August.

The digital twin is useful for both aspiring and existing AWS Ground Station customers to achieve faster outcomes without applying for satellite licensing and more cost-effectively than scheduling a production satellite contact. New AWS Ground Station customers can use the AWS Ground Station digital twin capabilities to assess AWS Ground Station APIs, AWS Ground Station mission profiles and configurations, and start validating integrations between AWS Ground Station and their mission control software well in advance of launch. Existing AWS Ground Station customers can use AWS Ground Station digital twin for ongoing configuration change management. For example:

• Establishing a preproduction environment for change management, integration and testing
• Customer provided ephemeris (CPE) can be used to validate configurations prior to launch and early operations (LEOP)
• Customers can integrate additional AWS Ground Station locations into their mission operations prior to the production spectrum licensing being granted

AWS Ground Station architecture prior to digital twin

A customer will typically create infrastructure as code (IaC) using AWS CloudFormation stacks to establish the primary AWS Ground Station configuration (to learn more, refer to Example mission profile configurations in the AWS Ground Station User Guide). The IaC creates AWS Ground Station specific entities, including a mission profile and data receiving and processing infrastructure such as an Amazon Simple Storage Service (Amazon S3) bucket for asynchronous downlink data delivery or an Amazon Elastic Compute Cloud (Amazon EC2) instance with software-defined radio (SDR) or data processing software for synchronous uplink and downlink data processing.

The customer managed mission control software then manages the appropriate tasking and telemetry, tracking, and command (TT&C) operations and schedules the desired satellite contacts through the AWS Ground Station API. The high-level architecture of a software-defined ground segment based on AWS Ground Station is shown in the following diagram.

Figure 1. Architectural diagram of the solution described in this post. The major components are AWS Ground Station, an Amazon S3 bucket, Amazon EC2, AWS Lambda, and AWS CloudFormation.

Prerequisites

To successfully schedule a satellite contact with AWS Ground Station, you need to have the following prerequisites in place:

• The IaC code must be syntactically and semantically correct, for example, the frequency ranges must be within valid limits and the eventual signal decoding profile must be correct.
• For Amazon S3 data delivery, the S3 bucket needs to be created and AWS Ground Station needs to have necessary permission to write data to the bucket.
• For Amazon EC2 delivery, the EC2 instance needs to be prepared with DataDefender (narrowband contacts), AWS Ground Station Agent (wideband contacts), and the installed SDR must be correctly configured to receive and process the data. As an additional consideration, the instance needs to be launched in sufficient time during pre-pass to be fully initialized by the time data starts to arrive from AWS Ground Station.
• The satellite contacts are maintained directly by the customer mission control software, using the AWS Ground Station API calls, and those API calls must both be syntactically and semantically correct. Because the AWS Ground Station antenna network is a time-shared resource, which can lead to contention with other AWS Ground Station customers, the customer also must schedule contacts that won’t overlap with contacts already scheduled and must manage exceptions accordingly.

Any subsequent changes made to the IaC or in the mission control software carries the potential risk to introduce a regression issue either into the contact scheduling component, the data processing infrastructure, or any of the associated configuration elements. Without proper testing, the regression issues can make their way into the production environment and disrupt the ground segment operations leading to wasted contacts and lost satellite data.

Prior to the AWS Ground Station digital twin functionality, to mitigate the risks of changes in IaC or mission control software, AWS Ground Station customers had to conduct manual or automated tests using the production AWS Ground Station service against real satellite contacts, which was neither cost-effective nor an operationally efficient use of the available resources.

Introducing AWS Ground Station digital twin

With the AWS Ground Station digital twin feature, customers can conduct integration tests of the changes in IaC and mission control software using the synthetic AWS Ground Station control plane at a significantly lower cost compared to the production satellite contacts in the live, operational environment.

The AWS Ground Station digital twin offers the same API functionality as the production AWS Ground Station service, so customers don’t need to change their existing code to access the new service. To use AWS Ground Station digital twin, customers must onboard their existing satellites or, if the customer doesn’t yet have their own satellites, public broadcast satellites. The satellites must be onboarded to a nonproduction AWS account for use with the AWS Ground Station digital twin. The separation of production and nonproduction environments makes sure that any potentially disruptive changes are evaluated prior to deployment to avoid impact to production operations, allowing for complete verification of the underlying configuration and validation of the configured data paths.

Although customers will schedule synthetic satellite contacts with the AWS Ground Station digital twin API, as of today the underlying control plane fully emulates the shared resources available in production, so any contact scheduling operations should accommodate contention with existing contacts, comparable with the production environment.

Note: No payload data is delivered during the synthetic contact, but the end-to-end contact lifecycle between the AWS Ground Station service and the defined dataflow endpoints (Amazon S3 or Amazon EC2) will be fully verified. As part of the contact lifecycle, the synthetic contacts will emit the same AWS Ground Station events into Amazon EventBridge , so the customers have an opportunity to verify the event-driven aspects of the architecture (for example, launching an EC2 instance during pre-pass). For the description of available events, refer to Automate AWS Ground Station with Events in the AWS Ground Station User Guide.

AWS Ground Station architecture using digital twin

The following image shows the architecture, where production and test environments are isolated from each other in dedicated AWS accounts. The test environment uses AWS Ground Station with digital twin.

Figure 2. Parallel development and production architectures showing how AWS Ground Station’s digital twin environment mirrors production system control-plane capabilities, allowing customers to safely test satellite contact scheduling, configuration changes, and workflow modifications before live deployment.

In an environment with AWS Ground Station digital twin, a customer can safely deploy and evaluate changes to the contact scheduling mechanism (including the customer-owned mission operations software and the underlying AWS Ground Station configurations) into the nonproduction account.

After the changes are successfully deployed, the user can conduct automatic or manual regression tests without impacting the production environment, including scheduling and management of synthetic contacts, validation of the launching, and configuration of the software provisioned on the EC2 instance and the complete end-to-end data path.

Customers can also use AWS Fault Injection Service to test the resiliency and availability aspects of their ground segment implementation by injecting faults into elements of the ground segment. To learn more about the supported services and FIS actions, refer to AWS FIS Actions reference in the AWS Fault Injection Service User Guide.

Assuming no issues are identified by the regression testing, the customer can then deploy the modified configuration into the production environment, significantly reducing the risk for production satellite contacts. If any issues are identified during nonproduction testing, the DevOps process will allow for continued change iteration and testing in the test environment with no impact to the production implementation.

Here is what one AWS customer says about AWS Ground Station digital twin:

“Using a digital twin has greatly simplified the process of deploying and testing mission control, thus making the best use of engineering man-hours and cutting down expenses considerably,” said Patrick Silva, principal engineer at CEiiA geoSystems.

Conclusion

In this post we showed how customers can use AWS Ground Station digital twin to accelerate implementation and test of ground segment prior launch of actual satellites, and to implement regression testing of changes in the existing ground segment implementation in an isolated test environment.

We encourage both existing and aspiring AWS Ground Station customers to use AWS Ground Station digital twin to support development and operations of their ground segment on AWS. To start using AWS Ground Station digital twin, follow the instructions at Use the AWS Ground Station digital twin feature to onboard your account to the feature.

Read more

• For information about Amazon EC2 data delivery, read the Putting it together section in Public broadcast satellite utilizing a dataflow endpoint
• For information about Amazon S3 data delivery, read the Putting it together section in Public broadcast satellite utilizing Amazon S3 data delivery