FPGA based On-Board Computer System for the

“Flying Laptop” Micro-Satellite

Felix Huber(1), Peter Behr (3), Hans-Peter Röser(2), Samuel Pletner(3)
(1)
Steinbeis Transferzentrum Raumfahrt, Rötestr. 15, D-71126 Gäufelden, Germany, [email protected]
(2)
Universität Stuttgart, Institut für Raumfahrtsysteme, D-70550 Stuttgart, Germany, [email protected]
(3)
Fraunhofer Institute for Computer Architecture and Software Technology (Fraunhofer FIRST), Kekulé Str. 7, D-
12489 Berlin, Germany, [email protected], [email protected]

ABSTRACT sensors: a 3-axis magnetometer, a coarse sun sensor

system, four fibre optical rate sensors, a star tracker unit
The availability of new high density FPGA technologies
with two camera heads and a navigation system
enables innovative approaches to the architecture of on-
consisting of three GPS receivers.
board computer systems (OBCS) for demanding small
satellite applications. In the paper, we present the archi-
2 PAYLOAD SYSTEMS
tecture of a highly integrated satellite computer exploit-
ing the powerful features of Xilinx’s Virtex-II Pro For BRDF measurements, a multi spectral camera sys-
FPGA technology. The computing resources of the “Fly- tem is formed by three single cameras, one for each
ing Laptop” satellite are provided by a single OBCS channel (green, red and near infra-red). The ground
performing the control functions of a traditional satellite sample distance (GSD) of the 1024x1024 Pixel images
bus controller (SBC) as well as all tasks of the payload is 25m. The three cameras are mounted in a triangle
data handling and processing system (PDH). The mode on a reinforced carbon fibre composite plate for
unification of the different computing functions on better alignment and thermal stability. In addition, the
board the satellite onto a single but highly redundant star cameras are mounted on the same plate which gives
computer system results in clear-cut system structure precise orientation ability of the imaging system.
and provides a high degree of fault tolerance with min-
imal resource requirements. The second payload is a thermal infra-red (TIR) camera
system for images with a GSD of 50 m (320 x 240
The “Flying Laptop” micro satellite is under develop- Pixel). The TIR camera system uses a 50 cm Cassegrain
ment at the Institute of Space Systems at the Universität mirror, a relay optic and a micro-bolometer sensor.
Stuttgart. The primary mission objective is to demon- Therefore, no cooling is necessary which makes the sys-
strate and qualify new small-satellite technologies for tem small in size with low power consumption and very
the future projects. In addition, the three main scientific cost effective.
payloads of the satellite will allow performing a number
of ambitious earth observation experiments. According The third payload of the “Flying Laptop” satellite is a
to the primary mission objectives, the OBCS itself will high performance Ka-band communication system. The
be a subject for evaluations of its innovative concepts travelling wave tube (TWT) amplifier of the Ka-band
and for qualification of its underlying hardware. transmitter will deliver an RF transmission power of 57
W (170.5 W DC input) which is unique for a micro-
1 THE “FLYING LAPTOP” MICRO-SATELLITE satellite. The 50 cm primary mirror of the TIR camera
will also be used as the reflector dish for the Ka-band
The total mass of the cubical satellite body with 60 cm
communication system. This dual use of the 50 cm mir-
edge length will be around 100 kg. The power supply
ror is absolutely necessary to install the two complex
system is based on three solar panels two of which are
payload systems on a micro-satellite platform.
deployable. The triple-junction solar cells have an effi-
ciency of approx. 26%. The peak power consumption of
The Ka-band transmitter is expected to achieve a down-
the satellite will be about 300 W which will be delivered
link data rate of up to 500 Mbps during a ground station
by a battery pack consisting of 8 Lithium ion cells.
fly-over. In addition to evaluating the Ka-band transmit-
ter technology for future lunar missions, a number of
The attitude control system is designed to achieve a
scientific experiments to study the Ka-band wave
pointing accuracy of better than 2.5 arc seconds. In ad-
propagation are planned. The dominant effects to signal
dition, the planned scientific experiments require a very
attenuation at frequencies beyond 10 GHz are clouds
high manoeuvrability which both are challenging re-
and all kind of precipitation. In addition, gas absorption,
quirements for a micro-satellite. The “Flying Laptop”
and tropospherical refraction play an increasing role
satellite is three-axis stabilized by momentum wheels,
with higher frequencies. By measuring signal propaga-
which can be de-saturated using magnetic coils. The at-
tion and the atmospheric attenuation in the Ka-band fre-
titude motion is monitored by five different types of
quency range under different conditions the causal rela-
tions of different and combined effects will be systemat- hardware compiler tool chain is used to directly gener-
ically explored. ate the FPGA configuration file from the Handel-C de-
scription. This high level design approach maximally
Another experiment will use the Ka-band transmitter for exploits the functional parallelism of a design by map-
global precipitation measurements. The experiment is ping the functions of a system onto dedicated parallel
based on the strong correlation between the amount of operating hardware units.
precipitation and the difference of the attenuation to Ku-
and Ka-band signals. That's why the “Flying Laptop”
will also be equipped with a low power Ku-band trans-
mitter. The main advantage of this method is that the
measured amount of precipitation is independent of the
rain characteristic, e.g. the distribution of the raindrop
size. It is further planned to use the Ka-band transmitter
as a powerful radar source with can be received by
ground stations within a spot diameter of 25 km.

