N/A

The work of Johan Östman was funded by Vinnova under grant 2020-04825 and the
work of Vinutha Magal Shreenath under Vinnova grant 2021-03643.

Corresponding author: Pablo Gómez (e-mail: pablo.gomez@esa.int).

# PAseos Simulates the Environment for Operating multiple Spacecraft

PABLO GÓMEZ1,2  JOHAN ÖSTMAN2  VINUTHA MAGAL SHREENATH2  AND GABRIELE MEONI2,3
Advanced Concepts Team, European Space Agency, European Space Research and
Technology Centre (ESTEC), Keplerlaan 1, 2201 AZ Noordwijk, The Netherlands
(e-mail<EMAIL_ADDRESS> AI Sweden, Lindholmspiren 11, 417 56 Göteborg,
Sweden (e-mail<EMAIL_ADDRESS><EMAIL_ADDRESS> $\Phi$-Lab, European Space
Agency, ESA Centre for Earth Observation (ESRIN), Via Galileo Galilei 1,
Frascati (00044), RM, Italy (e-mail<EMAIL_ADDRESS>
###### Abstract

The next generation of spacecraft is anticipated to enable various new
applications involving onboard processing, machine learning and decentralised
operational scenarios. Even though many of these have been previously proposed
and evaluated, the operational constraints of real mission scenarios are often
either not considered or only rudimentary.

Here, we present an open-source Python module called PASEOS that is capable of
modelling operational scenarios involving one or multiple spacecraft. It
considers several physical phenomena including thermal, power, bandwidth and
communications constraints as well as the impact of radiation on spacecraft.
PASEOS can be run both as a high-performance-oriented numerical simulation
and/or in a real-time mode directly on edge hardware. We demonstrate these
capabilities in three scenarios, one in real-time simulation on a Unibap iX-10
100 satellite processor, another in a simulation modelling an entire
constellation performing tasks over several hours and one training a machine
learning model in a decentralised setting. While we demonstrate tasks in Earth
orbit, PASEOS is conceptually designed to allow deep space scenarios as well.

Our results show that PASEOS can model the described scenarios efficiently and
thus provide insight into operational considerations. We show this in terms of
runtime and overhead as well as by investigating the modelled temperature,
battery status and communication windows of a constellation. By running PASEOS
on an actual satellite processor, we showcase how PASEOS can be directly
included in hardware demonstrators for future missions.

Overall, we provide the first solution to holistically model the physical
constraints spacecraft encounter in Earth orbit and beyond. The PASEOS module
is available open-source online together with an extensive documentation to
enable researchers to quickly incorporate it in their studies.

###### Index Terms:

computational modeling, distributed computing, edge computing, onboard machine
learning, spacecraft operations, satellite constellations

=-21pt

##  I Introduction

The last two decades have been characterized by significant changes in the
availability, types, and usage of spacecraft, especially satellites in Earth
orbit and beyond [1, 2]. Miniaturization has enabled operating satellites on
the scale of centimeters with just a few kilograms of mass [3]. At the same
time, the cost of launching satellites has plummeted, which opens up various
new applications for both private and public actors [4]. Furthermore, with the
advent of constellations for Earth Observation and with the increased
availability of computation, tools to deal with, e.g., scale, complexity, and
coordination of such distributed systems in space are required.

Many of the anticipated future applications are related to data processing and
transmission [1, 5]. Indeed, with the rise of artificial intelligence methods
in virtually all domains, the next generation of satellites is likely to be
equipped with novel tools and hardware [6] to enable machine learning methods
and other technological innovations such as inter-satellite links (ISL) [7].
To this end, a growing corpus of research has been exploring novel
applications suitable for this new paradigm, ranging from machine learning
applications in remote sensing [8, 9] to federated learning in low-Earth orbit
(LEO) constellations [10, 11]. However, there are fundamental constraints in
the operations of LEO satellites related to, e.g., short communication windows
with ground stations (resulting in large latencies and poor availability)
[12], temperature, radiation, and power budgets [13]. In addition to a hostile
environment, other challenges include increased hardware complexity, and
absence of a communication network [14]. Similar constraints exist beyond LEO
and, thus, for robust and realistic scenario planning, it is necessary to
properly consider them already both in algorithmic design and the
demonstration of space applications. Specialized simulation tools exist for
many aspects of onboard operation, such as communications [15, 16] or orbital
dynamics [17], but there is a lack of holistic simulation of the environment.

Here, we present an open-source software tool called PASEOS that is dedicated
to realistic modelling of various constraints induced by the harsh environment
of space. PASEOS is based on a modular design and is compatible with existing
code in both discrete-event and time-based simulations. It supports a variety
of scenarios ranging from modelling individual satellites to large-scale
constellations. It can be run like a classical numerical simulation minimizing
time-to-solution or in a real-time mode based on a clock, e.g., the system
clock the hardware is running on. PASEOS is implemented in Python and is
completely agnostic to any machine learning frameworks, such as PyTorch [18]
or TensorFlow [19], or even the specific application. In this work, we
describe the system design and mathematical modelling inside of PASEOS.
Further, we demonstrate its capabilities on three applications. First, by
using actual satellite hardware (Unibap iX-10 100 satellite processor), we
demonstrate real-time modelling of onboard detection of volcanic eruptions
using a single satellite. Second, we model the operational behavior and
constraints of a large LEO constellation limited by thermal, power and
communication constraints. In the final example, we demonstrate a fully
decentralized machine learning application on two satellites modelled with
PASEOS using heterogeneous data.

PASEOS source code is open-source available
online.111https://github.com/aidotse/PASEOS We hope to inspire and enable a
broad variety of follow-up research by making PASEOS modular, user-friendly
and efficient. Thus, the contributions of this work are:

  * •

Creation of the open-source Python framework PASEOS to model the impact of
constraints imposed by the space environment

  * •

Demonstration that the framework can be used in a wide range of scenarios
including operations on actual satellite hardware for real-time
implementations, for modelling constellations, and to study distributed
machine learning approaches

  * •

Detailed analysis of the runtime overhead of PASEOS models in a scenario
studying the detection of volcano eruptions on Unibap iX-10 100 processors

  * •

Demonstration of the direct impact operational constraints can have on machine
learning methods due to power budgets and communication windows

##  II Methods

This section describes the physical models implemented in PASEOS as well as
some of the design considerations. In the following, any type of device,
vehicle or similar, modelled in PASEOS, will be referred to as an actor.

###  II-A Modelling of Spacecraft Constraints

Operating spacecraft poses vastly different challenges than operating any type
of vehicle or asset on Earth [20, 12, 21]. Here, we briefly outline the
constraints considered by PASEOS and how they are modelled. Overall, PASEOS
aims to strike a compromise between computational complexity and physical
fidelity that enables it to be run in parallel to perform an operation, e.g.,
the training of a neural network, and yet still account for various
constraints on different hardware devices, including embedded systems.

Overall, both physical constraints, such as thermal management or the
availability of communication links, as well as operational constraints, such
as per-user allocated time slots in missions, can be modelled with PASEOS. An
overview of the modelled constraints can be found in Fig. 1. In this section,
most constraints are explained in relation to orbits around Earth. They
translate, however, to other scenario, such as orbits around other celestial
bodies or deep space missions.

Figure 1: Overview of the constraints modelled in PASEOS

####  II-A1 Astrodynamics Modelling

Many of the following constraints depend on the exact ephimerides, i.e.,
positions and velocities, of the spacecraft and relevant celestial bodies,
such as the Sun or the body the spacecraft may be orbiting. In PASEOS, we
assume each actor to have a central body that it is gravitationally bound to,
e.g., the Earth or the Sun. In its current version 0.1.2, PASEOS uses pykep
[22] to model Keplerian orbits around the central body. The JPL low-precision
ephemerides222https://esa.github.io/pykep/documentation/planets.html#pykep.planet.jpl_lp
Accessed: 2023-01-31 are used to model the position of the Earth and Sun. Even
though we focus on simple Keplerian orbits in this work, it is conceivable to
employ more complex dynamics models ranging from propagators such as SGP4 [23]
to high-fidelity modelling through orekit [17]. All positions and velocities
in PASEOS are modelled in the inertial frame of the central body.

####  II-A2 Communication Windows

One of the central constraints in spacecraft operations, especially in LEO,
are communication windows during which a spacecraft is able to communicate
with ground stations on Earth or with other spacecraft. In practice, these
windows can depend on a large variety of factors such as the type of
communication channel (e.g. optical, radio), environmental factors, such as
atmospheric conditions, and others [24].

In PASEOS, we consider communications to be limited by visibility. For
simplicity and computational efficiency, the version 0.1.2 considers only this
constraint for communication between spacecraft. Thus, it is computed whether
the sphere bounding the central body is obstructing the view between actors.
For the availability of a ground link between a spacecraft and ground station,
we utilize the Skyfield Python module [25] to compute the angle of a
spacecraft above the horizon. Further, Skyfield is also used to account for
ground stations’ movement due to the Earth’s rotation. Ground stations on
other celestial bodies are not yet supported. Thus, based on these
assumptions, PASEOS can be used to compute the availability and duration of
communication windows between actors.

####  II-A3 Data Transmission Rate and the Communication Channel

Aside from the availability of a communication link, a second factor for data
transmission is related to the effects of the communication channel, that
affect the effective data transmission rate available for the user and impact
the quality of data transmitted. Especially optical links from satellites in
orbit around Earth to ground are highly dependent on atmospheric conditions
[26, 24]. Similarly, space weather events like coronal mass ejections or solar
flares, e.g., can impact transmissions to Earth [27]. These effects can
introduce errors in the communication, which could lead to re-transmissions of
data packets or require additional data redundancy, which impact the effective
downlink data rate available to the user. Additionally, other factors such as
the used transmission modulation, channel encoding strategy, and need for
pilot synchronization play a significant role on the effective user
transmission data rate [28].

However, high-fidelity modelling of these factors can be tremendously complex
requiring dedicated simulation software, such as ns-3 or OMNeT++ [16, 15]. In
the long term, PASEOS may possibly provide interfaces for these packages. For
the moment, however, users are required to manually specify an average data
transmission rate to be considered for computing required transmission times,
which is considered constant and, within PASEOS, independent of the distance
between the actors and the communication link.

####  II-A4 Power Budgets

Another constraint relevant for all kinds of space missions are the available
power budget and power systems [12, 29].

Near the Sun and inner planets, spacecraft typically rely on solar power and
batteries. Further out, spacecraft rely on radioisotope thermometric
generators [30]. Land-based assets such as rovers typically also rely on
either of these methods.

We assume spacecraft to have a battery with a fixed capacity. For simplicity,
we model solar power generation in PASEOS as an increase in the battery’s
state of charge (SoC) at a constant rate while a spacecraft is not in the
eclipse of the central body relative to the Sun. For ground-based actors,
power budget is currently not considered as we are focusing mostly on Earth-
based ground segments. However, modelling of ground-based assets’ power
budgets can follow analogously to spacecraft if, e.g., rover operations are
modelled.

The SoC is reduced through the spacecraft activities, which—in the context of
PASEOS—are user-defined operations that consume charge at a constant rate
during operations.

####  II-A5 Thermal Management

Another critical constraint on the activities a spacecraft can perform is
posed by managing the spacecraft’s temperature, both in terms of low and high
temperatures. Spacecraft hardware will typically have a limited operational
and survival range in terms of temperatures [13]. Hence, it is important that
such constraints are respected during any operations the spacecraft performs.
Due to the surrounding near-vacuum, heat dissipation is typically a major
concern. However, low temperatures can also pose problems, especially when the
spacecraft is in the central body’s eclipse or deep space. Therefore, it is
necessary to rely on a thermal model to anticipate and prevent violation of
these constraints.

In PASEOS, we rely on a formulation similar to the one described by Martínez
[31]. We model the change in the spacecraft’s temperature $T$ as

$mc\frac{\Delta T}{\Delta
t}=\delta_{\mathrm{a}}\dot{Q}_{\mathrm{solar}}+\delta_{\mathrm{a}}\dot{Q}_{\mathrm{albedo}}+\dot{Q}_{\mathrm{IR}}+\dot{Q}_{\mathrm{activity}}-\dot{Q}_{\mathrm{diss}}$
(1)

where $m$ is the spacecraft mass, $c$ its thermal capacity,
$\delta_{\mathrm{a}}=1$ if the spacecraft is in eclipse and 0 otherwise and
the $\dot{Q}$ are heat fluxes. In particular, the individual heat fluxes are
given as

$\dot{Q}_{\mathrm{solar}}=\alpha_{\mathrm{a}}\>E_{\mathrm{s}}\>A_{\mathrm{a,Sun}}$
(2)

where $\dot{Q}_{\mathrm{solar}}$ is the radiative flux produced by the sun,
$\alpha_{s}\in[0,1]$ is the spacecraft solar absorptance, $A_{\mathrm{s,Sun}}$
is the area facing the Sun and $E_{\mathrm{s}}$ the solar irradiance.

$\dot{Q}_{\mathrm{albedo}}=0.5\>\alpha_{\mathrm{a}}\>\rho_{\mathrm{b}}\>E_{\mathrm{s}}\>A_{\mathrm{a,albedo}}$
(3)

where $\dot{Q}_{\mathrm{albedo}}$ is the sun heat flux generated back-
scattered by Earth, $A_{\mathrm{a,albedo}}$ being the area facing the albedo
and $\rho_{\mathrm{b}}$ being the central body’s reflectance. The $0.5$ factor
stems from a simplification as we currently do not compute angles between the
Sun, the central body and spacecraft to reduce computational costs.

$\dot{Q}_{\mathrm{IR}}=\frac{r^{2}_{\mathrm{b}}\>\epsilon_{\mathrm{a}}\>\epsilon_{\mathrm{b}}\>\sigma\>T_{\mathrm{b}}^{4}\>A_{\mathrm{a,b}}}{\bar{r}_{\mathrm{a}}^{2}}$
(4)

where $\dot{Q}_{\mathrm{IR}}$ is the radiative flux due to the Earth black
body emission, $A_{\mathrm{a,b}}$ is the spacecraft area facing the central
body, $\bar{r}_{\mathrm{a}}$ is the spacecraft’s distance to the central body
center, $\epsilon_{\mathrm{a}}\in[0,1]$ the spacecraft’s infrared emissivity
(i.e. absorptance), $\sigma$ the Boltzmann constant and $r_{\mathrm{b}}$,
$\epsilon_{\mathrm{b}}$ and $T_{\mathrm{b}}$ are the central body’s radius,
infrared emissivity and temperature. Furthermore,

$\dot{Q}_{\mathrm{activity}}=\kappa P_{\mathrm{A}}$ (5)

where $\dot{Q}_{\mathrm{activity}}$ is the heat flux from the spacecraft
hardware, $P_{\mathrm{A}}$ is the power consumption rate of an activity $A$
and $\kappa$ is a user-defined parameter describing conversion rate into heat.
And finally,

$\dot{Q}_{\mathrm{diss}}=\epsilon_{\mathrm{b}}\>A_{\mathrm{b}}\>\sigma T^{4}$
(6)

where $\dot{Q}_{\mathrm{diss}}$ is the heat emitted from the spacecraft. While
PASEOS does not enforce consideration of the spacecraft temperature (except
disallowing temperatures below 0K) it enables the user to query the current
temperature and formulate abort conditions based on it.

####  II-A6 Radiation Effects

Another constraint and physical factor to consider are the effects of
radiation, especially beyond LEO, where spacecraft are still fairly protected
by the Earth’s magnetic field [32, 33]. In practice, these events can lead to
data corruption, software faults, or permanent hardware damage [6]. In PASEOS,
we model three different types of effects on operations due to single event
effects (SEEs) [12]:

  * •

Data corruption with a certain probability due to single event upsets. For
that, PASEOS models flipped bits that occurs according to a Poisson-
distribution with a rate $r_{\mathrm{d}}$

  * •

Unexpected software faults leading to a random interruption of activities
following a Poisson distribution with rate $r_{\mathrm{i}}$

  * •

Device failures following a Poisson-distribution with rate $r_{\mathrm{f}}$,
which can be imputed mostly to single event latch-ups

Given the dependence on spacecraft-specific hardware and orbit, the
definitions of these rates are left to the user.

####  II-A7 Operational Constraints

Finally, in addition to the constraints imposed due to physics and the space
environment, missions typically have many objectives and there are various
stakeholders for any spacecraft [34]. Therefore, there are often operational
constraints to be considered that are imposed through the mission profile.
PASEOS enables these by allowing user-defined constraints based on arbitrary
parameters that are evaluated during activities and lead to interruption of
the activity if the constraints are not met. This gives users a broad range of
possibilities ranging from imposing strict hardware limits, such as having to
respect a minimum SoC or certain temperature range, to requiring time limits
or factors outside the PASEOS simulation.

###  II-B Software Design

In the following section, we briefly elaborate on the design philosophy of
PASEOS with regard to user interaction and validation of the models. Even
though we already provide concrete application results in this work, the aim
of PASEOS is to enable a variety of future applications and consequently a
flexible and generic design is paramount.

####  II-B1 Actors

As an abstraction of the variety of different assets available on ground and
in space we simulate them in PASEOS as so-called actors. Fundamentally, we
distinguish between ground-based actors and spacecraft actors. In the current
version, the main feature associated with the former is modelling the change
in position due to the rotation of the central body. For spacecraft actors, a
variety of models can be enabled describing all the physical and operational
aspects described in Sec. II-A. Initially, one only needs to define the type
of actor, a name for it and the current local time of the actor. Depending on
the desired models, additional parameters, e.g. position and velocity for
orbits, need to be specified.

####  II-B2 Activities

Activities are the second central abstraction in PASEOS. They serve to
describe any kind of operation the user wants to model. For example, we may
want our spacecraft actor to capture data with one of its sensors and process
that data. PASEOS allows the specification of an (asynchronous) function that
is executed in the background while PASEOS models the physical constraints.
Further, a constraint function, which is then evaluated repeatedly at a fixed
timestep, can be used to interrupt an activity. For each activity, one has to
specify the power consumption to allow PASEOS to model excess heat and the
change in the battery’s SoC.

Users can either let PASEOS run operations asynchronously to model updates or
run operations and then advance PASEOS’ simulation time.

####  II-B3 Discrete-Event vs. Time-based

One additional challenge for PASEOS is that network-oriented simulations, such
as ns-3 [16] typically focus on providing a discrete-events simulation
allowing users to skip to the next event. Physical simulation modelling
ordinary differential equations, such as the one in Equation 1, however, are
usually solved in a time-based fashion with discrete time-stepping schemes
[35]. In PASEOS, these two simulation paradigms meet as both kinds of
simulations are addressed and part of PASEOS. PASEOS operates at the
intersection of both as it performs numerical simulations of physical
processes while modelling discrete events such as communication windows
becoming available. One can choose a fully real-time operation of PASEOS,
where it will run the physical models asynchronously while performing a user-
defined activity. Alternatively, one can manually ask PASEOS to advance its
simulation state to a specific time interrupted by potential events of
interest to the user occurs.

####  II-B4 Using PASEOS

With the relevant terminology introduced, we can describe the main workflow of
PASEOS. Figure 2 gives an overview of the high-level use of PASEOS. It
fundamentally requires two definition steps where, first, the actors are
modelled and, second, the modelled operations are defined. Operations can then
be performed repeatedly in either the discrete-event or time-based fashion. At
any point of the simulation, the user may benefit from detailed output logs on
actor status and activities (written to a *.csv file) and/or from
visualizations.

Figure 2: Overview of the workflow using PASEOS

####  II-B5 Validation

Given the multitude of physical models in PASEOS as well as the complex
interaction due to asynchronously running activities, a thorough validation of
the software is both critical and challenging. We rely on a comprehensive
suite of automated tests to validate the continued correctness of the
implemented models. In many cases, the tests are based on realistic scenarios,
such as Sentinel-2 communication windows. Test-driven development has been
employed for the design of many of the individual components and no
contributions are merged without code review, appropriate tests, and passed
automated tests. A modular design approach enables testing of individual
components, such as the thermal model or communication links. Further, PASEOS
is available online as an open-source software to enable anyone to provide
feedback and report bugs.

###  II-C Modelling Asynchronous Operations between Multiple Spacecraft

The PASEOS framework may be readily used to model operations involving
multiple actors where each physically modelled actor contains a PASEOS
instance. Note that this setting requires a change of perspective from Fig. 2,
where there is a single actor of interest, to a system-level view where each
actor is to be modelled. PASEOS does not aim to facilitate coordination,
scheduling of activities, or other tasks specific to the modelled application.
Instead, it aims to provide the user with the capability to model different
scenarios, such as intermittent knowledge of other actors and both centralized
(e.g. federated learning) and decentralized (e.g. decentralized learning)
operations. Each actor is assumed to operate independently and any information
about other actors should be acquired during the operation. Operations can
either be performed independently, where the user takes the responsibility to
advance the time of the PASEOS simulation manually, or they can operate in an
asynchronous fashion with event-based activities.

Flexibility is an important design goal of PASEOS, and the user is able to
equip a PASEOS instance with arbitrary capabilities by registering activities,
see Sec. II-B2, consisting of the actions to be performed, the power
consumption, and constraints that must be satisfied for the activity to be
performed. The action and constraint of an activity are coroutines, i.e.,
asynchronous functions, and rely on the asyncio Python module [36]. When an
activity is performed, its action and constraint function are submitted to an
event loop for execution. Meanwhile, PASEOS will monitor and update the
internals of the actor, e.g., temperature and SoC, and advance the time. Note
that PASEOS allows only one activity to be performed simultaneously. Given the
arbitrary code execution inside the activity, a user can, however, perform
different tasks within an activity, e.g. based on the actors state.

To allow for simulation of multiple spacecraft, the ability for the actors to
interact is imperative. In PASEOS, communications are achieved by
encapsulating transmission and reception as activities. Such activities should
be designed to comply with the communication device for the given actor, see
Sec. II-A3, in order for the communication windows to be properly calculated.
For simulation on a single machine, communications may be emulated by simply
imposing a delay (and power consumption) in the corresponding activity.

To use PASEOS directly on edge devices, e.g., spacecraft hardware,
communication activities may be based on packages such as gRPC and zeroMQ to
allow interaction over a network. When working with edge devices, time
synchronization between the actors is paramount for correct operation. As the
actors in PASEOS operate independently, they must make themselves known to
others by, e.g., sending out heartbeats at given intervals containing the id
of the actor and, optionally, metadata, e.g., position and velocity. An actor
may also be unavailable due to low SoC, no line-of-sight connection, or a
device failure. The absence of heartbeats entails the unavailability and other
actors may respond accordingly. PASEOS does not automatically send heartbeats
or check these factors but provides an API to serialize actors for network
transmission and the user to tell each actor about its known and available
peers. Thus, arbitrarily simple or complex connectivity constraints can be
imposed.

If one wants to perform specific operations in a synchronized manner it is
necessary to synchronize actors in time by, e.g., providing a start time for
an activity. Alternatively, time synchronization can be achieved by means of
communication [37]. For example, one may utilize the Network Time Protocol
[38] that relies on a master clock or decentralized approaches that rely on,
e.g., the heartbeats [39].

##  III Results

In this section, the usage of PASEOS is demonstrated for three distinct
modelling scenarios: Earth observation, constellation design, and
decentralized machine learning. The purpose is to illustrate the broad range
of applications that are readily modelled with the aid of PASEOS.

###  III-A Single Actor: Onboard Volcano Detection Onboard Sentinel-2

This experiment showcases how one can use PASEOS in real-time simulations to
emulate satellite onboard-processing scenarios on actual space hardware.

####  III-A1 Setup

We design an experiment in which we register an activity to process satellite
payload data and utilize a constraint function to check the availability of a
link to transmit data to the ground. During the simulation, we profiled our
code on a Unibap iX-10 100 satellite processor [6] to evaluate the overhead of
PASEOS, i.e., the time spent to update the physical models compared to the
time required for checking constraints and running user activities. In
particular, we consider onboard detection of volcanic eruptions applied to
Sentinel-2 L1-C where the acquired data are processed directly onboard a
satellite to spot possible volcanic eruptions and deliver early-alerts to
ground [40, 41].

To set up the orbit of the spacecraft actor we used the ephemerides of the
Sentinel-2B satellite at 2022-10-27T12:30:00Z, which were calculated by using
two-line elements. Because of that, the orbit of our actor is sun-synchronous.
To set up the ground station actor position, we used the European Space Agency
ground station, located at Maspalomas, Gran Canaria (27.7629° latitude,
-15.6338° longitude at an elevation of 205.1m). The ground station link is
available if the satellite is 5° above the horizon. To check for the
possibility to communicate, we used a constraint function that interrupts the
user activity (i.e. the volcanic eruption detection) when the satellite is in
line of sight (LOS) with the ground station.

To have sufficient energy to process data onboard, the actor is equipped with
a 0.162 MJ battery, with a SoC of 1.0 at the beginning of the simulation. We
assume a charging rate of 10 W. Furthermore, to increase the computational
cost due to the update of the physical models in PASEOS and test the system in
the worst case, we also equipped the space actor with a thermal and radiation
model to measure their run time impact. In particular, to avoid effects of
radiation but track computational cost, we set up the rate of data corruption,
restart, and device failure to be 0—this does not affect the computational
cost.

The simulation data consist of three Sentinel-2 L1C post-processed products
showing volcanic eruptions of Etna (2021-08-30), La Palma (2021-09-30), and
Mayon (2018-02-09), provided by Meoni et al. [42] . Each image is produced by
cutting and mosaicing the 20m bands B8A (Near-Infrared) and the B11 and B12
(Short-Wave Infrared) of multiple tiles over the area of the band B8A of the
correspondent Sentinel-2 L0 granule [43]. We artificially extended the
simulation time by repeatedly evaluating the images until we get 100 images in
total for the simulation. In addition, we assumed all data to be already
acquired and available for processing to disregard hardware-related delays
that would occur in reality as we focus here on profiling PASEOS.

Code profiling was performed by using the Python module yappi [44]. In
particular, we measured the Central Processing Unit (CPU) time on the iX-10
100 device for three different values (0.25 s, 0.5 s, 1 s) of the PASEOS
timestep, i.e. the interval time for updating PASEOS, its physical models, and
checking user constraints. We performed three runs for each choice of PASEOS
timestep. During each run, we measured the CPU time for the user activity, to
check user constraints (i.e., check of LOS with the ground station), time to
update PASEOS overall, and the individual times spent to update the radiation,
the thermal, and the battery charge models. Results were averaged over the
three runs for each test case. All the tests were performed sequentially with
two warm-up runs with PASEOS timestep of 1 s.

####  III-A2 Onboard volcanic eruption detection

The detection is based on a simplified implementation of the algorithm [45],
presented in [42], which produces a bounding box surrounding the detected
volcanic eruption and the associated geographical coordinates. Since the aim
of the activity is to provide an early alert to promptly notify and locate a
detected volcanic eruption, a possible alert message will provide the
coordinates of the bounding box center or top-left/bottom-right points. One
example of a detected volcanic eruption on the island La Palma is shown in
Fig. 3.

Figure 3: Detected volcanic eruption on the La Palma (Spain) on 2021-09-30.
The displayed coordinates (longitude, latitude) correspond to the center of
the detected bounding box.

####  III-A3 Results of profiling

Tab. I shows the simulation results for the runs on the iX-10 100 device. In
each test, the activity was interrupted after roughly 29 s of CPU time because
the satellite was found in LOS with the ground station. Indeed, the time to
perform the user activity is similar for each value of the PASEOS timestep,
whilst the time to update PASEOS state and to check the user constraints grow
almost linearly. However, even for the smallest PASEOS timestep, the latter
are respectively 0.43 s and 0.29 s compared to 28.64 s for the user activity.
Overall, PASEOS requires around the 1.45% of the total run time. This
demonstrates that PASEOS is a lightweight solution that can be suitable for
onboard processing use cases on embedded hardware.

As can be seen in Tab. I the time for modelling battery charge is equal to the
one for updating the thermal model. This is because the update of both the
power and the thermal models require checking whether the spacecraft actor is
in eclipse. This operation is carried out only once for both the models and
run time of it is attributed equally to the thermal and power models. All the
other operations to update the battery SoC and thermal models are negligible.

TABLE I: Results of profiling on a Unibap iX-10 100 device for different PASEOS timesteps. Each column reports the CPU time in seconds spent for the user-defined activity, to update the physical models of PASEOS and their individual times. Percentages with respect to the total time are reported in brackets. The last column provides the time spent for the check of the LOS. All in [s](%) | PASEOS timestep
---|---
Type | 0.25 |  0.5 | 1.0
User- defined |  User Activity | 28.64 (97.47) |  28.59 (98.66) | 28.52 (99.27)
LOS Constraint | 0.29 (0.98) |  0.14 (0.50) | 0.072 (0.25)
PASEOS State Update |  SoC | 0.11 (0.39) |  0.062 (0.21) | 0.034 (0.12)
Radiation | 0.0086 (0.029) |  0.0044 (0.015) | 0.0024 (0.008)
Thermal | 0.11 (0.39 |  0.062 (0.21) | 0.034 (0.12)
Other | 0.19 (0.65) |  0.10 (0.34) | 0.056 (0.19)
Subtotal | 0.43 (1.45) |  0.23 (0.79) | 0.13 (0.44)
Total | 29.39 |  28.98 | 28.74

###  III-B Multiple Actors: Communications Modeling of a Constellation

The capabilities of PASEOS to model the operational constraints of managing a
constellation are demonstrated in this test case. Detailed results on the
constellation’s status over time are given and a simple scaling study is
performed to investigate PASEOS scaling abilities to showcase the potential of
modeling large constellations.

####  III-B1 Setup

The scenario investigated here is a LEO constellation consisting of sixteen
spacecraft in a Walker pattern [46] in four planes at 550 km altitude with an
inclination of 10°. Operations of the constellation are modelled for eight
hours—that equals slightly more than five revolutions. The satellites are
presumed to be equally equipped with a 1 MJ battery initially at randomly
uniform SoC between 0.1 and 1.0. Each satellite is equipped with solar panels
charging at 50 W. Satellites are assumed to have a mass of 50 kg, to be at
273.15 K initially and have absorptance of solar and infrared light of 1.0.
The areas facing the Sun and Earth are assumed to each be 2 m². The emissive
(radiating) area is presumed to be 4 m². The thermal capacity is assumed to be
1000 Jkg-1K-1. We assume half of the used wattage for satellite operations to
be converted to heat. The Earth’s temperature is assumed to be 288 K, its
infrared emissivity at 0.6 and its solar reflectance to be 0.3. Solar
irradiance is estimated as 1360 W.

Satellites have two operational modes, one is a standby mode called Standby
where they consume only 2 W and the other one is called Processing where they
consume 100 W. The satellites automatically switch to Standby if their
battery’s SoC falls below 0.2 or their temperature above 330 K.

In addition to the constellation, we monitor availability of communication
links to a satellite in geosynchronous orbit called GeoSat and the European
Space Agency ground station at Maspalomas, Gran Canaria. As for the single
satellite scenario, the ground station link is available if satellites are 5°
above the horizon. The geosynchronous satellite is reachable from the
Maspalomas station.

In PASEOS, we use a time step of 1 s for the thermal and power models.
Satellites decide every 600 s whether they are ready for Processing. If the
constraints for Processing are violated during the 600 s interval, they switch
to Standby for the remainder of the interval.

####  III-B2 Constellation Analysis

We analyze the constellation regarding several operational factors. First off,
in terms of time spent processing. As can be seen in Fig. 4, roughly half of
the satellites are processing at any time, and both battery SoC and
temperature limit the periods of operation. Given the circular LEO orbits of
the constellation, the satellites spend a large time in eclipse with 25 to 50%
of the constellation being in eclipse at any moment. This also influences the
operational temperature—as seen in Fig. 6—of the satellites which rises
quickly at the beginning when a large share begins processing and the
temperature falls especially during eclipse.

Figure 4: Overview of the satellites able to process and in eclipse over time.

Even though PASEOS’ SoC model, for now, is simplistic, complex dynamics for
the power budgets can be observed in Figure 5. Satellites in the constellation
fluctuate between a SoC of 0.2 and 1.0. The low standby consumption of the
Standby activity means they never run the risk of reaching critical SoCs.
Overall, the constellation’s behavior in terms of satellites performing
Processing and the constellation’s temperature and SoC become stable and
cyclic after roughly one orbital revolution.

Figure 5: Battery SoC of the constellation. Different colors indicate
percentage intervals around the median. Figure 6: Temperature of the
constellation. Different colors indicate percentage intervals around the
median.

In terms of communication status, 50 to 75% of the constellation are not
within LOS of either the ground station or satellite in geosynchronous orbit
as can be seen in Figure 7. As the geosynchronous satellite is reachable from
Maspalomas, it is also in LOS of a constellation satellite when the ground
station is.

Figure 7: Overview of the satellites’ communication status over time.

####  III-B3 Performance and Scaling

Running this scenario on a AMD Ryzen-5 consumer-grade CPU on a single thread
requires about 200 s. Time is spent almost exclusively on the physical models
and LOS checks. With 16 satellites, running the simulation for a simulation
time of 600 s requires 8.3 s, 0.52 s per satellite. We investigated the
scaling by increasing the number of satellite per plane. With a constellation
of size 32, 16.4 s were necessary for 600 s simulation time, 0.51 s per
satellite. The better-than-linear scaling is likely due to a constant
initialization overhead in starting the simulation. With 512 satellites, the
600 s required 255.9 s computation time or 0.50 s per satellite. Thus, it is
clear that PASEOS scales well even to a large number of satellites.
Parallelization of these simulations is also trivial given the fully
asynchronous nature of PASEOS that permits parallelization without any concern
for shared memory of similar.

###  III-C Onboard Machine Learning in Orbit

This test demonstrates how PASEOS can be employed to model and monitor
constraints when solving a machine learning task in a decentralized setting.
Limited communication windows, heterogeneous data, and power constraints are
imposed while successfully solving a classification task.

####  III-C1 Setup

The operational scenario in this example consists of two satellites in
circular LEO at an altitude of 550 km with an inclination of 98.62°. They move
in opposing directions and thus have only brief communication windows amongst
them twice per orbital revolution. Both are equipped with a 0.1 MJ battery
with an initial SoC randomly chosen between 0.6 and 0.8. They have solar
panels which charge the battery at 50 W when not in eclipse. They are also
equipped with inter-satellite links enabling them to transmit 1 Mbit per
second amongst themselves when in LOS. The satellites are assumed to not
communicate during the first ten orbital revolutions.

The satellites are tasked with jointly learning a binary classification task
identifying an inner and outer circle by leveraging data uniquely available to
each satellite. The used dataset and its distribution among the satellites is
depicted in Fig. 8. Notably the distributions are heterogeneous with the
satellites only having access to data points with values in the first
dimension above 0.5 and below -0.5, respectively. The test dataset is
identical on both satellites and covers the complete feature space. A total of
4166 training samples are used and the test dataset consists of 3300 samples.
A two-layer dense neural network with ten neurons is trained using stochastic
gradient descent with a learning rate of 0.1 and a binary cross-entropy loss
function. Training is modelled for a total of 30 orbital revolutions. In each
revolution, if allowed, the satellites communicate twice and will train an
aggregated model in the window between communications. On average, Satellite 1
is able to train 42.3 epochs and 11.6 epochs in the two different windows
whereas Satellite 2 is able to train 4.1 epochs and 50.5 epochs. During
operations, the satellites have three distinct operational modes they perform
in descending priority:

  * •

Standby – When the SoC is below 0.5 the satellites stand by to conserve and
charge their batteries. This mode drains 2 W.

  * •

Model Sharing – When the satellites are in LOS of each other they exchange
their models and aggregates via a federated averaging at a power consumption
of 100 W.

  * •

Model Training – If neither of the above takes place the satellites perform a
training epoch at a power consumption of 100 W.

Figure 8: Training and test data for the binary classification task as well as
their distribution among satellites. Note the heterogeneity of the data
distribution in the training set. $y=0$ and $y=1$ are the classes of the
problem.

####  III-C2 Learned Model and Communications

Overall, training the models on the two satellites is successful, reaching an
accuracy of over 91% on both satellites compared to a random guess accuracy of
50% and independent training that results in an accuracy below 70%. Figure 9
displays the test set accuracy over time and shows how both satellites
struggle to obtain good results individually. However, when they exchange
models (marked with gray vertical lines) they improve their accuracy
noticeably. Notice that model transmission is virtually instant given the
small models (only 1312 bits).

It can also be seen that each satellite benefits after each communication
round as the test accuracy rapidly increases. However, once the satellite
starts training on local data again, the performance deteriorates due to
catastrophic forgetting [47]. Furthermore, there is a large discrepancy
between the test accuracy for the two satellites. This happens as Satellite 1
is able to do training after each model exchange because charging is initiated
after one exchange and the satellite remains in LOS with the sun after the
next exchange. Satellite 2, on the other hand, is charging before one exchange
and has stopped charging during the next. Hence, Satellite 2 may not have
battery to do training after one of the model exchanges and, therefore, its
convergence is slower, as seen in Fig. 9.

In terms of power consumption, which is displayed in Fig. 10, we can observe
training in the intervals of rapid oscillation of the SoC when the battery is
charged and consequently the training run. During eclipse the satellites go
into standby to conserve SoC and drains only 2 W. Finally, the rapid increase
in SoC occurs when a satellite is facing the sun and training is not allowed
because SoC is below 0.5.

Figure 9: Test accuracy over 30 orbital revolutions. Vertical gray lines
indicate communication between the satellites. Constant accuracy stems from
the battery SoC being below 0.5.  Figure 10: SoC between orbital revolution 15
and 20.

##  IV Discussion

In general, the examples in Sec. III clearly demonstrate the viability of
PASEOS for the three considered test cases. By running on an actual satellite
processor in real time, we have also shown the feasibility of using PASEOS to
model scenarios while utilizing real, prospective mission hardware. In the
case of the LEO constellation, we can see that PASEOS is also capable of
modelling large constellations on a longer time frame. Finally, we also
showcased how PASEOS can be used to model constraints that impact the training
of machine learning models directly in space. There are, however, some aspects
that mandate further discussion and consideration.

###  IV-A Impact of Onboard Constraints on Machine Learning

One of the objectives of PASEOS is to study the impact of operational
constraints when utilizing machine learning methods in orbit. Especially in
the context of distributed and onboard learning paradigms it is an essential
question what this impact will be [11, 10]. As demonstrated in our onboard
learning results in Sec. III-C, PASEOS can provide concrete insights into the
operational impact of factors such as orbital dynamics and power consumption.
As can be seen in Fig. 9, the timing of communication windows and eclipse
directly influenced the accuracy obtained during the distributed training.
While the importance of factors such as temperature, battery SoC, or the
timing of communication windows in relation to eclipse are well established
parameters for spacecraft operators they have not been studied in the context
of the application of machine learning methods in orbit. Even in-orbit
demonstrations, such as $\Phi$-Sat-1 [48], did not explore the topic of
continuous operations of these systems over a longer operational time frame
where many of the constraints captured by PASEOS play an important role. For
both inference and training in constellations, to the authors’ knowledge,
there is currently a lack of holistic modelling of these factors as offered by
PASEOS.

###  IV-B Scalability & Performance

As shown on the single device example using real space-rated embedded hardware
in Sec. III-A, PASEOS is a lightweight tool that allows modelling the space
environment and operational constraints with minimal overhead for the user
activity. Results shown in Sec. III-A3 showcase that the computational
complexity inside PASEOS models scales linearly with the PASEOS timestep while
requiring less than 1.5% of the total CPU time compared to the user activity
with the highest investigated update rate of PASEOS. This is due to the
particularly efficient physical models that offer suitable trade-offs to be
used on edge devices. This partially comes at the cost of model fidelity, for
which the main limitations and possible future improvements are discussed in
Sec. IV-C and IV-D.

On the other end of the simulation spectrum, the LEO constellation example in
Sec. III-B shows that even as PASEOS is able to handle large constellations of
up to hundreds of satellites, performance does become a concern. If one wants
to model the long-term viability of a constellation including aspects like
station keeping, degradation of photovoltaic cells and batteries, and similar
effects (which are yet to be implemented in PASEOS), computational time may
become a concern. In the single-threaded, single-core run used for the
example, the runtime would, at the moment, already be prohibitive for a
constellation with hundreds of satellites on a timescale of months or years.
Thus, a careful study of the parallelization possibilities of PASEOS will be
required in the future. As PASEOS is implemented in a fully asynchronous
manner, it is straightforward to employ tools such as the popular message
passing interface (MPI) [49] to use compute clusters for PASEOS—this is shown
in one of the online examples. A more detailed investigation of this is
warranted.

###  IV-C Fidelity Considerations

One key point in terms of fidelity that has to be taken into account are the
user-provided specifications. They are not studied here in detail as they are
beyond the scope of this initial release. However, given the holistic nature
and the complex emergent behavior—see, e.g., the complex SoC curve stemming
from just a simple, linear charge model in Figure 5—of PASEOS, the accuracy
and quality of the input parameters is likely to become a critical factor in
the fidelity of results produced by PASEOS. Notably, if all physical models
are activated, the number of input parameters becomes fairly large. Indeed,
just the thermal model requires eight parameters, the power model currently
requires three, the radiation model another three, the orbital model seven and
these parameters need to be defined for every single actor in PASEOS. Thus,
even with the simplified models present in PASEOS, it is evident that
constellation scenarios modelled with PASEOS are already highly complex
systems. In the future, this may require more detailed analysis of the system
sensitivity to specific parameters to guide users as to which parameters are
particularly critical. It is also conceivable to add noise terms in a variety
of the PASEOS’s models to account for this sensitivity. Even higher robustness
code could be achieved by converting some of the parameters to be described by
distributions instead of scalar parameters and thus include a probabilistic,
Bayesian modeling component that allows consideration of prior assumptions
about the accuracy of passed parameters.

###  IV-D Limitations & Prospective Additions

At the moment, there are some natural limitations to the fidelity of the
models in PASEOS and supported scenarios. The two objectives of holistically
modelling the operational environment in space and being able to execute
PASEOS in the background in real-time on edge devices requires a careful
balancing of computational cost and physical fidelity. In the future, this may
be remedied by adding optional components to PASEOS that model the various
physical aspects at a higher fidelity when enough computational resources are
available. Initially, however, we have focused on breadth of considered
physical aspects instead of high fidelity in individual aspects.

In terms of astrodynamics modelling, Keplerian dynamics are a sufficient start
for low-precision Earth orbits but insufficient to, e.g., model orbits around
irregular bodies such as asteroids or comets. Similarly, phenomena such as
station keeping and occasional losses of tracking cannot be model with them.
Natural additions in the future would be a polyhedral gravity model [50] or
the wrapping of a software like orekit [17].

The availability of communication windows in PASEOS is currently determined
solely by whether the LOS is being blocked by an assumed sphere with a
specific radius. More complex geometry could be integrated via meshes. Other
factors such as success of tracking, distance of the actors and atmospheric
conditions for optical communications and similar are also currently not
modeled but sensible additions. Similarly, the communication bandwidth that is
currently available is in reality a more complex and variable quantity
dependent on a lot of the just mentioned factors such as distance, link
conditions, and others parameters linked to the transmission chain (i.e.,
channel-encoding, modulation, additional use of synchronization pilots, etc.).
A more thorough channel modelling is required to account for this. A potential
way forward is to wrap ns-3 or OMNeT++ into PASEOS [16, 15].

In regards to power budgets there also several conceivable improvements, such
as more rigorous modeling of the state-of-charge of the battery [51], a more
thorough model for the charging via solar panels [52] and consideration of
factors such as the age and temperature of the battery, devices, and solar
panels. The thermal model in PASEOS would,in a similar vein, benefit from a
more complex model that accounts for the thermal properties of various
components such as solar panels, radiators and others. Concerning radiation,
total ionization dose effects are not currently implemented in PASEOS, but
they will become relevant for simulations in the time scales of years [12],
especially for commercial off-the-shelf devices [53, 12, 20].

Another direction of improvements lies in expanding the the capabilities of
actors. Ground-based actors are currently stationary and only supported for
scenarios on Earth. Further, space-based actors cannot perform manoeuvres
(although one can manually change the orbit). In the future, these
capabilities could support more complex operational scenarios and activities.

Overall, there is a virtually endless range of potential improvements in
fidelity and modelled aspects. It will require careful analysis of which
aspects are critical to enable realistic constraint consideration and which
ones can be simplified to the degree as is currently the case in PASEOS. But,
to even enable these comparisons, one needs to start with a baseline first,
which is what we are providing here.

##  V Conclusion

PASEOS is a software package that enables holistic modelling of the onboard
environment accounting for, e.g., power, thermal, radiation, and dynamics. The
generality of PASEOS makes it a tool to study a plethora of operational
scenarios, hardware configurations, or to be used in conjunction with other
simulation tools. In particular, PASEOS is well suited to study constellations
in space for emerging operational scenarios, such as edge computing, edge and
decentralized learning, and artificial intelligence in space [54].

Overall, we have demonstrated that PASEOS provides the means to model a
variety of constraints that spacecraft and their operators experience in
orbit. Thus, we can explore the feasibility of onboard activities with a
greater rigor before launch and/or form an understanding of how already
operational assets may be repurposed or perform in the future. Given PASEOS’s
asynchronous and versatile setup, a broad range of scenarios ranging from one
to multiple spacecraft (including ground-based actors) are possible. Both
real-time at-the-edge execution and long-term simulation on a computing
cluster or similar infrastructure are supported. The specifics of the modelled
quantities can be adjusted to fit the particular scenario.

However, there are of course intrinsic limitations to this process. At the
moment, the models inside PASEOS exhibit comparatively lower fidelity than
simulators for dedicated topics (e.g. ns-3 or OMNeT++) to enable rapid
background execution. PASEOS’s modular nature does provide a natural surface
for extension and wrapping of more complex physical models. In the future, we
will conduct application-specific studies, explore more complex models, and
demonstrate an operational scenario using PASEOS on multiple edge devices in
parallel to solve a real-world task.

## Acknowledgment

The authors would like to thank Unibap AB for providing the iX-10 100 device
that was used for our experiments.

## References

  * [1] Stijn Lemmens and Francesca Letizia.  Esa’s annual space environment report.  Technical report, Technical Report GEN-DB-LOG-00288-OPS-SD, ESA Space Debris Office, 2022.
  * [2] Hannah R Goldberg, Özgür Karatekin, Birgit Ritter, Alain Herique, Paolo Tortora, Claudiu Prioroc, Borja Garcia Gutierrez, Paolo Martino, and Ian Carnelli.  The juventas cubesat in support of esa’s hera mission to the asteroid didymos.  2019\.
  * [3] J Douglas Liddle, Antony P Holt, Susan J Jason, Kathryn A O’Donnell, and Edward J Stevens.  Space science with cubesats and nanosatellites.  Nature Astronomy, 4(11):1026–1030, 2020.
  * [4] Harry Jones.  The recent large reduction in space launch cost.  48th International Conference on Environmental Systems, 2018.
  * [5] Oltjon Kodheli, Eva Lagunas, Nicola Maturo, Shree Krishna Sharma, Bhavani Shankar, Jesus Fabian Mendoza Montoya, Juan Carlos Merlano Duncan, Danilo Spano, Symeon Chatzinotas, Steven Kisseleff, et al.  Satellite communications in the new space era: A survey and future challenges.  IEEE Communications Surveys & Tutorials, 23(1):70–109, 2020.
  * [6] Fredrik C Bruhn, Nandinbaatar Tsog, Fabian Kunkel, Oskar Flordal, and Ian Troxel.  Enabling radiation tolerant heterogeneous gpu-based onboard data processing in space.  CEAS Space Journal, 12(4):551–564, 2020.
  * [7] Gabriele Giorgi, Tobias D Schmidt, Christian Trainotti, Ramon Mata-Calvo, Christian Fuchs, Mohammed Mainul Hoque, Jens Berdermann, Johann Furthner, Christoph Günther, Thilo Schuldt, et al.  Advanced technologies for satellite navigation and geodesy.  Advances in Space Research, 64(6):1256–1273, 2019.
  * [8] Pablo Gómez and Gabriele Meoni.  Msmatch: Semisupervised multispectral scene classification with few labels.  IEEE Journal of Selected Topics in Applied Earth Observations and Remote Sensing, 14:11643–11654, 2021.
  * [9] Dario Izzo and Pablo Gómez.  Geodesy of irregular small bodies via neural density fields.  Communications Engineering, 1(1):1–12, 2022.
  * [10] Nasrin Razmi, Bho Matthiesen, Armin Dekorsy, and Petar Popovski.  On-board federated learning for dense leo constellations.  In ICC 2022-IEEE International Conference on Communications, pages 4715–4720. IEEE, 2022.
  * [11] Bho Matthiesen, Nasrin Razmi, Israel Leyva-Mayorga, Armin Dekorsy, and Petar Popovski.  Federated learning in satellite constellations.  arXiv preprint arXiv:2206.00307, 2022.
  * [12] Gianluca Furano, Gabriele Meoni, Aubrey Dunne, David Moloney, Veronique Ferlet-Cavrois, Antonis Tavoularis, Jonathan Byrne, Léonie Buckley, Mihalis Psarakis, Kay-Obbe Voss, et al.  Towards the use of artificial intelligence on the edge in space systems: Challenges and opportunities.  IEEE Aerospace and Electronic Systems Magazine, 35(12):44–56, 2020\.
  * [13] James Richard Wertz, Wiley J Larson, Douglas Kirkpatrick, and Donna Klungle.  Space mission analysis and design, volume 8.  Springer, 1999.
  * [14] Giacomo Curzi, Dario Modenini, and Paolo Tortora.  Large constellations of small satellites: A survey of near future challenges and missions.  Aerospace, 7(9):133, 2020.
  * [15] András Varga and Rudolf Hornig.  An overview of the omnet++ simulation environment.  In 1st International ICST Conference on Simulation Tools and Techniques for Communications, Networks and Systems, 2010.
  * [16] George F Riley and Thomas R Henderson.  The ns-3 network simulator.  In Modeling and tools for network simulation, pages 15–34. Springer, 2010.
  * [17] Luc Maisonobe, Véronique Pommier, and Pascal Parraud.  Orekit: An open source library for operational flight dynamics applications.  In 4th International Conference on Astrodynamics Tools and Techniques, pages 3–6, 2010.
  * [18] Adam Paszke, Sam Gross, Francisco Massa, Adam Lerer, James Bradbury, Gregory Chanan, Trevor Killeen, Zeming Lin, Natalia Gimelshein, Luca Antiga, Alban Desmaison, Andreas Kopf, Edward Yang, Zachary DeVito, Martin Raison, Alykhan Tejani, Sasank Chilamkurthy, Benoit Steiner, Lu Fang, Junjie Bai, and Soumith Chintala.  Pytorch: An imperative style, high-performance deep learning library.  In Advances in Neural Information Processing Systems 32, pages 8024–8035. Curran Associates, Inc., 2019.
  * [19] Martín Abadi et al.  TensorFlow: Large-scale machine learning on heterogeneous systems, 2015\.  Software available from tensorflow.org.
  * [20] George Lentaris, Konstantinos Maragos, Ioannis Stratakos, Lazaros Papadopoulos, Odysseas Papanikolaou, Dimitrios Soudris, Manolis Lourakis, Xenophon Zabulis, David Gonzalez-Arjona, and Gianluca Furano.  High-performance embedded computing in space: Evaluation of platforms for vision-based navigation.  Journal of Aerospace Information Systems, 15(4):178–192, 2018.
  * [21] Peter Fortescue, Graham Swinerd, and John Stark.  Spacecraft systems engineering.  John Wiley & Sons, 2011.
  * [22] Dario Izzo.  Pygmo and pykep: Open source tools for massively parallel optimization in astrodynamics (the case of interplanetary trajectory optimization).  In Proceedings of the Fifth International Conference on Astrodynamics Tools and Techniques, ICATT. sn, 2012.
  * [23] David Vallado and Paul Crawford.  Sgp4 orbit determination.  In AIAA/AAS Astrodynamics Specialist Conference and Exhibit, page 6770, 2008.
  * [24] Samir Ahmed Al-Gailani, Mohd Fadzli Mohd Salleh, Ali Ahmed Salem, Redhwan Qasem Shaddad, Usman Ullah Sheikh, Nasir Ahmed Algeelani, and Tarik A. Almohamad.  A survey of free space optics (fso) communication systems, links, and networks.  IEEE Access, 9:7353–7373, 2021.
  * [25] B Rhodes.  Skyfield: Generate high precision research-grade positions for stars planets moons and earth satellites, 2020.
  * [26] Hemani Kaushal and Georges Kaddoum.  Optical communication in space: Challenges and mitigation techniques.  IEEE communications surveys & tutorials, 19(1):57–96, 2016.
  * [27] Charles S Carrano, Christopher T Bridgwood, and Keith M Groves.  Impacts of the december 2006 solar radio bursts on the performance of gps.  Radio Science, 44(01):1–12, 2009.
  * [28] Gabriele Meoni, Riccardo Cassettari, Matteo Bertolucci, Antonino Marino, Daniele Davalle, Marco Trafeli, and Luca Fanucci.  Ccsds 131.2-b-1 telemetry transmitter: A vhdl ip core and a validation architecture on board rtg4 fpga.  Acta Astronautica, 176:484–493, 2020.
  * [29] George Pitsis, Grigorios Tsagkatakis, Christos Kozanitis, Ioannis Kalomoiris, Aggelos Ioannou, Apostolos Dollas, Manolis G.H. Katevenis, and Panagiotis Tsakalides.  Efficient convolutional neural network weight compression for space data classification on multi-fpga platforms.  In ICASSP 2019 - 2019 IEEE International Conference on Acoustics, Speech and Signal Processing (ICASSP), pages 3917–3921, 2019.
  * [30] Mukund R Patel.  Spacecraft power systems.  CRC press, 2004.
  * [31] I Martinez.  Spacecraft thermal modelling and testing, 1995.
  * [32] Joseph R Srour and James M McGarrity.  Radiation effects on microelectronics in space.  Proceedings of the IEEE, 76(11):1443–1469, 1988.
  * [33] Yifan Lu, Qi Shao, Honghao Yue, and Fei Yang.  A review of the space environment effects on spacecraft in different orbits.  IEEE access, 7:93473–93488, 2019.
  * [34] Olivier Grasset, MK Dougherty, A Coustenis, EJ Bunce, C Erd, D Titov, M Blanc, A Coates, P Drossart, LN Fletcher, et al.  Jupiter icy moons explorer (juice): An esa mission to orbit ganymede and to characterise the jupiter system.  Planetary and Space Science, 78:1–21, 2013.
  * [35] Onur Özgün and Yaman Barlas.  Discrete vs. continuous simulation: When does it matter.  In Proceedings of the 27th international conference of the system dynamics society, volume 6, pages 1–22, 2009.
  * [36] asyncio — Asynchronous I/O.  Available online at: ”https://docs.python.org/3/library/asyncio.html”.  Last accessed on 30th January 2023.
  * [37] Alex Arenas, Albert Díaz-Guilera, Jurgen Kurths, Yamir Moreno, and Changsong Zhou.  Synchronization in complex networks.  Physics Reports, 469(3):93–153, 2008.
  * [38] D.L. Mills.  Internet time synchronization: the network time protocol.  IEEE Transactions on Communications, 39(10):1482–1493, 1991.
  * [39] Ozalp Babaoglu, Toni Binci, Mark Jelasity, and Alberto Montresor.  Firefly-inspired heartbeat synchronization in overlay networks*.  In First International Conference on Self-Adaptive and Self-Organizing Systems (SASO 2007), pages 77–86, 2007.
  * [40] Maria Pia Del Rosso, Alessandro Sebastianelli, Dario Spiller, Pierre Philippe Mathieu, and Silvia Liberata Ullo.  On-board volcanic eruption detection through cnns and satellite multispectral imagery.  Remote Sensing, 13(17):3479, 2021.
  * [41] Pietro Di Stasio, Alessandro Sebastianelli, Gabriele Meoni, and Silvia Liberata Ullo.  Early detection of volcanic eruption through artificial intelligence on board.  In 2022 IEEE International Conference on Metrology for Extended Reality, Artificial Intelligence and Neural Engineering (MetroXRAINE), pages 714–718. IEEE, 2022.
  * [42] Meoni Gabriele et. al.  Design of an end2end deep neural network model onboard satellites for time-critical applications.  Living Planet Symposium 2022, 23–27 May 2022, Bonn, Germany.
Available online at:
<EMAIL_ADDRESS>
  * [43] Sentinel-2 Products Specification Document.  Available online at: ”https://sentinel.esa.int/documents/247904/685211/sentinel-2-products-specification-document”.  Last accessed on 21st January 2023.
  * [44] Yet Another Python Profiler (yappi).  Available online at: ”https://pypi.org/project/yappi/”.  Last accessed on 23rd January 2023.
  * [45] Francesco Massimetti, Diego Coppola, Marco Laiolo, Sébastien Valade, Corrado Cigolini, and Maurizio Ripepe.  Volcanic hot-spot detection using sentinel-2: a comparison with modis–mirova thermal data series.  Remote Sensing, 12(5):820, 2020.
  * [46] John G Walker.  Satellite constellations.  Journal of the British Interplanetary Society, 37:559, 1984.
  * [47] Neta Shoham, Tomer Avidor, Aviv Keren, Nadav Israel, Daniel Benditkis, Liron Mor-Yosef, and Itai Zeitak.  Overcoming forgetting in federated learning on non-iid data, 2019.
  * [48] Gianluca Giuffrida, Lorenzo Diana, Francesco de Gioia, Gionata Benelli, Gabriele Meoni, Massimiliano Donati, and Luca Fanucci.  Cloudscout: a deep neural network for on-board cloud detection on hyperspectral images.  Remote Sensing, 12(14):2205, 2020.
  * [49] David W Walker and Jack J Dongarra.  Mpi: a standard message passing interface.  Supercomputer, 12:56–68, 1996.
  * [50] Dimitrios Tsoulis.  Analytical computation of the full gravity tensor of a homogeneous arbitrarily shaped polyhedral source using line integrals.  Geophysics, 77(2):F1–F11, 2012.
  * [51] Xin Lai, Shuyu Wang, Shangde Ma, Jingying Xie, and Yuejiu Zheng.  Parameter sensitivity analysis and simplification of equivalent circuit model for the state of charge of lithium-ion batteries.  Electrochimica Acta, 330:135239, 2020.
  * [52] Angel Porras-Hermoso, Borja Cobo-Lopez, Javier Cubas, and Santiago Pindado.  Simple solar panels/battery modeling for spacecraft power distribution systems.  Acta Astronautica, 179:345–358, 2021.
  * [53] Windy S Slater, Nayana P Tiwari, Tyler M Lovelly, and Jesse K Mee.  Total ionizing dose radiation testing of nvidia jetson nano gpus.  In 2020 IEEE High Performance Extreme Computing Conference (HPEC), pages 1–3. IEEE, 2020.
  * [54] Jose Manuel Gaspar Sanchez, Nils Jorgensen, and Martin Torngren.  Edge computing for cyber-physical systems.  ACM Trans. Cyber-Phys. Syst., 2022.