Traditionally, government satellites required five to 10 year development cycles, and the completed spacecraft was factored with an operational lifespan of 10 to 15 years.
Some of the large satellites in orbit today have exceeded 20 years in space. That is impressive, to say the least, and speaks highly of the engineers who designed them. These satellites were expensive to develop, have complex mission capabilities and often have dedicated ground systems.
As these missions evolved, new, large satellites were designed on similar timelines. Each evolution represented its own multi-year program with well planned changes to match the mission, the vehicle, operations, and the ground systems.
Those older vehicles were designed for missions that existed in the 1990’s. The world has since changed and a more responsive approach is needed today. Space is now a contested environment. The U.S. military needs responsive missions as well as resilient architectures. To ensure success, these new architectures must be driven with the same philosophies, provide identical agilities as well as accommodate an accelerated rate of change, both in space and on the ground.
Small satellites (smallsats) offer a potential solution in space. They are less costly to develop and launch and have sufficient capacity for a wide range of sensors. With a lifespan of from three to five years, a frequent refresh of on orbit capabilities is attainable.
These smallsat features combine today to meet changing mission requirements and provide a natural resiliency in space. Functionality in traditional large satellites can be disaggregated, presenting a distributed attack surface. Smallsats can be more quickly replaced and those replacements can evolve the mission.
Ground Systems Impact
Ground systems have similar concerns — antenna sites and control centers can be targeted by an agile adversary. The associated computers, software, and networks can be attacked. Resiliency is even more important; however, instead of disaggregating, the current focus is on defining a common enterprise ground system architecture.
Multiple missions are being combined into a common control center. Alternate ground networks are being integrated and multipurpose antennas are being designed.
The new philosophy is commonality. Ground systems are being designed to support pluggable functionality, use generic message buses and require standard interfaces between components. On the surface, this has the appearance of a solid solution. The ground system can adapt to an attack. If one ground network is compromised, another is seamlessly switched in. Components can be quickly replaced, added, and upgraded. New missions can be integrated as new vehicles are launched.
However, the quest for resiliency on the ground is riddled with traps. If a common architecture or multi-mission control center is desired, a common baseline must be created. As more missions are added, the size and complexity of that baseline grows. Adding or changing a component requires increasing amounts of analysis and configuration management.
As part of even a small change, every requirement must be regression tested to ensure there is no impact to the operational system. The number of potential interactions between numerous components quickly becomes challenging — if not impossible — to manage. Enhancement of capability slows to a crawl. Unforeseen vulnerabilities become more likely, which in turn makes resiliency even more difficult.
These challenges are exacerbated when considering common IT functions, such as hardware refresh cycles, security patches and network upgrades. These form an additional dimension that is rarely thought about in the system level architecture.
A simple security patch can result in unscheduled, unplanned and unfunded changes. Upgrades to the operating system can potentially impact the software applications and the underlying, likely aging, hardware. The desire for a common architecture and a unified operating environment can make the system more exposed. The smallest vulnerability can bring the entire enterprise down.
Modern technologies, such as containers, virtualization and cloud-based computing, can be used to help alleviate this problem. These technologies separate software from hardware constraints. They create unique environments that allow hardware and software to be updated independently. Computing resources can be managed to meet changing demands and functionality can quickly be recovered in the event of a failure.
The time and cost involved in testing all possible scenarios, as services come and go, is prohibitive. The resulting complexity can make even the most basic of services unknowingly critical in the overall architecture.
Every interface, every abstraction and every virtualized service establishes new connections and creates new opportunities for failure. Ideally, regression testing accounts for this, but schedules, resources and, frankly, a lack of desire can dramatically limit effectiveness.
The potential benefits of smallsats may actually make the problem on the ground worse. If the future rate of change in space is considered, the timelines for a few programs are overlayed, the challenge can be quickly assessed.
The amount of change could overwhelm a common ground system’s ability to keep up — each new vehicle has the possibility of using a new waveform, higher data rates, new operational concepts, and alternate data formats. Standards can help, but standards take time and they establish an anchor. The benefits of smallsats become limited if they cannot take advantage of new technologies, prototype new concepts and meet an ever changing mission.
Traditionally, each mission had a dedicated control center and possibly their own ground network. Shared resources focused on the most common needs of each mission — monitor and control. Everything else was unique to the mission.
The technology available in space changed slowly and dedicated ground systems could easily keep up with the status quo. This paradigm changes with smallsats. The paradigm on the ground must similarly change.
The Solution is in Simplicity
As a software application product vendor, AMERGINT faces such challenges every day. AMERGINT supports more than 50 various satellite programs with mission-critical telemetry, command and payload processing systems. These include critical systems that support manned space flight, launch systems, Earth Observation (EO), and TT&C links on numerous programs.
Every customer is on their own timeline, has their own mission constraints, processes and security considerations. Each delivery has unique requirements, often stretching the bounds of current technologies and computing platforms. Yet, each delivery is verified, and updates are fully regression tested. Support calls are quickly handled and even larger system-level issues, beyond the scope of the applications the company provides, are rapidly resolved.
The key is in AMERGINT’s SOFTLINK™ architecture. By minimizing the hardware required to interface with the physical world, and using common, atomic, software building blocks, the company’s engineers are able to rapidly construct unique applications.
Each application is tailored to meet a customer’s exacting requirements. The underlying building blocks, or software devices, are optimized, fully unit tested, and used across multiple systems.
Applications are designed to support specific vehicles and combined to create larger systems. Interfaces are well defined and the system architecture is open. Using RedHat Enterprise Linux, AMERGINT’s products are security hardened and OS patches are kept up-to-date. As the customer’s mission changes, their application is safely upgraded without fear of impacting other customers. The ripple effect is minimized and complexity is managed.
No application is more complex than it needs to be to meet the requirements of a single mission. That underlying philosophy, more than any other, is how AMERGINT has succeeded. And that philosophy may very well be the solution to providing a resilient enterprise-level ground system for the U.S. government.
Admittedly AMERGINT’s SOFTLINK architecture is not the solution for a full enterprise ground system. The architecture is designed specifically for high performance, real-time, pipeline processing.
Yet, the philosophy of simplicity, agility, and openness that helped AMERGINT succeed is easily extended to meet the fundamental goals inherent in a common ground system.
Taking advantage of small, independent building blocks and constructing custom, virtualized ground systems for each vehicle is absolutely possible using today’s technologies. These virtualized ground systems need to only meet the requirements of a single mission and extend all the way from the antenna to the operator. They can evolve through the life of that mission without impacting other users of the architecture. Even waveforms, data rates, network protocols, and other mission specific functionality can evolve independently with the mission.
A philosophy of simplicity is vital. The space industry is realizing this and sees smallsats as playing a pivotal role in enabling a more resilient space enterprise. They are easier to replace, create a smaller target, and enable an evolving space warfighting capability that matches an ever changing environment.
However, the rate of change this imposes means the ground system must be equally dynamic and a desire for a one-size-fits-all architecture may actually hinder this. Combining rapidly changing small satellites with legacy program requirements, then factoring in government procurement cycles and oversight may simply do nothing more than bring the ground system to a halt.
This must be solved — a proven approach is in defining an architecture specifically designed to allow each mission to independently evolve.
Smallsats provide rapidly-evolving resiliency in space. They will not wait patiently as the ground system attempts to