In our previous blog post, we explored how planning algorithms help reduce latency by optimizing imaging schedules and ground station usage.
But as soon as a plan reaches the satellite, another challenge begins: how do you execute the plan as quickly, reliably and flexibly as possible?
This is where flight software comes in.
In this blog post, we take a closer look at:
What flight software does
How software and hardware work together to reduce latency
The physical limits software still has to work around
Why onboard autonomy is becoming increasingly important
Flight software is the software running onboard the satellite itself. It controls nearly every aspect of the satellite’s operation, including maneuvering, image acquisition, onboard data handling, and downlink.
For the most part, the software does not act autonomously. Instead, it executes commands contained in task plans that are uploaded to the satellite during ground station contact.
At ICEYE, our flight software is primarily developed in-house. This gives our engineering teams tight control over performance, reliability, and how quickly new capabilities can be introduced across the fleet.
When it comes to tackling latency, software and hardware are closely intertwined.
Each new generation of satellites introduces new physical capabilities, but those capabilities only become operationally useful when the software fully supports them.
Earlier ICEYE satellite generations, for example, used fixed antennas. This meant the satellite had to physically orient toward either the target area (for SAR image acquisition) or the ground station (for X-band downlink). It could not do both simultaneously. As a result, planning algorithms had to decide whether imaging or downlinking should take priority during any given window.
That changed with our Gen 3.5 satellites. These have a mechanical arm, which allows the communications antenna to point toward a ground station while the satellite body points elsewhere for imaging. This enables simultaneous image acquisition and downlink – an important capability for tactical users who need imagery delivered as quickly as possible after capture.
The hardware created the possibility. The flight software turned it into an operational capability.
Historically, onboard satellite software was treated as relatively fixed after launch. At ICEYE, we take a far more iterative approach. Our development cycle includes:
Daily automated testing
Weekly deployments to test satellites
Monthly production releases across the fleet
This allows us to continuously improve satellite performance after deployment. In some cases, capabilities that did not fully exist at launch become operational months later through software updates alone.
Sometimes software updates do more than optimize performance – they fundamentally change what a satellite can do.
We recently helped a customer operating two older ICEYE satellites upgrade to the latest version of our operating system. Previously, each satellite could acquire three images per day. Following the update, which gives access to Multi-Spot imaging mode, they can now acquire around 100 images at the same three passes.
Same asset. Same satellite. Same hardware. Just updated software.
Figure 2 (below) illustrates Multi-Spot image acquisition mode from two angles: the left-hand animation shows how mechanical pointing and electronic steering work together, while the right-hand animation shows the same process from the perspective of the satellite's orbit geometry. Learn more about Multi-Spot acquisition in our Beyond the Echo - How satellites steer the radar beam blog post.
Despite advances in onboard software, some constraints remain fundamentally physical.
Power and thermal management are two of the biggest limiting factors affecting SAR imaging capacity today. Unlike optical satellites, SAR satellites use active sensors that are very power hungry (in telemetry, you can see the battery charge drop significantly after each acquisition). Long imaging sessions also generate heat within the radar antenna and can increase the temperature of other critical components through solar exposure.
Dynamic attitude control, which we're now introducing, will autonomously optimize satellite orientation for thermal management, power generation, or both. This extends usable imaging time within each 90-minute orbit, with zero hardware change, and works out to a 50% increase in usable imaging time per satellite per day.
Across the fleet, that's a real jump in tasking capacity and shorter wait times for customers.
Today, ICEYE satellites still operate largely according to pre-planned timelines. In the future, we are looking to increase onboard autonomy so they can respond more intelligently to events as they unfold.
Let’s say a satellite fails to capture a high-priority image. In a fully pre-planned system, the software continues with the scheduled downlink, even though no usable image exists. Autonomous software, however, could recognize the capture had failed and choose to downlink another image instead, helping to clear the onboard backlog and use the ground station pass more efficiently.
Adding this level of operational autonomy improves overall responsiveness and helps reduce delays caused by unexpected disruptions.
One of the biggest remaining limitations on insight delivery speed is the intermittent nature of ground station connectivity.
Unlike communication satellites, which remain positioned above the same location on Earth, ICEYE satellites operate in sun-synchronous low Earth orbit, circling the planet roughly every 90 minutes at an altitude of 500-600 kilometers.
This means we do not have continuous access to our satellites but instead have to wait until a satellite is flying over a ground station before we can upload the plan.
Let’s imagine we want an image of Helsinki. Not only does a satellite need to pass over the target area, but it must also already have received the imaging task during an earlier ground station contact.
Now imagine instead that satellites could communicate continuously with one another.
In this scenario, a task could be uploaded to whichever satellite passed over a ground station first and then relayed through the constellation to the satellite best positioned to execute the acquisition.
This would have a major impact on latency reduction, extending the same 15-minute turnaround we can already achieve today to nearly any point on Earth, at any time.
Our hardware teams are actively evaluating inter-satellite communication capabilities for future generations, a capability that could unlock even faster tasking across the fleet. A truly exciting prospect!
As we have seen throughout this series, latency reduction is not the result of a single breakthrough, but of continuous improvements across the entire system. Flight software is central to that improvement process – unlocking new capabilities, maximizing hardware performance, and increasingly enabling satellites to adapt in real time.
As onboard autonomy, thermal optimization, and future technologies such as inter-satellite communication continue to evolve, software will play an even greater role in shortening the path from tasking to insight. The smarter the satellite becomes, the faster the system gets.