Basics of modern Mission Control Systems (MCS)

Typically, it works like this: You integrate your payload into a demo satellite to prove your technology or service. You select manufacturers and vendors, build the satellite, and design a ground system for testing and operations. Then you launch. As you identify and fix issues, you simultaneously design the system that will support your full constellation. If all goes well, you’ll proceed to launch the first batch of service satellites.

Well, that’s the plan, isn’t it?

Your situation is quite common across the industry. Most of our prospects are in the early stages of their mission, currently designing a precursor mission to demonstrate their technology before deploying the full constellation. The exact numbers vary, but typically, after the precursor mission, companies launch the first batches of satellites – usually just a handful at a time – with the target constellation size ranging from a few dozen to around one hundred satellites.

However, from an operational standpoint, this approach often comes with a range of challenges.
‍

Before we delve into the challenges, let’s briefly explore the typical setup of the ground segment and the software used for mission operations.

If your satellite mission is providing a service or data,you’ll want to enable your stakeholders to access that service by allowing them to make requests, such as for observations.

It's crucial to maintain awareness of your mission timeline and orbit, track stakeholder requests, and actively adjust the mission timeline as needed. To facilitate this, you'll integrate a planning and scheduling solution alongside flight dynamics and possibly other elements, such as collision avoidance.

Once you’ve created your plan, it needs to be communicated to the spacecraft – typically through telecommands. This requires integrating a command & control system (MCS) and establishing a ground station network for communication with the space segment. At the same time, you'll receive data, including telemetry and payload data, which must be processed and analyzed. While telemetry is used by operators for satellite maintenance, payload data should be provided to your stakeholders.

To deliver this information, you might integrate a downstream payload processing solution to manage the data generated, whether it’s imagery or service-related information.

The primary goal of operations is to keep this entire process running smoothly. The existence of these building blocks (or systems)is nearly universal, regardless of the type, design, size, or homogeneity of your space system architecture. Yet possibilities for the implementation details are limitless.

In this article, we’ll take a closer look at the MCS.
‍

The MCS is the binding element between your mission planners, or operational decision-makers, and the satellite. Downstream, it serves as the intermediary between the satellite and the controllers who monitor the telemetry data. Depending on the implementation, the MCS handles data reception and separates the telemetry from the payload stream.

In literature, various terms exist, such as Command &Control System and Mission Control System (MCS), but they all essentially refer to the same function. In this article, I use the acronym MCS. The term has evolved historically, originating when mission control was conducted entirely from control rooms, and the processes of spacecraft maintenance and commanding were largely manual.

During the early phases of a satellite mission, the MCS is crucial for accessing satellite data and manually executing procedures. This hands-on approach is essential for ensuring proper operation and addressing any issues.

However, as the mission advances, many processes become automated, leading to a reduced scope for the MCS. In the later mission phases,its responsibilities shift primarily to releasing telecommands and receiving data, as planning and health checks are managed automatically.

In a perfect world for operators, everything in the operational process would run automatically. But getting there means you need to think about a few key things.
‍

So, your challenge is to set-up an MCS for your first satellite that can scale as you deploy your operational constellation. Along the way, you may encounter various obstacles and pitfalls that, if not addressed, could not only make your life miserable but also cost your company significant time and money. 

The space industry is inundated with a variety of communication protocols tailored for different purposes. Some protocols facilitate space-to-ground communication (between satellites and ground control), while others are designed for ground-to-ground communication (e.g. to connect with ground stations). Additionally, there are protocols for integrating various equipment.

On top of that, organizations often need to integrate third-party services, which necessitates dealing with application programming interfaces (APIs) and various interface formats. If your organization is not highly vertically integrated and relies on solutions from multiple vendors,managing these interfaces can generate significant overhead.

In fact, some of our partners have reported that interface engineering constitutes a substantial portion of their efforts within the ground segment.
‍

Another issue you may encounter is the common practice of protocol tailoring. Due to specific technical requirements or the need to achieve certain functionalities, flight software development teams are sometimes compelled to deviate from established standards. Some standards, such as the European ECSS/PUS protocol, even explicitly support these deviations.However, with each deviation comes the need for corresponding adjustments in the ground segment, which can significantly increase your costs.

Even if you adhere to the standards, be prepared for change.Throughout your mission project, you may face evolving technical requirements or shifts in consortium dynamics. These changes might necessitate switching vendors or even overhauling the entire satellite bus and its manufacturer.
‍

Flight and ground software are usually developed in silos.While siloed development has its disadvantages, it’s not necessarily a badthing and can actually be a good practice to help cope with the changes Imentioned earlier. However, it does require productive communication between the teams and an efficient way to exchange information.

In this case, you want the space and ground software teams to share details about the instructions your satellites understand and the telemetry they return. Again, be prepared for the million ways to facilitate this exchange.

In the space industry, there’s a variety of exchange formats for these operational products, often referred to as reference databases or mission information bases. Each has its pros and cons, and sometimes the choice depends on the underlying space-to-ground protocols.

Having multiple exchange formats can create integration challenges for your team. You might face compatibility issues, leading to increased development time and costs. This often requires extra effort to adapt data,which can delay your mission timelines.
‍

Okay! You've settled on your vendors, specified your protocols, and agreed on a policy and format for exchanging your operational products. What else could possibly go wrong?

Well, flight software, telecommand definitions, exchange products, parsers, interfaces – these things don’t just create themselves. That might not seem like a problem at first, but remember that since no uniform solutions exist, these components are often developed over and over for each new mission. And that takes time. Plus, if you have pending interface specifications or TM/TC sets that still need defining, your MCS development and rollout will pretty much hit a standstill.
‍

