1. SmallSat Payload Simulation for Onboard-
Software Verification
Alberto Isaac Barquin Murguia
Space Engineering, masters level
2016
Luleå University of Technology
Department of Computer Science, Electrical and Space Engineering
2. SmallSat Payload Simulation for
Onboard-Software Verification
Alberto Isaac BARQU´IN MURGU´IA
Universit´e Toulouse III
Lule˚a University of Technology
A thesis submitted for the degree of
MSc Tecniques Spatiales et Instrumentation
MSc Space Science and Technology
September 2016
3. Abstract
This work presents the advancements in the development of simulation mo-
dels of spacecraft components as part of a testbench for verification of on-
board flight software. The satellite and its mission are briefly described
as to give an idea of the conditions where the simulation has to run. The
simulation environment, SimTG, is also introduced and a description of the
developed models is presented. The models required interaction between
different simulation environments, real hardware and simulated hardware,
and also some data processing was necessary in order to filter undesired
information. Finally, the performance of the models was tested and verified
and a sensible improvement of the state of the testbench on the simulation
side was achieved, although a considerable amount of work still lies ahead
before a complete onboard software verification tool is ready.
4. Summaire
Ce travail pr´esente les avancements dans le d´eveloppement de mod`eles de
simulation de composants d’engin spatial dans le cadre d’un banc d’essai
pour la v´erification de logiciel de bord. Le satellite et ¸ca mission sont
bri`evement d´ecrits afin de donner une id´ee des conditions o`u la simula-
tion doit se d´erouler. L’environnement de simulation, SimTG, ainsi que
les mod`eles d´evelopp´es sont ´egalement pr´esent´es. Les mod`eles ont exig´e
l’interaction entre diff´erents environnements de simulation, du mat´eriel vrai
et du mat´eriel simul´e. Du traitement de donn´ees s’est aussi r´ev´el´e n´ecessaire
pour filtrer les informations non d´esir´ees. Finalement, la performance des
mod`eles a ´et´e test´ee et v´erifi´ee et l’on a observ´e une sensible am´elioration de
l’´etat du banc d’essai sur le plan de la simulation, mˆeme s’il reste toujours
une quantit´e de travail consid´erable afin qu’un outil complet de v´erification
de logiciel de bord soit prˆet.
5. Acknowledgements
First of all I want to thank the National Council of Science and Technology
from Mexico for the full scholarship I was given to pursue this master’s
program. Without them I would not have done any of this. I also want to
thank Erasmus+ for sponsoring me on my third semester of studies, and
Airbus DS, for providing me with a final internship.
I also want to thank my supervisor at Aribus DS, Jens Eickhoff, for giving
me the opportunity to work on this project; it has been a great experience.
I want to thank professor Edmundo Rocha Czatl for the influence he exerted
on my academic life.
Finally, at the risk of sounding cliche, I want to thank my family and friends
for being with me despite the enormous distance; and also to those I met
during the master’s, for helping make these two years an amazing experi-
ence.
iv
8. Chapter 1
Introduction
This thesis is an account of the work carried out during a final internship on the project
Future Low-cost Platform at Airbus Defence and Space in Friedrichshafen, Germany.
The Future Low-cost Platform (FLP) is a joint venture between Airbus DS and the
University of Stuttgart. It arises as an upgrade of the previous version of the project,
the Flying Laptop, and it aims at creating a satellite platform that is reusable in mul-
tiple scenarios, by being able to carry different sets of instruments for several missions.
The advantage of reusability of the platform, is that it reduces the costs of a mission
because there is no need to design an entire new satellite from scratch and the platform
can be suited to a new mission with only some minor modifications.
The platform is that par t of the satellite that takes care of the satellite itself, keeping it
healthy so that its payload can carry out the intended measurements or observations. It
is in charge of maintaining the temperatures, battery charge, attitude and orbit within
a certain range where everything works properly. All these activities are part of what
is called house keeping.
The onboard computer is responsible for house keeping with a certain degree of auto-
nomy. It has to be capable of failure detection and handling. For instance, when a
satellite is deployed, it usually starts in safe mode, which means deploy solar panels
and find the Sun. This mode is critical when trying to keep the spacecraft functional
after some unwanted situation happens, ensuring it receives energy to keep the batte-
ries charged.
Because all those different situations where the onboard software has to perform pro-
perly cannot be tested before launching, it is necessary to create a testbench in which
1
9. 1. INTRODUCTION
to let the onboard computer handle the different scenarios and let it fail until all
the bugs have been found and taken out: that’s where the usefulness of simulations
comes to hand. The setup in the laboratory consists of an onboard computer from
Cobham Gaisler, model GR712; two SpaceWire routers from 4links, model RTR4; a
SpaceWire-Ethernet interface, or SRR (SpaceWire RMAP Responder) that acts as a
bridge between the physical hardware and the simulated models; and a computer where
the simulation is run, an 8 core Intel Xeon processor running Red Hat Enterprise Linux.
It runs Eclipse version 4.4.2.
Figure 1.1: Testbench
This thesis is organized in the following way: chapter 2 contains a description of
the Future Low-cost Platform and the hardware available at the testbench, as well
as a short description of the mission that is being simulated; chapter 3 goes into the
details of the simulation environment and how the simulation is run, as well as a brief
description of the inherited models that already existed within the project; chapter 4
describes the work done on the payload and the models that are part of it, as well
as some work that was carried out outside of the simulation environment that also
concerns the payload; and chapter 5 describes the insights that were reached by the
time spent on this project.
2
10. Chapter 2
Future Low-cost platform
The FLP satellite is, as its name implies, a low-cost satellite that would be classified
as a small satellite. It will be about one cubic meter in size, and will weigh something
close to 150kg. It is equipped with all the necessary instruments on the platform side,
that enable it to perform in space regardless of the mission, such as star trackers, gy-
roscopes, magnetometers, reaction wheels, solar panels, batteries, etc.
2.1 Mission
Although the project falls in the department of future programs, and so it has at the
moment of writing this thesis no defined mission, for the sake of having a fully inte-
grated simulation, a plausible mission is to be simulated. This mission is concerned
with Earth observation, and an instrument is proposed for taking on such mission: the
Instaview.
The currently investigated satellite mission will orbit at an altitude of 600 km with
an inclination of 30o. The platform will have contact with ground stations for house
keeping activities, and the payload will have a separate link to ground via a relay con-
stellation. A steerable antenna will establish the connection with the satellites of the
constellation, and they will relay the data down to the instrument’s users.
3
11. 2. FUTURE LOW-COST PLATFORM
2.2 Hardware
2.2.1 Onboard computer
The onboard computer is a GR712 model that features a LEON3-FT SPARC V8 pro-
cessor by Cobham Gaisler (5). The onboard software runs on the real time operating
system RTEMS and options are currently being explored as to how to exploit in a
novel way the two cores available, which will permit to have all operations dedicated to
the satellite bus run on one core, and payload related computations run on the second
core. The difficulties of this approach come mainly from the fact that race conditions
are possible and the program stops being deterministic. However, this is not the subject
of this thesis and will not be discussed further.
2.2.2 Mass Memory Unit
The testbench also counts with a mass memory unit where the data generated by the
instruments will be stored. This mass memory unit is SpaceWire capable, and will
be accessible directly from the payload, onboard computer, and downlink encoder via
RMAP protocol. A physical mass memory unit is available for the testbench, but as of
the time of writing, only a simulated one was used. The physical memory unit has a
storage capacity of 16 GB and is capable of running its own real time operating system.
2.2.3 SpaceWire and RMAP
Most of the data connections within the satellite will be over SpaceWire, which is a
space-grade radiation tolerant data-handling interface designed with the aim of stan-
dardizing reusable technology, reducing costs and facilitating the design and construc-
tion of data-handling systems (12). SpaceWire can handle point-to-point links between
devices, or even entire networks using SpaceWire routers. This protocol can run at
different speeds between 2Mbits/s and 200Mbits/s across a full-duplex bidirectional
link that uses Low Differential Voltage Signaling (LVDS). The routers forward traffic
based on routing tables or instructions contained in the packets. A SpaceWire packet
consists of a header, cargo and end of packet bits (EOP) as shown in figure 2.1. The
destination address can be either a path address, or a logical address. The former refers
to the route the packet has to take from the sender to the receiver across a network
4
12. 2.2 Hardware
of SpaceWire routers. Each router reads the first byte of the packet and if it is within
the range 1 to 31, it strips off that byte and forwards the rest of the packet to the port
indicated by that byte and so on until the packet reaches its destination. If instead
of an outgoing port, a unique address is specified, it is called logical addressing, and
the router needs to look up in the routing table which port corresponds to that logical
address, which means that the routing tables need to be set up before hand. Then
comes the cargo, which is the actual information that needs to be transferred. There is
no limit in the SpaceWire protocol for the size of the cargo, but it is not recommended
to send extremely long packets because ports could get blocked until the packet has
been transmitted completely (13).
Figure 2.1: SpaceWire packet format
There are several communication protocols that communicate over SpaceWire. One
of these protocols is the Remote Memory Access Protocol (RMAP), which supports
writing to and reading from memory in a remote SpaceWire node. It can also be
used to configure a SpaceWire network and command a SpaceWire node (14). RMAP
request packets have a header that is at least 16 bytes long. The 1st and 5th bytes
indicate the destination and source logical addresses, respectively. The 2nd, 4th, 6th
and 7th are identifiers for the protocol, the destination key and the last two for the
transaction, also respectively. The 3rd byte indicates the command and nature of the
packet, be it a read or a write request. Then there are 5 bytes assigned for memory
addresses. That means that the protocol can address memory banks of up to 240 bits,
or 1 TB of capacity. The next 3 bytes correspond to data length, which means that,
unlike SpaceWire packets, RMAP packets are limited in size to 224 bits, equivalent
to 16 MB per packet. The last and 16th byte is a Cyclic Redundancy Check (CRC)
checksum, to ensure the integrity of the packets. Optionally the header can include the
destination path address and the source path address, so that packets are able to make
5
13. 2. FUTURE LOW-COST PLATFORM
their way in a network without routing tables. After the header come all the data bytes
and another CRC checksum followed by a SpaceWire EOP.
Figure 2.2: RMAP Write Command (1)
6
14. Chapter 3
Simulation
Satellites, or spacecraft in general are very complex systems that involve extensively
detailed design and manufacturing techniques. Verification of such phases is extremely
helpful for the final validation of a project, and thanks to the available computing
resources of today, also extensively detailed simulations are possible. This makes it
possible to test every functionality of the onboard software with simulated models
that conform the entirety of the spacecraft, sometimes including the onboard computer
itself (4). In the case of an FLP based satellite, the goal is to have a fully simulated
environment that opens the possibility of simulating entire constellations of satellites,
although at the moment, let us only focus on the actual state of the testbench. Figure
3.1 shows a diagram of the testbench, with the elements and connections that are
part of it. The processor board with its dual core processor is able to dedicate one of
them to the platform and house keeping activities, and the other to payload-related
activities. In this way, both parts of the satellite, platform and payload, are handled
independently. The onboard computer then is connected to two SpaceWire routers,
having thus one platform router and one payload router. The routers are also connected
to the SpaceWire RMAP Responder (SRR) that forwards all the SpaceWire packets to
the simulation computer. The SRR is interfaced in the computer using a 4Links API
in a program called IOBroker. This program is mainly legacy from the past version of
the project. It was created because the old simulator ran at a certain frequency and
not in real time, creating thus a latency in the received packets that came from the
SRR with low latency (2). The IOBroker is therefore run in real time, and on receiving
a new packet it writes it into a buffer that will be read by the simulation. Today’s
7
15. 3. SIMULATION
Processor
Board
CCSDS BoardCCS5
Payload
Ground Client
(Web browser)
Constellation
Ground Station
Platform RTR Payload RTR
MMU
SRR
I/O-Broker
Terminal +
Encoder/HF
Antenna Model
Drive
I/O-Board
Model
PCDU Model
Payload
Equipment
Model
Platform
Equipment
Models
Constellation
Ephemerides
Orbit/
Ephemerides
Simulation
SpaceWire
Simulated SpaceWire
Internet/WAN/LAN
Encoded Mission Product
TM/TC over LAN
Not assigned yet
Figure 3.1: FLP Testbench Infrastructure
simulation software has improved since the days of the Flying Laptop, and now it is
possible to run different models at specific frequencies or in an asynchronous manner,
which allows them to receive the incoming packets in real time.
3.1 SimTG
Behind the IOBroker, the packets go to the actual simulation software: SimTG. SimTG
is a modeling framework developed at Airbus DS, that lets us simulate the whole
spacecraft in a modular way (18). The models are programmed with C++, an object
oriented programming language capable of generating compiled executables for fast
processing (15). SimTG comes as an Eclipse plug-in, so all the other functionalities of
Eclipse are also available, such as repository management and debugging (3).
As mentioned before, SimTG uses models for the different elements of the spacecraft
that have to be simulated. These models have internal variables, inputs and outputs,
and internal functions. They can also be executed synchronously or asynchronously.
8
16. 3.1 SimTG
The former means that the functions are called at regular intervals, or that they have
to be called explicitly. The latter means that when an input is propagated to the
model, a certain predefined behaviour will be executed. When a model is created,
SimTG generates 4 files automatically: an xml file with all the necessary definitions
for displaying it within the SimTG visual environment, but also including its internal
variables, outputs and inputs and its extension is smf; a Base file, which is a C++
source file that is used for initializing the internal variables and handling other SimTG
functions of lower level; two C++ source files, a header file and a cpp file, where
the functionalities of the model are programmed. In the cpp file, there is two very
important methods: init() and step(). The method init() is called once the model
has been instantiated and is where all the initializations have to be made, such as
sockets, shared memories, etc. The other method, step(), is called for every step of
the simulation, be it synchronously, i.e. periodically at definite time steps, or be it
asynchronously, that is, whenever an input is updated.
3.1.1 Testing
SimTG uses Java for testing the models. A small Java program instantiates the models
needed and creates the connections between them using XML files similar to those
created by SimTG described earlier. That made it easier to create the entries for these
XML files needed for testing the simulation. The model’s properties are listed in the
smf file with a mark that contains the text DataDef, so those lines were extracted from
the file and the field values separated with awk. Then they are sorted alphabetically
and after, again with awk, they are given the XML format needed for instantiating the
models and a few other corrections are made with sed. The shell command that does
all this is the following:
# Finds parameters | prints name type value | alphabetcally | prints XML
#format | adds commas for vector values | fixes cat="0">< | fixes >km/s<
grep DataDef *.smf | awk -F= ’{print $4 $6 $7}’ | sort | awk -F" ’{print
"<"$2" cat=""substr(tolower($4),0,1)"">"$6"</"$2">"}’ | sed -e "s/.[0-9](
)/0,/g" | sed -e "s/0">/p">0/g" | sed -e "s/>[a-z]*/[a-z]*/>/g"
9
17. 3. SIMULATION
3.2 Already existing elements
Some parts of the simulation shown in figure 3.1 were already developed and running
and had to be only slightly modified for the purpose of this project. Most of the models
of the satellite’s devices are under development at the University of Stuttgart, and a
few of them are available for the testbench existent in Friedrichshafen. The IOBoard,
magnetometer and PCDU (Power Conditioning and Distribution Unit) are such mo-
dels. The main task with those, was to include them within the rest of the simulation
by generating the XML tags, and maybe correct the code when needed. Another one
of those models was the one that propagates the orbit of the satellite by integrating the
forces acting on the spacecraft. This model was developed as a master’s thesis, but it
only included an ideal orbit, where only gravity is taken into account, neglecting other
perturbations like solar pressure, or atmospheric drag (10). This model made use of
Euler’s rule for integrating the forces, but was modified to use the trapezoidal method,
which is more accurate. Also latitude and longitude had to be set as outputs, and the
time model that was inside it was taken out so that other models could use it too.
10
18. Chapter 4
Payload
The proposed architecture of the onboard computer makes use of its second core as a
payload management computer, thus making the first core take care of the platform’s
operations. Given that the FLP satellite does not have a specific mission, there needs
to be a payload for the onboard computer to command. The proposed payload is called
Instaview, and consists of a camera that will photograph the surface of the Earth as
the satellite orbits.
The camera was designed with a simple state machine that upon reception of com-
mands turns on, calibrates itself, takes pictures, and turns off as shown in figure 4.1.
The blue arrows indicate that a command is needed for the transition, whereas the red
arrows indicate that the transition will happen after a certain period of time.
Trying to simulate to take a picture can vary in a wide range of complexity. Initially,
to get an idea of what the camera would see, we assumed that it would be facing Earth,
at a right angle, and that Earth would look like a very simplified version of itself, like
the ones presented in solutions such as OpenStreet maps (7). The camera then, needs
to know the coordinates of the sub-satellite point in order to extract an image off an
OpenStreetMaps server. The way an OpenStreetMaps server works, or probably any
map online service for that matter, is by dividing Earth’s surface into tiles of a certain
size at different levels of zoom. These tiles are later merged together to form a rectan-
gular area where the point of interest is enclosed. The objective of the payload is to
retrieve that tile where the point of interest is. Because downloading the image within
11
19. 4. PAYLOAD
Figure 4.1: Instaview’s state machine
SimTG slows down the simulation, it was decided to relegate that part to an external
program coded in Python. For that purpose a library also written in Python was used,
taken from a public GitHub repository available in (11). This Python program would
need the coordinates of the sub-satellite point as input so that it could find the desired
tile. For the sake of simplicity this input to the Python program from SimTG was
made with a FIFO (First Input First Output) file into which SimTG writes and out
of which the Python program reads. The pair of coordinates is then converted into a
URL and can be downloaded from the server. The end result is a picture of what the
instrument would see, as presented in figure 4.2.
4.1 Other models
The payload side not only includes the instrument, but also the devices required for
storing and transmitting the data generated by the instrument, so a few other models
were developed in order to have a complete flow from instructing the payload to acquire
and save the data, to sending it down to ground. The process includes storing the data
on a memory unit and an antenna/encoder that connects to the relay satellites which
12
20. 4.1 Other models
Figure 4.2: Sample tile
will transfer all the instrument’s data. A small part of the on-board computer was
also simulated, whose purpose is to track the positions of all the satellites from a
constellation, in order to be able to correctly point the antenna at them. This section
dives into the different models that were developed within the simulation.
4.1.1 Mass Memory Unit
In order to store the data generated by the instrument, a model of a Mass Memory Unit
(MMU) was also created within the simulation. The MMU needed to be SpaceWire
and RMAP capable and different solutions were explored as to how the SpaceWire
connection had to be implemented. This connection also had to be managed by the
RMAP library that was already being used within the testbench, which initially was
part of the IOBroker code, and therefore had to be modified in order for it to function
within SimTG. Since SpaceWire transmits the data through a serial line by low voltage
differential signaling (LVDS), a SimTG Serial Line was initially used for the transmis-
sion of the RMAP packets. Because the SpaceWire protocol also has different flags to
identify correct reception of a packet with the end of packet (EOP) bits, it was decided
to discard the serial line and use a composite type instead. SimTG allows to create
composite datatypes that can be used as inputs/outputs for the models. A composite
type allows for the use of markers that indicate correct reception of a packet with EOP,
or an error end of packet (EEP), this by adding a separate integer along with a string of
bytes for the RMAP packet and another integer that indicates the length of the packet.
13
21. 4. PAYLOAD
The RMAP library was then modified so that it could handle such data type with a
similarly created structure native to the C++ language. Once the RMAP library can
handle this datatype, the only thing that is left is for the memory unit to deal with write
and read requests. This is done by simply copying the data bytes from write requests
to a memory address inside a previously allocated memory space for write requests,
and copying data bytes from that memory space to the RMAP transmission buffers
from the RMAP library upon reception of a read request. A disadvantage with this
approach is that the amount of memory that can be allocated is not as big because it
uses RAM memory, but for the purpose of the simulation, a limited amount of memory
is enough to prove its functionality and does not have the disadvantage of having to
deal with files on a hard drive, which are slower to access.
4.1.2 Onboard Computer
The images captured by the camera have also to be down-linked via a relay constellation
of satellites. For this, the onboard computer needs to know its own location, as well as
that of the relay satellites, in a common reference frame. It’s own position should be
taken from the GPS model, but the development has not yet been completed, so the
coordinates were taken from the dynamics propagation model, which eventually will
provide the GPS model with the actual position. The positions of the relay satellites
are not propagated with such an accurate dynamic simulation as used for the FLP
satellite, instead a catalog is used, which contains the satellites’ orbital elements. This
kind of catalog is called Two Line Elements (TLE) catalog, and they are widely used,
regularly updated, and easily available on the internet (9).
Because TLEs are generated using the SGP (Simplified General Perturbation) models
for determination of orbits, they need to be propagated with those models too, so
that the calculated orbit has sufficient accuracy and is actually useful at predicting the
position of the object of interest. These models were developed in the 60s and 70s, and
in 1980, a paper which contained code for the initial five models was published (8). With
time, researchers all over the world started using the code and making modifications
to it with the aim of improving it, but making it, as a result, incompatible with the
way TLE were generated. To address this problem, a paper that revisited the famous
Spacetrack Report #3 was published as well as source code in different programming
languages that allows for the implementation of a generalized and compatible version
14
22. 4.1 Other models
of the models in question (16).
TLE files save the satellite’s position at a certain epoch, and a TLE with multiple
satellites is not likely to have all epochs synchronized, so it is necessary to save the
differences between the TLE’s epochs and the simulation time, so all orbits can be
propagated in synchrony. When the position in time is computed, this difference is
added to the simulation time, making it possible to synchronize multiple TLE entries
with one base time.
After computing the positions of all the relay satellites, the OBC finds the closest one
and has to calculate elevation and azimuth angles to feed to the antenna. In order to do
this, two rotations have to be done. The first one transforms the direction vector from
the FLP satellite to the chosen relay satellite from an Earth centered inertial frame to
a nadir pointing frame centered on the spacecraft. The second rotation transform the
mentioned vector from a nadir pointing frame to a body fixed frame ,depending on the
spacecraft’s attitude.
In a nadir frame, the ˆz direction points to Earth, the ˆx direction points forward but
Figure 4.3: Fixed on Earth and body frames
not necessarily tangential to the orbit -this is only the case for circular orbits-, and
the ˆy direction points perpendicular to the orbital plane, completing the triad. The
transformation to this frame can be described as follows:
TN
E ·
−→
j = j · ˆj
TN
E ·
−→
k = k · ˆk
TN
E · −→r = −r · ˆz
15
23. 4. PAYLOAD
Where ˆx, ˆy and ˆz are the unit vectors in the inertial frame, and ˆj, ˆk and ˆl are the unit
vectors in the nadir frame. The ˆy vector is obtained with the cross product from the
−−→r vector which points to Earth and the velocity −→v vector, tangential to the orbit.
The ˆx vector is computed by the cross product of the ˆy vector and the ˆz vector. The
transformation matrix is then:
TN
E = ˆr × ˆv × ˆr ˆr × ˆv ˆr
T
(4.1)
Where ˆr and ˆv are unit vectors defined as follows:
ˆr =
−−→
−−→r
|−→r |
ˆv =
−−→
−−→v
|−→v |
The next transformation matrix depends on the attitude of the spacecraft and is given
by the Euler angles φ, θ and ψ as follows (6):
TB
N =
−sinφsinθsinψ + cosφcosψ sinφsinθcosψ + cosφsinψ −sinφcosθ
−cosθsinψ cosθcosψ sinθ
cosφsinθsinψ + sinφcosψ −cosφsinθcosψ + sinφsinψ cosφcosθ
(4.2)
Once the vector
−→
b which points to the relay satellite from the FLP satellite, is in
a body fixed frame, azimuth and elevation of the antenna can be calculated. The
Figure 4.4: Elevation and azimuth angles
16
24. 4.1 Other models
elevation is simply the complementary angle of the angle formed between the vector
−→
b
and the −ˆl axis, or as equation 4.3 shows:
=
π
2
− cos−1
(
−→
b · −ˆl
|
−→
b || − ˆl|
) (4.3)
The azimuth angle is measured between the ˆk direction and the shadow of the
−→
b vector
on the ˆjˆk plane, or as equation 4.4 shows:
α = tan−1 −
−→
b k
−→
b j
(4.4)
4.1.3 Constellation
The azimuth and elevation angles are fed to the antenna, but in order for it to know if
the link was correctly established, it also needs to know if the beam is hitting the relay
satellite, which means it needs to know where the relay satellite is. For this purpose
another software was acquired and it will be explained in the following subsection.
4.1.3.1 Astos Simulation
Because the orbits of all satellites in the relay constellation need to be propagated
as accurately as possible to simulate a scenario as realistic as possible, a specialized
software from Astos Solutions was acquired for the task (17). The program can create
constellations based on a TLE file and one previously defined spacecraft. Defining a
spacecraft in the program is done by creating a vehicle and assigning mass to it, both
from fuel and dry mass. This is needed for the integration of forces acting upon a mass.
Then an epoch is defined and a time duration for the simulation. The results can be
exported to a tsv file (Tab Separated Values), and then it has to be processed because
the exported file includes more than 600 columns for a 12 satellite constellation. This
is done with awk and a little bit of help from Python. The header line was imported
to the Python console and separated into an array that can be easily analyzed in order
to find the desired values, i.e. the positions of the satellites. Then it compares those
values with the complete array and prints out the columns that correspond to each
of the coordinates, and then awk filters them into a much smaller csv file (Comma
Separated Values).
17
25. 4. PAYLOAD
Figure 4.5: 3D view of simulation
4.1.3.2 Interpolator
The results from the simulation with the Astos software, i.e. the csv file, is saved in a
shared folder on the Windows computer where the software is installed, and mounted
on the Linux computer where SimTG accesses it as a normal file in the filesystem. The
time steps in the SimTG simulation are much smaller than those resulted from the
Astos simulation, and even if they were not, the chances of them coincide at the same
epoch are practically zero, since we are dealing with floating point numbers; therefore,
it is necessary to interpolate for the coordinates of all 12 relay satellites at the time
where the SimTG simulation is actually running. That means checking through the
array where the positions are loaded and find the upper and lower boundaries in time,
that is, the two rows needed for interpolation. This finding action can be very time
consuming if those rows are at the end of the array, since the whole array has to be
searched through. To speed up the process, the last row that was checked is saved and
then the search is conducted only after that last row, thus having only to go over a few
rows to find the next position.
18
26. 4.1 Other models
The snippet of code that does that looks like this:
1 f o r ( col = l a s t c o l ; col < c o l s ; col++){
2 i f ( time >= p o s i t i o n s [ 0 ] [ col ] && time < p o s i t i o n s [ 0 ] [ col +1]){
3 double t1 , t2 , a1 , a2 ;
4 ( . . . )
5 xyz [ 0 ] = a1 +(time − t1 ) ∗ ( a2 − a1 ) / ( t2 − t1 ) ;
6 ( . . . )
7 }
8 }
After all 3 coordinates of all 12 satellites have been computed, the closest one to the
FLP satellite is selected and its coordinates are forwarded to the Antenna model.
4.1.4 Antenna
This model receives from the OBC two angles: elevation and azimuth. The antenna has
to be pointed at those angles in order to establish a connection to the relay constellation,
which in turns is to link it down to ground for its users. The antenna, in order to know
if the connection is established, needs to perform a series of computations similar to
the ones done in the onboard computer that result in those angles. The angles need to
be converted into a vector −→a that is then compared to the vector
−→
b that points to the
relay satellite. This has to be done inside a common frame of reference, so the vector
−→
b has to be transformed from an inertial frame of reference to a body fixed frame the
same way as described in subsection 4.1.2. Then the angle between these two vectors,
which will be named γ, is measured with a simple dot product as in equation 4.5 and if
that angle is less than a threshold, i.e. 1 degree, the connection is said to be established.
γ = cos−1
−→a
−→
b
|−→a ||
−→
b |
(4.5)
The resulting angles for a simulated period that involved 5 changes of relay satellites
to be pointed at is shown in figure 4.6. The majority of points are located close to a
median of 0.411o, which is well within the threshold, meaning that the propagation of
the orbits with the mentioned SGP models is sufficiently accurate for the task.
19
27. 4. PAYLOAD
Figure 4.6: Deviation angle between antenna and relay satellite
4.2 IOBroker
Although the IOBroker is not really part of the payload, since it manages all the
connections out to the real hardware, and because the payload, as figure 3.1 shows,
has a connection independent of the one that goes to the IOBoard, thus bypassing
it, modifications to the IOBroker were necessary. The role of the IOBoard is to act
as a bridge between the onboard computer and all the devices that cannot handle
SpaceWire with a sort of multiplexing of all those lines into one SpaceWire line. The
communication between the IOBroker and the IOBoard goes through a couple of shared
memory files, one for each way of communication, that is, one where the IOBroker writes
and the IOBoard reads, and one where the IOBoard reads and the IOBroker writes.
In order for the shared memory to be created, the files have to exist, and when it is
created, it allocates as many bytes as needed for that file. In the code, the shared
memory looks like a C struct; there is essentially two integers and one pointer. The
pointer stores the memory address of the shared memory, and the integers keep record
of the read and write positions (RP and WP, respectively). When a block is written,
the WP is increased by the size of the block, and when a block is read, the RP is
20
28. 4.2 IOBroker
increased too by the size of the block. If either of them reaches the end of the allocated
space, it is reset to zero. If the WP reaches a cycle before the RP and then catches
up to it, it will not be possible to write on it because some information has not been
read yet and it would be destroyed if an attempt to write is performed. This process
is illustrated in figure 4.7.
In order for the payload to communicate with the real hardware it needs to access the
Figure 4.7: Simplification of the 2 shared memory files
IOBroker, and the only way to do this is through the shared memory, but the problem
is that the shared memory can only be read by one device because everytime a block
is read, the RP is updated and the block is discarded. If the payload happened to
read a block corresponding to the IOBoard, the IOBoard will not receive it and the
payload would not know what to do with it. Writing to the shared memory is not
a problem because the previous positions of the WP are not relevant to any of the
parties and it can be updated without any consequences. The way to solve this was
to create an extra byte inside the C++ struct that is exclusively read by the payload,
and although it reduces the usable size of the shared memory, it is by no means a
significant reduction. The payload receives 1 byte-long commands and that single byte
is enough for that purpose, although as development advances, RMAP packets need to
be sent throughout the testbench, making this approach obsolete. A new version of the
IOBroker needs to be implemented, which can run inside SimTG and is able to forward
SpaceWire packets through the method described earlier, using a composite datatype.
21
29. Chapter 5
Conclusion
Although there is a lot of work yet to be done until the completion of the testbench,
many milestones were achieved. A simple payload model that makes use of the sa-
tellite’s coordinates to retrieve an image of Earth’s surface is commandable and able
to communicate with the real hardware. The onboard computer model can read TLE
files with multiple satellites and is able to propagate and synchronize their orbits with
its own time. Furthermore, it can find the most appropriate satellite to link to, and
computes the angles the antenna needs to point at in order to establish a connection,
achieving fairly accurate calculations. The antenna model can also do the necessary cal-
culations to find the relay satellite on a body fixed reference frame and decide whether
the link is established or not. The results from the Astos simulation are also available
within SimTG, and the positions of all satellites are interpolated at the current simu-
lation time, giving the antenna model a reference that enables it to evaluate the angles
calculated by the onboard computer. The mass memory unit model is also usable and
RMAP capable, so it can receive and respond to write and read requests over RMAP.
The other models developed at Stuttgart, that is the magnetometer, power containment
and distribution unit, batteries, solar panels and IOBoard, are also fully integrated and
operational within the simulation as well as the orbit propagation model. The IOBro-
ker can now handle multiple SpaceWire ports for differentiated transmission depending
on what model are the packets coming from. All this allows for a better integrated
simulation where a complete flow of information can be achieved, from ground systems
and mission control all the way to the payload via the onboard computer.
22
30. References
[1] Remote memory access protocol. ECSS-E-50-11 F,
2006. 6
[2] 4Links. SpaceWire RMAP Responder, (SRR):
Product Brief, 2011. 7
[3] IDE Eclipse. Eclipse Foundation, 2007. 8
[4] Jens Eickhoff and Hans-Peter Roeser. Simulating space-
craft systems. Springer, 2009. 7
[5] Kristoffer Glembo, Sandi Habinc, and Jiri Gaisler.
GR712RC-The Dual-core LEON3FT System-on-
Chip Avionics Solution. 4
[6] K Großekatth¨ofer and Z Yoon. Introduction into
quaternions for spacecraft attitude representa-
tion. TU Berlin, 2012. 16
[7] Mordechai Haklay and Patrick Weber. Openstreetmap:
User-generated street maps. IEEE Pervasive Com-
puting, 7(4):12–18, 2008. 11
[8] Felix R Hoots, Ronald L Roehrich, and TS Kelso. Space-
track report no. 3. Colorado Springs CO: Air Force
Aerospace Defence Command, pages 1–3, 1980. 14
[9] TS Kelso. CelesTrak. https://www.celestrak.com/NORAD/
elements/, 2016. 14
[10] Giovanni Lapiccirella. Specification of a functional system
simulator for early design phase covering the multi-physics
aspects. University of Pisa, 2014. 10
[11] Christoph Lingg. Static Map. https://github.com/
komoot/staticmap, 2016. 12
[12] SM Parkes and Philippe Armbruster. SpaceWire: a
spacecraft onboard network for real-time commu-
nications. In 14th IEEE-NPSS Real Time Conference,
2005., pages 6–10. IEEE, 2005. 4
[13] Steve Parkes. SpaceWire Users Guide. STAR-Dundee
Limited, 2012. 5
[14] Steve Parkes and Chris McClements. Space Wire Re-
mote Memory Access Protocol. In DASIA 2005-Data
Systems in Aerospace, 602, 2005. 5
[15] Bjarne Stroustrup. The C++ programming language.
Pearson Education India, 1995. 8
[16] David A Vallado, Paul Crawford, Richard Hujsak, and
TS Kelso. Revisiting spacetrack report# 3. AIAA,
6753:2006, 2006. 15
[17] A Wiegand et al. ASTOS User Manual. Unterkirnach,
Germany: Astos Solutions GmbH, 2010. 17
[18] Olivier Zanon. The SimTG simulation modeling
framework a domain specific language for space
simulation. In Proceedings of the 2011 Symposium on
Theory of Modeling & Simulation: DEVS Integrative M&S
Symposium, pages 16–23. Society for Computer Simula-
tion International, 2011. 8
23