Further scientific experiments will be performed by us-

ing the three GPS receivers of the satellite navigation
system and the star sensor camera unit of the attitude
control system. More detailed descriptions of all sci-
entific mission objectives can be derived form the “Fly-
ing Laptop” website.

3 FPGA BASED ON-BOARD COMPUTER SYS-

TEM
The variety of scientific instruments and the broad range
of the scientific mission objectives are creating challen-
ging demands on the performance and functionality of
the on-board computing infrastructure. By following the
system-on-chip (SoC) design approach and by exploit-
ing the capabilities of the new high density FPGA tech-
nologies, the complete functionality of the OBCS could
be integrated onto a single printed circuit board (PCB)
of standard Euro card size (100mm x 160mm). The
highly integrated and configurable system-on-chip
(SoC) approach allows integrating most functions of the
node within a single chip and offers significant advant-
ages over a conventional system design especially for
the development of space computer hardware. The re-
duced number of components reduces weight and
volume of the OBDH system and results in better reliab- Figure 1: PCB of one node computer
ility figures. In addition, the SoC design provides higher
operation speeds and reduced power consumption due In general, when designing an OBCS based on COTS
to on-chip vs. off-chip connections. By exploiting the components, the design strategy has to be based on the
high degree of parallelism within the FPGA fabric lower assumption that, because of the single event radiation
clock frequencies are required which further can reduce effects (SEE), failures within the system must not be
the power consumption significantly. Another advantage considered as an exception but, in principle, as normal
of the programmable FPGA technology is its high flex- operation. Such a design principle requires fault toler-
ibility that allows for in-orbit reconfiguration of the ance features to be added to the system. Redundancy
hardware functions e.g. to adapt the system to changing and parallelism allow for realizing highly dependable
mission requirements or to update the FPGA configura- systems even if individual components do not fulfil the
tion to fix design errors. requirements defined for space qualified technology.

