This article discusses the role of automation in satellite missions and discusses how it can build more powerful and versatile constellations.
It covers the benefits that automation brings, the trade-offs of using it, advice on implementing solutions, and the knock-on impacts.
The article was developed in collaboration with Terma, a Denmark-based provider of technology and services for extreme, mission-critical environments and situations, including electronics and software for space.
Terma is a satsearch Trusted Supplier and insights from the company were provided by Mario Monaldi, Director of Business Development and Sales in the New Space & Defense division.
Mario has a breadth of expertise in the space industry, both commercially and in support of the European Space Agency (ESA). His project work included a major role in the definition of the operations of the Columbus module of the International Space Station (ISS) as well as supporting space initiatives across Europe in the Middle East.
Understanding automation in space missions
Whether for routine maintenance checks onboard the International Space Station (ISS), in the imagery processing chain of a Low Earth Orbit (LEO) constellation, or to enhance the navigation of a deep space probe, automation plays many roles in space – the nature of the operating domain requires it.
It essentially refers to pre-programmed processes performed without a human-in-the-loop. Automated procedures may begin with human activation (e.g. via a Spacecraft Controller’s command) or with automatic triggers due to input from onboard sensors, timing, or through other onboard functions.
Such processes are crucial for mission success. It isn’t possible to physically access a satellite in orbit of course, and when a spacecraft is out of ground station range, it can’t be accessed via radio or optical signal either. If some aspects of the key activities weren’t automated, space missions would be much less productive.
In recent years there have been a number of new capabilities brought to market designed to make it easier to automate mission processes, both in space and on the ground. There are also a number of factors driving growing interest in automation, including the development of more constellations.
A constellation has several unique and more complex challenges compared to a single satellite mission, as discussed further below. These dictate a much larger role for automation in operations – both to improve efficiency and to open up new capabilities.
Automation vs. autonomy
Automation and autonomy in space missions are not exactly the same.
Automation is the ability of the system to carry out rigid, set tasks when commanded or prompted to do so.
Autonomy is when a system is capable of making decisions and determining, and performing, its own commands. Autonomous systems have the capability to reach specific goals or objectives, and a level of freedom to determine the approach.
In this article we will be primarily focussing on automation, as this is much more widely used.
Why constellations need automation
A satellite constellation is a complex system to coordinate. Managing ground station passes, the data processing chain, and maximizing reliability and efficiency at the same time is difficult, and the complexity grows with the number of satellites.
However, even relatively “small” constellations have complicated operations, depending on the service they provide. Galileo, for example, is made up of 27 currently operational satellites connected to 2 main ground control centres and a global network of additional stations. All key mission communication, such as Telemetry, Tracking, and Command (TT&C), must be scheduled and configured for each satellite and ground station.
As a global navigation system, the Galileo service needs to remain online with minimal disruptions. Automation plays an important role in this, reducing both the number of human errors and the amount of operator time it takes to manage.
When operators send manual commands to a satellite there is always a risk of failure or error. Automated routines send commands faster and fail less often.
They are also unaffected by project pressure – which is something that Terma has observed in many missions. When a situation goes wrong or expectations change, the performance of some human operators can be impaired, while automated processes will run as normal.
The operating orbit can also provide challenges. LEO satellites, for example, have many short passes per day and automation is needed to get the maximum value from such limited communication (more on this below).
A key challenge is to rapidly configure satellite communications to access compatible ground stations. This might require pointing antennas, with the right elevation and azimuth data, to initiate program tracking and then moving to auto-tracking. If anything changes in this process the operator must quickly re-configure in real time. Such protocols should ideally be automated.
Note that many operators won’t care exactly which ground station or satellite a particular set of data comes from, provided it is accurate and valuable. So a LEO constellation can usually be heavily automated without any issues.
Another reason that constellations need automation is encryption. In today’s industry most satellite data is encrypted before downlinking. And a constellation capturing a high volume of data will need some automation to handle this – usually the automated management of encryption keys.
Finally, one the biggest drivers of automation is simply the increase in satellites in orbit. Whether it is the Starlink or OneWeb LEO mega constellations, the geostationary orbit (GEO) navigation systems, or more advanced LEO-GEO hybrid services (such as those proposed for next-generation Positioning, Navigation and Timing (PNT) solutions); there are already thousands of satellites in orbit and many more on the way.
Resolving and decreasing human error and efficiency is going to be very important in such busy environments. However, automated processes are not a panacea for space missions, nor are they even needed in certain circumstances. The decision to automate must always be driven by the mission concept of operations.
The critical importance of the mission’s ConOps
A space mission’s concept of operations (ConOps) should be the driving force behind many decisions during constellation development and scaling. And the extent to which automation is incorporated, and how it should be used, are two of the most important.
A single satellite team is usually more reluctant to extensively use automation. Their operations are nowhere near as complicated as with multiple satellites and the nature of the mission typically means that the team likes to be in full control at all times.
For example, technology demonstrations (such as an in-orbit demonstration (IOD) or verification (IOV) missions) and scientific missions typically have ConOps that don’t require a lot of automation. In such projects all aspects of the satellite’s data, from status reports to captured images, are manually reviewed both to maintain control and to build the team’s expertise.
But for constellations, decisions on deploying automation should depend on how the operators plan to run the mission. For example:
GEO missions – in GEO you have constant visibility and no communications delay – so automation is usually only used for routine processes.
LEO missions – LEO satellites perform several passes per day, each around 5-15 minutes. In this case operations need to be carefully pre-planned. The possibility to react in real time is limited and the operating team can usually only fix issues in the next pass after they are identified. Automation can play many roles in this – more on this below.
Deep space – for deeper space and exploratory missions operators face major time delays, so automation is necessary for many operations. However, such missions don’t usually produce revenue-generating data at high rates, compared to Earth Observation (EO) services in LEO for example, so certain processes can remain manual.
Scientific, technology demonstration, and public service missions – in such missions the operation of the satellite is usually fundamental to the objectives, so stakeholders will expect to maintain much more manual control. The preferences of end-users are also important. In Copernicus, for example, data is used by an extensive user community, many of whom would be reluctant to see much greater automation in operations.
As you can see, the standout mission format for automated procedures is in a LEO constellation.
Automation in LEO constellation operations
Here are some of the factors to take into account when assessing the potential for automation in a LEO constellation, as determined by the ConOps:
- Such missions might see 14 – 16 passes a day, per satellite, lasting around 5-15 minutes usually. If data isn’t collected in every pass (perhaps to save money on the ground segment) then some satellites will need to store it for a period.
- This will require systems to have more memory onboard, meaning there might be a mass budget increase.
- Operators will also need to plan for what happens if a satellite or a pass is then missed and the data not downlinked. Will the data be lost? Will the next collection phase overwrite it? If it is to be kept, how and when will it then be processed and downlinked?
- Automating the correct configuration of technology and operations, in space and on the ground, needs to begin early. And it can affect actual spacecraft design.
- Inter-satellite links (ISL) require automation as manual control of both systems is difficult. ISL capabilities can also enable automation as they provide the ability to perform data exchange between systems in such processes.
- Collision avoidance is an important, and growing, area, particularly for satellites in mega constellations, and automation plays a key role in this.
- When communications satellites are considered, there is a different situation than EO or remote sensing missions as service contracts require minimal interruption or loss of service. Automation plans should therefore be built with this in mind.
In addition, one of the biggest operational challenges in a LEO constellation is how satellite ‘safe mode’ is defined and treated.
The balance of operating in safe mode
Most satellites are designed with a safe mode. This is a control law in the sensors that makes the system inert (and not collecting data) if contact is lost, or due to some other event, so that it is kept safe. This is all enabled through automation, of course.
For missions near Earth this is typically sun pointing, so that the system maintains power. For missions further into space the safe mode might make the spacecraft Earth pointing to re-establish contact.
For many operators the concept of ‘safe mode’ is a little taboo. Spacecraft operational teams want to maintain control of their satellites, even when there is a serious error.
However, if operators can consider safe mode as simply another operational mode, using it can be more acceptable. Mission designers need to consider not just their optimal plans but contingencies as a result of onboard failures or external interference.
And, again, use of safe mode will depend primarily on mission ConOps.
If the ConOps can incorporate a lower data return for a certain period, while still being within performance limits, then it is possible to spend some time inert in order to fix issues or conserve resources. In a large constellation you can then accept having some systems in safe mode as there are lots of satellites and the service will still be delivered as needed.
Handling safe mode in ConOps is a prime example of the operational trade-offs that can occur when utilizing automation. The decision whether to incorporate artificial intelligence (AI) capabilities is another.
The impact of AI
Artificial intelligence is changing many fields and industries. This is certainly true of the space industry where AI and machine learning (ML) are being used in operations in several areas, from data processing to optimizing communications.
This is an area that Terma is actively investigating and incorporating into existing solutions where relevant.
Where automation is concerned, AI can act as an extension of rigid, automated procedures, providing additional capabilities to operators.
But it can also be used to replace such procedures, by utilizing large language models (LLMs), or neural networks which can achieve a result without requiring a specified process to reach it. This approach is less established in the space industry, though there are movements in this direction.
However, incorporating any AI-based solution requires overcoming two key issues:
- Accessing enough data for effective training
- Understanding the impact on the fault tree
Both of these issues become relevant in the event of a problem with the mission. For any anomaly the operating team reviews historical data to look for similar event detections, conditions, or correlating effects. But it is very difficult to get enough training data that is relevant to your mission and technologies.
In addition, understanding the root of an error is complicated when AI is used. The fault tree for prescribed manual processes is well-known, and analysis can usually determine where an error occurred quite rapidly.
However, when a neural net is employed, the fault tree can be indeterminate. The full route taken by the AI system to reach a certain conclusion was not specified in advance and so deconstructing the issue can actually take a lot of manual work by the operating team.
In spite of these drawbacks AI will certainly be integrated into more and more missions, to some extent, moving forwards and space organizations will need to continue to get to grips with it. And one area where the impacts (of both automation in general and AI in particular) could be most keenly felt are in staffing a project or service.
The role of the human in, and out, of the loop
Decisions about implementing automation can affect both the size of the required operating team and the duties assigned to them. Space missions will still require various human operators for the foreseeable future, with many flagship projects utilizing a 24/7 flight controller.
But Terma does expect the current definition of a flight control team to change. In the most extreme scenario, Mario shared that he has been a part of conversations over several years about the concept of the ‘lights out control room.’
This is an operating paradigm in which the satellite’s control is almost entirely automated and can all be handled remotely, by very few staff, and in normal office hours. This approach is already used in missions where a high data return or continuity of service are not major requirements, such as ESA’s PROBA missions. However, larger and more complex missions tend to use more conservative setups, although teams can save money and time on both personnel and facilities by using more automation.
A typical space mission can last for several years and staffing a full operations team, 24/7, for such a period is expensive. It can also limit company development opportunities or even affect mergers and acquisitions (M&A) potential as it is a sunk cost that needs to be borne for the mission duration.
But the level of adoption of automation, and subsequent replacement of human operators, will always vary from mission to mission, being dependent on the service requirements, end-user expectations, and attitudes to risk. This issue is discussed in many other fields where automation, AI, and similar innovations are being introduced, such as transport or healthcare for instance.
In the aviation industry we have seen such a shift occur over several years. As flight technology has become more advanced and automated, airline pilots have moved from manually flying planes to more of a flight supervisor status. They must still undergo rigorous training in order to take over if the automated system fails, but the vast majority of flights are handled primarily by the system, not the operator.
Altering how mission operations teams work may also require changing the service level delivered, so it is important that customers can accept the results. For example, if the constellation was to have manual oversight 9-5, 7 days a week, and then be automated at other times, end-users would need to understand that an issue occurring at 5am on a Saturday would not get fixed until Monday morning.
In conclusion, when balancing the roles of people and automation, we come across a number of trade-offs. And, as you know, this is the case for every aspect of a space mission in which automation can be used.
Implementing automation and handling trade-offs
If the information shared in this article so far has motivated your team to assess automation options for your next mission, here are some useful pointers on implementing solutions and handling the trade-offs that will occur.
Build to meet objectives, not just satisfy technical requirements – a space mission should begin with a proper analysis of what you want to achieve and how you want to achieve it. Engineers and operators need to understand why you are flying the mission in order to give the best advice at each stage.
Involve operations early – the personnel in charge of operating the mission can add a lot of value during planning. Their insights can help determine the optimal spacecraft design and the ground segment requirements. This could involve defining mass memory requirements, for example, or using more advanced solutions for fault detection, isolation, and recovery (FDIR).
Consider the full mission lifetime – if you can identify areas early on that require automation, then you can actually plan for it. It can become more expensive to change the mission plans and technology later to incorporate it, and automation itself will usually save money and time in operations for the entire mission lifetime.
Factor in wider business needs – as mentioned previously, staffing a mission for several years is a major investment of money, people, and resources, and it is a decision that can impact how the wider business can develop in years to come. Ensure these decisions are assessed in the early stages.
Follow a process-driven approach – successful automation relies on robust processes that need to be specified in advance. While this may take some extra time in development, the efficiency savings that come from the resulting automation, and the ability to optimize processes that are now fully understood at a granular level, will usually outweigh this work.
Increased complexity – be aware that there may be some additional engineering or software development work required to incorporate an automated solution. In the majority of cases this extra investment would also be offset during operations.
Understanding and dealing with such trade-offs is an important part of assessing whether an automated solution is suitable for any mission. And working with an experienced provider can help shortcut these processes significantly.
Automation solutions provided by Terma
For more than 40 years Terma has offered a range of space mission solutions that enable mission teams to efficiently incorporate automation in their missions and services.
Today, these systems offer a scalable and flexible suite of tools to run an entire mission, known as the Terma Ground Segment Suite (TGSS).
At the links below you can find more information on the different tools available in Terma’s TGSS:
The Terma TRACK product enhances space mission management with precise, real-time orbit visualization and analysis for spacecraft and fleets, incorporating dynamic 3D and flat maps, terrain data, and solar system views.
Request quote 
request info
The Terma Spacecraft Control System – Operations and/or AIT (CCS5) is a multi-user operation and testing product designed for space applications. The CCS5 can be used for all phases of operations - from preparation and launch to routine operations. It can be also used as the central part of an EGSE for assembly and integration testing (AIT/AIV). The single-user version of CCS5 is called TSC and can be used for a variety of purposes including instrument and payload testing.
The Terma TEMU system is a high-performance emulator specialized in simulating a range of (multi-core) processors commonly deployed in European spacecraft. This versatile flight processor emulator supports a broad array of architectures including ERC32, LEON2, LEON3, LEON4, P2020 and ARM.
The Terma ORBIT product, leveraging the Terma Flight Dynamics library and an extension of Orekit, offers advanced support for Flight Dynamics across missions from LEO to GEO.
STAMP streamlines thermal testing by offering a robust system for data acquisition, visualization, and management, designed to support extensive thermal test campaigns. It stands out for its reliability, adaptability, and ease of use, coupled with advanced presentation features that enhance collaboration among sizable teams of operators and clients.
Terma's STAT is a sophisticated software product for the efficient archiving and analysis of spacecraft data. It serves as a central archive for telemetry and event data, ready for mission operations and AIT, and is scalable for constellations.
Terma's TSC - Spacecraft Test Software is a simplified and streamlined version of the company's CCS5 system, designed for single user processes in several areas such as payload testing.
The TSC system enables space mission operators to quickly and easily set up automated spacecraft testing routines to enhance mission performance, for a single spacecraft.
uNIS serves as the crucial interface linking the Spacecraft Control System with Ground Stations, facilitating the exchange of Telemetry and Telecommands via CCSDS Space Link Extension services (SLE). Additionally, it plays a pivotal role in ground testing scenarios, connecting the primary test system with Telemetry/Telecommand Front-end Equipment and ensuring interoperability through CCSDS Space Link protocols and ground station interfaces.
PLAN, integral to the Terma Ground Segment Suite, automates and optimizes mission schedules for satellite fleets, aligning tasks with key events to pinpoint ideal operational windows. With capabilities for manual adjustments and seamless integration with CCS5, its AutoPilot function executes scheduled tasks autonomously, ensuring timely and efficient mission control.
Conclusion
In Mario’s words; in operations there is a saying; if it ain’t broke, don’t touch it. And this conservative approach is how many engineers have assessed automation for a space mission in years past.
However, it’s no longer sufficient in the modern industry. Your competitors are continually optimizing and accelerating their mission development timelines and creating more powerful satellites with higher data throughput, through automation.
At the same time, demand for space services is growing globally while the actual operating environment in LEO is becoming more congested and complex. These changes also have regulatory impacts for missions at all levels.
Yes, automation is a change in the operational paradigm – with knock-on impacts for how missions are developed and the role of humans in their management.
However, the opportunities on offer, to reduce the overall cost per mission while achieving higher rates of performance and value generation, are significant.
So ensure that you properly assess the potential for incorporating more automation in your next project. And feel free to reach out to Terma if you would like to discuss how to achieve this.