Small satellites (smallsats) have become mainstream—large scale constellations are a promising next step.
New business ventures are deploying constellations of smallsats that are aggregated and networked to perform remote sensing, image collection and Internet routing.
To date, the number of deployed smallsats in any one constellation range from the single digits to perhaps fifty in number. However, that’s about to change. New constellations are targeting tens, hundreds, and in some cases, even thousands of smallsats to meet connectivity, coverage, or revisit rate requirements.
These are exciting times, and perhaps surprisingly, the satellite is not the driving force behind the complexity of these new constellations, but rather the ground system software that must direct the big show.
Constellations transitioning from the prototype phase and going through the rapid buildup phase present a real challenge for the ground software. It is simply not the ideal time to be working through undiscovered issues in the ground software right now when the next several gaggles of satellites are being deployed, one right after another.
Herein lies one of the key risks for new satellite constellations and system emulation is central to reducing this risk.
Risk Profiles
It’s an understatement to say that designing, deploying, and operating a space system employing a dozen, a hundred, or a thousand satellites is complex. There’s inherent risk “building up” the number of on orbit smallsats from few to many in a short period of time. The risk profiles for the space segment and the ground segment are remarkably different as a constellation of small satellites is deployed.
Within a satellite constellation, each spacecraft is, more or less, its own ecosystem. Each spacecraft has a self-contained structure, power, attitude control, sensor for data collection, data processing and storage, and communications links.
Smallsats, in their LEO are designed to be autonomous. Scaling from two to 10 and then to a hundred spacecraft is a replication effort. The complexity of each individual spacecraft does not increase with the size and deployment of the constellation.
The business risk to the new venture associated with the spacecraft actually decreases as the constellation is launched and deployed. The satellite design is incrementally refined over time, becoming more and more proven with each production lot of spacecraft.
Conversely, the complexity of the ground software that manages the constellation grows non-linearly for some time as the satellite constellation increases in numbers, settling down only as operations become routine and more automated. It’s like managing a company of five and rapidly growing it to a corporation with several hundred employees—what’s straightforward at first, quickly becomes complicated, time-consuming, and has the potential for continual and costly do-overs.
It’s risky to defer full scale testing of ground software, waiting for a majority of the satellites to be in orbit
Constellation Management
The tasks of managing the satellites, their collection of data, and the processing and dissemination of that data falls predominantly on the ground system software. It is this software that becomes increasingly complex as the constellation size is scaled from prototype to full operations. The bigger the constellation, the bigger the task at hand for the software engineers.
As every software engineer and every business manager knows, software issues increase as new code is developed, new functions are added, and new interfaces are exercised. The rapid rate of change is what delays the maturity and reliability of software. It is with increased use, and a slowing in the rate of change, that software becomes dependable.
Operational Software Matures With Time
This paradigm is at odds with how a satellite constellation is deployed. The period of greatest change for the ground system software is exactly at the crucial “make-or-break moment” for the new venture, when new spacecraft are rapidly being deployed to fill out the constellation. There could not be a worse time to begin encountering issues in the nearly new ground software that is so central to operating the system.
Enter System Emulation
A system-level emulation is a software-based framework that provides the means to exercise the flight software, ground applications and operations automation long before there are any satellites on orbit. Emulation plays a vital role in validation of the operational system at a point when changes can be more easily made.
The emulation models the satellite data, communications links, and data flows, using separate software emulators to represent the spacecraft, ground terminal equipment, and the ground networks. Each emulator can be easily replicated, allowing for simulation of multiple antenna sites and a full constellation of satellites. As any individual emulation is enhanced, those changes take effect across the entire system. Three tenets are central to the system emulation architecture:
1. The emulators adapt and evolve from system implementation to system validation and then again from system validation to system operation. Both the scale and the fidelity of the emulation increase at each stage.
2. The emulation mimics the planned system. There are two aspects to this. The system emulation performance loads networks and applications. The system emulation also provides an efficient way to simulate errors, exercise corner cases, and run at degraded levels.
3. The software-based emulators are built with the interfaces that allow operational components to be swapped in. For example, flight software and satellite simulators connect into the emulation framework. Over time, the system emulation is replaced with the operational system and its satellites, space links, ground networks, and control applications.
Scaled Fidelity
Incremental co-evolution of the emulation with the ground system avoids the flash-of-lighting approach to software creation. The fidelity of the system emulation is scaled to reflect the maturity of the fleet management applications and the purpose of the testing.
If what’s required is simply generating the dynamic data loading from the satellites into the ground network, then replicated copies of a simple spacecraft emulator is all that’s required. This emulator mimics contacting the satellite and having the satellite dump its stored payload data before disappearing from view.
Emulation Software Scales In Lock Step
A more complete satellite emulator accepts a limited subset of commands and commutates a state-of-health downlink telemetry stream. It interfaces with a payload simulator that generates a payload data stream.
The emulation software produces a fully formatted downlink, one that mimics the operational downlink. This medium-fidelity application exercises a larger percentage of the ground applications, notably the command and control software and the payload data ingest software.
The highest level of fidelity might connect to the spacecraft factory to fully exercise and validate the command and control software. This version of the spacecraft emulator is simply what’s needed to connect the satellite to a wide area network.
Operator training and rehearsals is another use for the system emulation. This, too, scales the fidelity of the emulation as it rolls from software test to training and rehearsals.
Exercising Automation
Building automation into the ground software adds yet another layer of complexity. The automation that’s so essential to effectively managing a constellation of satellites takes time to develop and even more time to refine.
Developing automation for an individual satellite, a single contact, or a specific anomaly is difficult enough. Scaling that to hundreds of satellites is a significant challenge, but absolutely critical for efficient operations. Having an end-to-end system emulation to validate the automation is essential and the most cost effective approach.
“Fly like you test” is backwards thinking,
“Test like you’re flying” is more accurate
Automating the response to expected behaviors is only a fraction of the task. It is the unexpected and the anomalous conditions that expand and complicate the automation scripts.
With a satellite constellation numbering in the hundreds, there’s a problem to be dealt with every single day, and most likely, multiple problems on most days. It’s automating these responses and the contingency actions that are central to flying the large constellation with a small staff.
It can be downright difficult to get real satellites and real ground networks to misbehave on demand in order to exercise and test the automation scripts. They just don’t want to break only when you want then to—creating this bad behavior is simple with emulation software. Emulation software can mimic spacecraft anomalies, communications disruptions, contact failures, network bottlenecks, and general failures.
Having separate teams, one creating the automation and one designing the “problems” to test automation, is key. Make this exercise a bit of a cat-and-mouse game.
Initially the system emulation team dreams up the problems, implements them in the emulation, and tests the response of the automation software. The engineers developing the automation then get to refine their work.
Emulation software is ideal for testing and re-testing the automation software’s response to real problems. Real problems are usually difficult to recreate. The emulation can more easily recreate them, allowing for validation of the updates to operational software. This beats the “crossing your fingers and waiting for the next occurrence in the deployed system” approach to validation of anomaly–response automation.
Emulation Changes The Risk Profile
System emulation changes the risk profile by enabling full-scale test and validation of the ground software in the prototype phase rather than waiting for the deployment and build up phase. In effect, it better aligns the space and ground risk profiles.
This is critical to the success of an emerging small satellite constellation, allowing the new venture to proceed with increased confidence during constellation build-up; that critical moment when the business either provides return on the investment or fails to deliver on its promise.
The Discovery And Elimination Of Risk
Satellite constellations are the next step for smallsats. It’s a giant leap for the ground networks and control applications. A well-conceived system emulation ensures the infrastructure and software applications are well grounded before the herd of satellites head for space.
amergint.com
Randy Culver is the CEO of AMERGINT Technologies. AMERGINT products include satellite communications software for modems and ground processing. The company’s SOFTLINK™ product enables customers to emulate their future satellite systems and then easily transition from the emulation software to operational satTRAC™ and softFEP™ products.