Another unique feature of the OBCS is the software-less Paying respect to the risks of the COTS approach, the
implementation of all control and processing functions. OBCS is realized as a highly redundant replicated four-
The complete functionality of the OBCS is modelled in lane computer system. The four identical computer
Handel-C, a C-based design language, and Celoxica’s nodes of the OBCS form a synchronous symmetric
multi computer system synchronously executing in a As shown in the block diagram of the OBCS, an addi-
master/monitor configuration. In principle each single tional component called the command decoder and vot-
node is able to execute all functions and to perform all ing unit (CDV) is connected to the four computing
control tasks of the OBCS. This implies that all nodes nodes. The specific functions of the CDV are essential
must be connected to all instruments and devices of the for the viability of the whole satellite; therefore the
satellite. In addition, direct communications can be per- CDV is implemented by a space qualified radiation hard
formed between the nodes to efficiently exchange con- FPGA device. The reliability of the CDV is assumed to
trol and status information. be sufficiently high, thus no replication is required. The
CDV includes the mass memory, provides an interface
The main advantages of the four node approach are:
to the receiver of the up-link, and is performing the fol-
• extended lifetime of the OBCS in the event of a per- lowing main tasks:
manent error in the node hardware
• (CCSDS) decoding of the uplink data stream
• short outage times (higher availability) in the event
• Forwarding of commands to the node computers
of SEU induced errors
• Voting on the checksums, generated by the node
• redundant computations allow for voting resulting in
computers
higher reliability
• Selecting the master node (based on voting results)
Due to the SEU sensitivity of the SRAM-based FPGA • Enforce reset/recovery or power cycling of a faulty
technology arbitrary errors of the node computer must node
be expected. The FDIR strategy of the OBCS is based • Isolating permanently failing nodes (by power off)
on: • writing new configuration data into the EEPROMS
• Error detection by comparing the checksums gener- of the nodes
ated by the replicated nodes
Replicating the nodes of the OBCS to ensure sufficient
• Error isolation by voting on the checksums and se-
high availability requires that each node is able to ac-
lecting a node which provided the correct checksum
cess the payload instruments and all other devices con-
to drive the output lines
trolled by the OBCS. Sharing of a device interface re-
• Error recovery by enforcing a faulty node to perform
quires either dedicated point-to-point connections or a
the reset/restart procedure and subsequently re-syn-
shared bus system. In the OBCS of the “Flying Laptop”
chronize with the other nodes
the four node computers share the bus lines to connect
Within this straight forward FDIR strategy, error hand- to the peripherals and dedicated connections are used
ling mainly relies on the implementation of the robust between the nodes and the CDV. The block diagram of
restart capability. It must be ensured, that after resetting the OBCS in Fig. 2 shows the shared I/O bus to the
a node, the FPGA can reliably be configured by loading devices, the dedicated connections between the four
a valid configuration into the configuration memory. nodes, the CDV, and the isolating node interfaces.
This task is performed by a dedicated configuration con-
troller (CC) implemented in a separate FPGA and a ra- The redundant nodes in general are receiving the same
diation hard configuration EEPROM. digital inputs and are executing the same functions, thus
producing the same results. The CDV selects by dedic-
ated control lines one of the four nodes to execute in the
FPGA FPGA FPGA FPGA
Onboard Onboard Onboard Onboard master mode. Only the master node is able to drive the
Computer Computer Computer Computer output lines to the devices of the satellite. The CDV per-
1 2 3 4
forms the voting function on checksums generated by
all active nodes. For the checksum information of a
node can not only be received by the CDV but also by
Isolating Buffer Isolating Buffer Isolating Buffer Isolating Buffer
the three other nodes a Byzantine voting scheme may be
implemented as an alternative to the centralized voting
by the CDV.

Nodes delivering a wrong or no result are assumed to be