Now that I have nagged about all these issues, let’s be positive for a change and figure out what we can do about it.
‍

Remember, a variety of communication protocols already exist in the industry. Some may fit your application better than others, and while none might be ideal, many smart people have invested considerable thought into defining them, and each has its justification. So, rather than getting caught up in the quest for the perfect protocol stack, we recommend sticking with the established ones as much as possible.

You will encounter edge cases, but in my experience – and that of my colleagues – it's often much faster to implement a simple, standard,and easily adaptable protocol stack and then build your custom application on top.

Keep in mind that even if a standard or protocol includes elements you don’t need, you’re not obligated to use every aspect of it. The more a standard protocol is embraced by the space community though, the easier it becomes to develop reusable software for it. And that is what ultimately saves you money.
‍

Remember what lies ahead! You’re developing a system for the operations and management of a satellite constellation. Your ground segment is not just a piece of the puzzle – it’s an integral part of a large, complex system. This means your operations design must prove itself alongside your key technology on the spacecraft. Avoid the temptation to build a super-scalable solution for your precursor mission. Instead, focus on understanding the overall system, analyzing operational workflows, and identifying edge cases that you can address later. This foundational knowledge will guide you in selecting the right software stack.

So, what can you do about it? As a ground systems engineer, don’t see yourself merely as the recipient of a satellite. Instead, recognize that you’re an essential part of the entire space systems engineering process. Be proactive in engaging with the decision-making around the space segment. Your insights matter!
‍

Even as a ground systems engineer, your active involvement in selecting your spacecraft bus provider is essential because it is your responsibility to ensure seamless onboarding of the space segment into operations. Choosing the right satellite manufacturer is critical for achieving your mission objectives. Begin by evaluating their track record and industry experience.

When selecting a satellite manufacturer, aim for one that offers solutions that fit well with your needs. Look for systems that integrate smoothly with yours and adhere to industry standards. This will help streamline operations and reduce future hiccups. It's also wise to avoid vendor lock-in by steering clear of proprietary protocols, because otherwise you might run into dependencies that could impede your system scalability. Moreover, you want a manufacturer that provides necessary insights into their systems, as this is crucial for avoiding integration challenges and essential for early operations, commissioning of your technology and handling contingency situations.

Support and communication are also crucial. A manufacturer that maintains open lines of communication throughout the development process can facilitate problem-solving and adjustments as needed.
‍

As I mentioned at the beginning of this article, I’ve been in your shoes as a ground systems engineer, and my colleagues and I have gained a lot of experience working as satellite operators on different missions. If you need support or just want to chat about your ground segment, feel free to reach out.

Having dealt with the challenges I discussed, we decided to create solutions to tackle them head-on. That’s how our satellite operating system, SAT.os, came to be. It’s designed to be the backbone of your operational software system on the ground, offering integrated solutions for command & control, along with various use cases in mission operations.

If you’re facing some of the issues I highlighted in this article, here are a few key features of SAT.os as well as other SAT.IO products that might catch your interest.

· SAT.os has been designed to seamlessly integrate with existing systems, and protocols ensuring compatibility with a wide range of satellite platforms and ground equipment. This minimizes integration challenges and streamlines operations.
‍
· SAT.os has been designed to grow with your operations. It accommodates increasing mission complexity and the addition of new satellites or services without requiring extensive reconfiguration.

· A clear and intuitive graphical user interface enhances user experience, enabling ground systems engineers to efficiently monitor & control satellite operations. Simplified workflows and easy access to essential information reduce training time and errors.

· Our integrated command & control solution offers efficient data handling capabilities, including telemetry reception, storage, processing, and visualization.

· We are also working on advanced data analytics and features that can help you derive actionable insights from telemetry data: e.g. anomaly detection.

· While adhering to industry standards, SAT.os allows for customization to meet specific operational needs without causing vendor lock-in through proprietary protocols. This flexibility ensures that engineers can adapt the system as required, e.g. by deploying custom software stacks on top of SAT.os

· SAT.os facilitates real-time monitoring of satellite health and performance, while also supporting automation of routine tasks. This helps reduce the workload on ground systems engineers and enhances operational efficiency.

· Open and responsive communication with customers and partners is key for SAT.IO. We also provide extensive documentation, and trainings, to ensure engineers can effectively utilize our command &control solutions and resolve any issues that may arise.

· Adhering to recognized industry standards not only enhances interoperability but also builds trust with customers. When you go with SAT.IO system compatibility is one less thing to worry about.
‍

Even as a ground systems engineer, your active involvement in selecting your spacecraft bus provider is essential because it is your responsibility to ensure seamless onboarding of the space segment into operations. Choosing the right satellite manufacturer is critical for achieving your mission objectives. Begin by evaluating their track record and industry experience.

When selecting a satellite manufacturer, aim for one that offers solutions that fit well with your needs. Look for systems that integrate smoothly with yours and adhere to industry standards. This will help streamline operations and reduce future hiccups. It's also wise to avoid vendor lock-in by steering clear of proprietary protocols, because otherwise you might run into dependencies that could impede your system scalability. Moreover, you want a manufacturer that provides necessary insights into their systems, as this is crucial for avoiding integration challenges and essential for early operations, commissioning of your technology and handling contingency situations.

Support and communication are also crucial. A manufacturer that maintains open lines of communication throughout the development process can facilitate problem-solving and adjustments as needed.
‍