faulty and are enforced to perform the reset/restart func-
tion. If the current master fails to produce the correct
Satellite checksum, the CDV will select another node as master
Command
Payload and
Decoder which will perform the correct output. To avoid accu-
Peripheral
and
Electronics mulation of latent errors in the master node, the CDV
Voter
may cyclically select a new master while enforcing the
Figure 2: Block diagram of the OBCS old master to execute the reset/restart function.
The implementation of the master/monitor principle on the input buffers are always enabled, the output buf-
within the four node system implies the following states fers to shared bus lines by default are disabled through
of the nodes that must be determined by the CDV: pull up/down resistors. Only the output drivers of the
master node will be enabled by the CDV via the direct
• Inactive (power off, isolated from the shared bus master monitor control lines.
• Master (selected to drive the output lines of the
shared I/O buses)
• Monitor synchronized (runs synchronously, provides
correct checksums, may be selected as a new master)
• Monitor not synchronized (performing the restart/re-
covery function, cannot be selected as a new
master).
4 NODE COMPUTER
The highly integrated node computer is based on the
VIRTEX-II Pro FPGA XC2VP50 of Xilinx. All control
and data processing functions of the satellite, which are
not directly executed by the CDV, are implemented
within this FPGA. Figure 3: Block diagram of the node computer

The block diagram in Fig. 3 shows the Virtex-II Pro 4.2 Configuration Controller
computing device, the dedicated configuration control- In a system-on-chip design based on the Xilinx Virtex-II
ler (CC) and the I/O interface logic. The Virtex-II Pro Pro FPGA, after power-on, first the system itself must
has access to four parallel operating banks of fast SS- be configured by initializing the FPGA. Thus, the initial
RAM for intermediate results and to three banks of system configuration must be performed by dedicated
DDR SDRAM to be used for application data or option- hardware. Further, the straight forward FDIR strategy of
ally as program memory of the PowerPC core. Addi- the OBCS mainly relies on the implementation of a ro-
tional memory devices of the node are three banks of bust restart capability within the nodes. It must be en-
NOR flash for multiple versions of the Virtex-II Pro sured, that after resetting a node the Virtex-II Pro FPGA
configuration, the radiation hard EEPROM for the con- can reliably be configured by loading a valid configura-
figuration of the configuration controller, and a NAND tion into the configuration memory. To realize this vital
flash memory for permanent storage of application data function of the nodes a dedicated configuration control-
and optionally of the PowerPC code. ler (CC) was implemented within in a separate FPGA
(Spartan-II). The configuration of the Spartan-II FPGA
4.1 Node interface is assumed to be fixed and is stored in a radiation hard
The availability and reliability of the redundant OBCS serial EEPROM.
highly depends on the feature to securely isolate a faulty
node so that it cannot obstruct the correct operation of Multiple versions of the configuration file for the Vir-
the rest of the system. As shown in the block diagram all tex-II Pro FPGA can be held in three physically separate
I/O connections are implemented by special isolating NOR-Flash memory banks. This allows for secure in or-
buffer devices that completely disconnect all interface bit reconfiguration of the satellite functions. The CDV
signals from the shared I/O and communication buses if has access to the flash memories via the CC either to
the CDV switches off the power supply of a node. By load new versions of configuration data or to restore a
this, individual nodes can be switched on and off ac- corrupted configuration file. In addition, the configura-
cording to the current mission requirements and also to tion data can be directly streamed from CDV into the
isolate a faulty node containing a permanent hardware configuration memory of the FPGA. Loading the flash
error. memories under control of the CDV ensures that a node
always can be newly configured even if all configura-
In addition to the isolating feature of the bidirectional tion data in the flash memory has been corrupted. This
buffer devices, control inputs allow to enable or disable is true as long as there is no permanent hardware error
the input and output buffers separately. In addition, the in the node and the configuration of the CC in the serial
output enable control signal of the isolating buffer EEPROM is not corrupted.
devices is used to control the output drivers of the nodes
such that on shared bus lines only the selected master After power-on or RESET, first, the CC is configured
node is able to drive the output lines. While after power- from the configuration data in the serial EEPROM.
Then the CC will configure the VIRTEX-II Pro FPGA The communication between the CDV and the CC is
by transferring the configuration file stored in the performed via a serial UART interface by a specific reli-
memory bank Flash 0. The complete configuration of able protocol. Further, the CC directly can notify the
the node from Flash 0 takes only about 200 ms. If the CDV via a number of dedicated status lines, e.g. to sig-
configuration file stored in Flash 0 is corrupted or a dif- nal successful initialization of the Virtex-II Pro FPGA or
ferent configuration has to be loaded, the CDV - by ap- to indicate an over-current or over-temperature condi-
propriate commands - can enforce the configuration tion or to inform the CDV about a self-reset of the node.
from another memory bank or to load the configuration
To flexibly exchange housekeeping data and other con-
file directly in the streaming mode.
trol and status information between the CDV and the
Virtex-II Pro FPGA the Spartan-II FPGA includes a re-
In addition to the CC function for the Virtex-II Pro
gister file. While the Virtex-II Pro can only perform read
FPGA the Spartan-II FPGA is used to implement the
operations, the CDV can use specific commands to per-
command and status interface to the CDV, the logic to
form read and write operations on the register file via
gather and store the housekeeping data of the node, and
the CC. Because neither the CDV nor the CC is in-flight
an independent watch dog function. The block diagram
reconfigurable a fixed set of commands had to be
in Fig. 4 shows the main functions and interfaces of the
defined. But by using the communication mechanism
Spartan-II FPGA.
via the register file, new commands can still be defined
for new versions of the Virtex-II Pro configuration.
These additional commands will be transparently for-
warded by the CDV and written into specific locations
of the register file.
To allow for mutual monitoring of the two FPGAs
(Spartan-II and Virtex-II Pro) within the node, a watch-
dog timer is implemented in each FPGA. The watchdog
outputs of both FPGAs are connected to the reset signal
of the node. In addition, the CDV is informed about the
event of self-reset of a node via a dedicated status sig-
nal. The periodic generation of the signal, which retrig-
gers the external watch-dog timer is based on the com-
bination of internal alive signals generated by all the
controllers within the FPGA. Such an effective watch-
dog implementation ensures that all unexpected node
failures caused by unspecific errors will result in a
watch-dog time out and a subsequent reset and re-ini-
tialization of the faulty node.
The different error detection mechanisms implemented
within the Spartan-II FPGA are working independent of
the general voting mechanism of the CDV. They signi-
ficantly improve the reliability and availability of the
Figure 4: Block diagram of the Spartan-II FPGA OBCS because serious failures during the configuration
of a node are detected immediately and will automatic-
The PicoBlaze Micro-Controller IP core (MC) is used to ally restart the initialization procedure of a node.
flexibly implement the different functions within the
Spartan-II FPGA. The firmware of the PicoBlaze con- 4.3 Main FPGA
troller is stored in the Block RAM of the CC FPGA. To
The Virtex-II Pro FPGA holds the complete ACS,
improve the reliability of the CC the PicoBlaze control-
TM/TC processing, real time image processing of the
ler is duplicated executing in a master/checker
configuration. By sharing all input lines and buses, it is RG, NIR and TIR cameras and generation of scientific
downlink data for the S- and Ka-Band. All these func-
enforced that both MCs receive the same input data. By
tions use a dedicated individual area within the FPGA
comparing the output data of both controllers, each fault
and run strictly in parallel. Thus, no race conditions or
can be detected by a mismatch of any of the output sig-
nals. This straightforward mechanism is completely interrupt latencies exist and allow for the real-time syn-
chronous operation. This is accomplished by a direct
transparent to the firmware and it can be ensured that all
implementation of the algorithms in hardware without
possible SEU errors in the PicoBlaze section of the CC
the need for an operating system using the Handel-C
FPGA will be detected immediately.
compiler.
All four nodes execute the same algorithms in parallel at provides and by eliminating common sub expressions.
a clock cycle precision and in addition to their ACS and Moreover, the compiler can perform a re-timing optim-
scientific output, a hash checksum of the internal state isation in order to allow for higher clock speeds.
variables is permanently presented via dedicated cross
The basic properties of the Handel-C compiler are
strapped lines to each of the other nodes. Every node is
checking the hash codes of the other nodes against its • All ANSI-C Elements are synthesized
own values and presents the result to the other nodes • One source line is executed per clock cycle
and the CDV in order to identify a faulty node. In prin-
• Fixed deterministic timing down to clock cycle res-
ciple, this checking could be performed after every
clock cycle but could also be performed only immedi- olution
ately before the new ACS commands are sent out to the • True parallelism
actuators. • Any bit width for variables
After a reset, the algorithms in a node resynchronise to • External RAM or other H/W included transparently
the current state vector by reading in the state variables • Same code is used for PC simulation and synthesis
of the other nodes which are also exchanged periodic-
ally. After some iterations of the ACS, the node is syn- An additional Platform abstraction layer (PAL) hides
chronised again and signals this to the CDV, after which hardware specific functions from the user's main code
it is again included in the voting process. and is pulled in at link time before synthesis. For each
dedicated hardware platform, a PAL library functions as
In parallel to the ACS, the scientific functions are ex- a wrapper to the hardware specific implementation
ecuted. This is mainly the clocking of the CCD cameras (Platform support layer, PSL) and after synthesis
to read in the pixels and a (pre-)processing of the data. eventually evaluates to nothing. Thus, no extra penalty
This includes the rotation and scaling of the raw images is payed by the insertion of this extra layer. On the hand,
using real-time edge detection and summing of several the user code in then independent from the underlying
images in order to achieve a better S/N ratio. The image hardware and can be compiled directly for different
processing functions make use of pipelined library func- targets including simulation. For the simulation, the
tions that are are part of the Handel-C compiler and design is also fully synthesized but the primitives of the
store intermediate results in the SSRAM. Each of the FPGA are then simulated by a normal C program that
four banks of the SSRAM can be accessed independ- runs under the control of the compiler. In this mode, the
ently of the others at a sustained data rate of 533 synthesized design can be step-by-step examined on a
Mbytes/s. Thus, while one image is being processed, a clock cycle level with full stimulation of external I/O
new image can already be read in from the cameras al- signals.
lowing to use the cameras at their maximum clock
speed. The processed images will either be sent directly The speed gain over a software based implementation is
to the downlink modems or will be stored in the CDV, enormous, typically a speed gain of 40-100 is achieved.
where a mass memory will be located. In order to On the other hand, the FPGA could run at a much
achieve the best possible scientific outcome of the im- slower clock speed in order to save power. The currently
ages, only processing that would have to be performed implemented parts of the ACS include the safe mode
on the ground anyhow before the data can be used will and de-tumble mode that, for safety reasons, only make
be performed. However, due to the high processing use of the magnetometers and magnetic torquers. Each
speed of the node, a real-time classification of the pixels of the algorithms uses roughly 1.1% of the FPGA's gate
could be also performed according to pixel values with equivalences including debug code to feed in simulated
an artificial colouring of detected areas. orbital propagation data for stimulus and performs
20000 iterations per second, which is well beyond the
5 HANDEL-C PROGRAMMING MODEL design cycles of 10/s given the speed of the star tracker
The nodes execute their functions directly in hardware cameras.
without the need for a micro processor or an operating The expected speed of the main ACS algorithm using
system. This is made possible by the use of the Handel- the full set of sensors is in the order of 1000-2000 itera-
C programming language which uses a C-like syntax to tions per second, leaving enough time to perform a cross
describe hardware performing complex algorithms. The checking of the data with the other nodes before the new
Handel-C compiler performs the complete synthesis of actuator commands are sent out to the buses.
the design directly from the C source code without the
need for RTL programming such as VHDL. The advant-
age of this direct conversion is that the compiler can
perform a global optimisation on the structure and typic-
ally shrinks the design by 50% by making use of know-
ledge of the internal primitives that a certain FPGA