MOVE-II THE MUNICH ORBITAL VERIFICATION EXPERIMENT II

Abstract

MOVE-II (Munich Orbital Verification Experiment II) is a 1 Unit CubeSat currently under development at the Technical University of Munich (TUM). This paper reports on the technical as well as the organizational advancements of the project. With overall more than 130 students involved so far, the project is currently in Phase D, with the launch of the satellite scheduled for early 2018. For communication purposes, MOVE-II will utilize a novel robust and efficient radio protocol for small satellite radio links, called Nanolink, both on an UHF/VHF transceiver and an S-Band transceiver. The usual power restrictions of the 1U envelope are overcome by four deployable solar panels, which are held down and released by a reusable shape memory mechanism. This allows repeated tests of the mechanism and true test-as-your-fly philosophy. As its scientific goal, the MOVE-II CubeSat will be used for the verification of novel 4-junction solar cells. With a footprint of 10x10 cm, the payload consists of one full size solar cell (8x4 cm) and five positions (each 2x2 cm) for the corresponding isotype solar cells. As opposed to its predecessor mission, MOVE-II will be the first CubeSat of TUM utilizing a magnetorquer based, active attitude determination and control system (ADCS). The system consists of five Printed-Circuit-Boards with directly integrated magnetic coils, forming the outer shell of the spacecraft, and one so-called ADCS Mainboard, located in the board stack of the satellite. Each Sidepanel has its own microcontroller and is connected to the ADCS Mainboard with one of two redundant SPI buses. From an organizational point of view, we tried to increase the reliability of MOVE-II by fast prototyping and releases as well as enhanced hardware-in-the loop tests. We will present the application of agile software development in the project as well as methods that we applied to assure reliability on system level. For that purpose a Reliability Growth Model, based on our CubeSat Failure Database, was adapted for the project.

Full text

(Preprint) IAA-AAS-CU-17 -06-05
MOVE-II THE MUNICH ORBITAL VERIFICATION EXPERIMENT II
Martin Langer*
, Florian Schummer*, Nicolas Appel*, Thomas Gruebler*,
Katja Janzer*, Jonis Kiesbye*, Lucas Krempel*, Alexander Lill*, David
Messmann*, Sebastian Rueckerl*, Michael Weisgerber*
MOVE-II (Munich Orbital Verification Experiment II) is a 1 Unit CubeSat cur-
rently under development at the Technical University of Munich (TUM). This pa-
per reports on the technical as well as the organizational advancements of the
project. With overall more than 130 students involved so far, the project is cur-
rently in Phase D, with the launch of the satellite scheduled for early 2018. For
communication purposes, MOVE-II will utilize a novel robust and efficient radio
protocol for small satellite radio links, called Nanolink, both on an UHF/VHF
transceiver and an S-Band transceiver. The usual power restrictions of the 1U en-
velope are overcome by four deployable solar panels, which are held down and
released by a reusable shape memory mechanism. This allows repeated tests of
the mechanism and true test-as-your-fly philosophy. As its scientific goal, the
MOVE-II CubeSat will be used for the verification of novel 4-junction solar cells.
With a footprint of 10x10 cm, the payload consists of one full size solar cell (8x4
cm) and five positions (each 2x2 cm) for the corresponding isotype solar cells. As
opposed to its predecessor mission, MOVE-II will be the first CubeSat of TUM
utilizing a magnetorquer based, active attitude determination and control system
(ADCS). The system consists of five Printed-Circuit-Boards with directly inte-
grated magnetic coils, forming the outer shell of the spacecraft, and one so-called
ADCS Mainboard, located in the board stack of the satellite. Each Sidepanel has
its own microcontroller and is connected to the ADCS Mainboard with one of two
redundant SPI buses. From an organizational point of view, we tried to increase
the reliability of MOVE-II by fast prototyping and releases as well as enhanced
hardware-in-the loop tests. We will present the application of agile software de-
velopment in the project as well as methods that we applied to assure reliability on
system level. For that purpose a Reliability Growth Model, based on our CubeSat
Failure Database, was adapted for the project.
INTRODUCTION
MOVE-II, the Munich Orbital Verification Experiment II, is the second satellite of the CubeSat
program MOVE of the Technical University of Munich (TUM). The single-unit Unit CubeSat is
being developed since April 2015 and will be launched into a 575 km sun-synchronous orbit in early
2018. Being a mission with educational, tech-demo as well as scientific goals, we will report on the
technical as well as organizational advancements of the project. The first chapter will introduce the
MOVE satellite program of TUM. In the second part, a technical description of the satellite will be
followed by a detailed presentation of the technical advancements of the mission. The third chapter
deals with the organizational advancements, in particular with methods for reliability assurance and
risk mitigation in MOVE-II. In the last chapter, we conclude with the implications of this work and
give an outlook.
*Institute of Astronautics, Technical University of Munich, Boltzmannstrasse 15, 85748 Garching, Germany, mar-
tin.langer@tum.de
1

THE MOVE SATELLITE PROGRAM
In 2006, the Institute of Astronautics (LRT) started the CubeSat program MOVE with the am-
bition of designing and building a single-unit CubeSat verification platform, called First-MOVE1
(see Figure 1). The main goal of the program since then has been the hands-on education of un-
dergraduate and graduate students. When First-MOVE was launched in late 2013, more than 70
students of different faculties had participated successfully in the project, with numerous educa-
tional and programmatic lessons learned. We operated First-MOVE successfully for one month,
after which a major malfunction occurred in the satellites’ on-board computer, leaving the satellite
in a mode where it is only transmitting continuous wave (CW) beacons since then. The short mis-
sion duration prevented us from obtaining significant results from the solar cell experiment (primary
payload objective) and from receiving photos from the on-board camera (secondary payload objec-
tive). Nevertheless, major in-house technology and spaceflight processing developments as well
as many educational lessons learned while using a CubeSat for teaching purposes in a university
environment were important results of the First-MOVE mission.2
Figure 1: First-MOVE in Launch Configuration (left) and Deployed Configuration (right)
Since April 2015, we are continuing the hands-on student education at LRT with a single-unit
CubeSat called MOVE-II.3With more than 130 students involved so far, MOVE-II is currently
awaiting shipment to the launch provider, with its launch scheduled for spring 2018. From the
beginning, we tried to apply the lessons learned of First-MOVE and other CubeSat teams in the pro-
gram: We focused on early testing and careful characterization of complex subsystems, similar to
the Bread-Brass-Silver-Gold approach of the Air Force Research Laboratorys University Nanosatel-
lite Program, and built prototypes and brass-boards often and early.4, 5 Due to recent advancements
in additive manufacturing as well as custom-made thermal prototypes of all subsystems, we were
able to conduct individual functional and performance tests under a variety of relevant environments
early on, followed by a long phase of flat-sat style and integrated system level tests. The necessity
for longer, continuous operation tests of the fully integrated system is a lesson learned not only from
First-MOVE, but a general lessons learned from CubeSat development worldwide.6, 7 To ensure re-
liable and successful operations of MOVE-II, we focus on system level tests, carefully monitor the
2

bugs and errors on system level and evaluate the remaining testing time needed and the number of
not detected bugs in the system. For that purpose a Reliability Growth Model, based on our CubeSat
Failure Database, was adapted for the project.
From an educational point of view, we tried to counter the drain of knowledge due to students
leaving the project, an obstacle many university-based CubeSat teams experience, by establishing
a voluntary, dedication-based approach in our project. Students are not just assigned to a specific
thesis topic, but to a specific subsystem where they are encouraged to stay involved in the project
preferably over the full project time. All involved students organize themselves in a LRT-associated
student organization (Scientific Workgroup for Spaceflight and Rocketry, WARR8) where their com-
mitment to the project is out of interest and dedication, rather than short-term academic credit, lead-
ing to less team fluctuations. The need for the inclusion of external experts was another important
lesson learned from First-MOVE. We believe that expert knowledge of senior engineers enhances
both hands-on education of students in different subsystems as well as technical quality, preventing
pitfalls during the design phase of the satellite. More than 40 external experts were involved in the
PDR and CDR of the satellite. Despite the agile approach in some subsystems, one programmatic
lesson learned of First-MOVE was, that CubeSat development needs more or less the same number
of technical reviews as bigger missions, despite its small size. The reviews are not only important
as a gate for technical maturity, but also vital for having short-term goals for the student team.
THE MOVE-II CUBESAT
MOVE-II is a 1.2 kg, single-unit CubeSat in compliance with the CubeSat Design Specification.9
Being limited to single-unit size during launch, the satellite, as its predecessor, uses deployable
solar panels to overcome the power limitations of the single-unit envelope10 (see Figure 2). The
four deployable solar panels are made out of carbon-fire reinforced plastics and are equipped with
two 4-junction solar cells each. A reusable shape memory mechanism holds down the panels during
launch and releases them after deployment. The mechanism, already tested on a sounding rocket,
allows repeated tests of the mechanism and true test-as-you-fly philosophy.11
Figure 2: MOVE-II in Launch Configuration (left) and Deployed Configuration (right)
In the following, we will explain the satellites’ main subsystems using the explosion drawing
depicted in Figure 3. The core of the satellite is an electronic stack of six printed circuit boards
(PCBs), plugged together using PC/104 sockets. Additionally, the so-called Toppanel, which houses
the payload of the mission, is a PCB stacked on top of the electronic stack connected via an adapter
3

board. The Toppanel houses one full size solar cell (8x4 cm) and five positions (each 2x2 cm)
for the corresponding isotype solar cells as the payload (PL) of the mission as well as electronics
and actuators for the attitude determination and control system (ADCS). Thus, the Toppanel is also
part of the ADCS system. ADCS consists of five Printed-Circuit-Boards with directly integrated
magnetic coils, forming the outer shell of the spacecraft, (the so-called Sidepanels being the other
four besides the Toppanel). MOVE-II will be the first CubeSat of TUM utilizing a magnetorquer
based, active ADCS. The so-called ADCS Mainboard, located in the middle of the board stack of
the satellite, controls the current of the magnetic coils of the other five panels and of its own, sixth
coil. Each Sidepanel has its own microcontroller and is connected to the ADCS Mainboard with one
of two redundant SPI buses. For communication purposes, MOVE-II will utilize both an UHF/VHF
transceiver and an S-Band transceiver. The antennas of the UHF/VHF transceiver are also hold
down and released by the redundant shape memory mechanism. For the S-Band channel, a patch
antenna is located at the bottom of the satellite.
Figure 3: Explosion Drawing of MOVE-II
4

Communication and Protocols
The MOVE-II communication system (COM) consists of two independent systems: a continu-
ously operating UHF/VHF system (see Figure 4a) and an auxiliary S-Band system (see Figure 4b).
The UHF/VHF system provides an attitude independent, highly available link. This is the main
COM link used to bidirectionally transmit all data, including TT&C. This link has a data rate of up
to 25 kb/s in both directions. For higher bandwidth, the S-Band system can provide up to 3 Mb/s
additional downlink data rate and 150 kb/s on the uplink.
(a) UHF-VHF Transceiver (b) S-Band Transceiver
Figure 4: MOVE-II Transceivers
The layer 2 protocol Nanolink provides quality of service features for user applications. This
includes guaranteed data rates for different streams and use cases. Additionally a automatic repeat
request protocol ensures delivery and improves link quality for upper layer protocols. Nanolink
is specifically tailored for moderate signal quality and efficiency in low bandwidth-delay applica-
tions.12
The design goal of the physical layer is to maximize data rate while retaining a comfortable
link margin. The limiting factor in UHF/VHF is bandwith, and power in S-Band, respectively.
The resulting design uses phase-shift keying modulation, and powerful Accumulate, Repeat-by-4,
and Jagged Accumulate (AR4JA) Low-Density Parity-Check (LDPC) codes by the Committee for
Space Data Systems (CCSDS) on the downlink. The parameters of the system are adapted to fit the
requirements of the respective link. It is possible to change these parameters at runtime since the
whole signal processing is implemented within an field programmable gate array (FPGA). An FPGA
offers the possibility for highly parallel, complex signal processing and advanced coding schemes.
The digital signal processing within the FPGA utilizes complex I/Q samples which are exchanged
with dedicated radio frequency hardware. This enables the use of virtually any modulation on up-
and downlink. The FPGA image can be reprogrammed in orbit, allowing to change the modulation
and coding arbitrarily. In order to achieve a small footprint the design relies on highly integrated
components.
5

Special focus during selection of the components were power consumption and reliability. Au-
tomotive grade commercial of the shelf (COTS) components offer great value compared to space
grade or industrial/consumer grade components. Additionally, they are qualified for a wider temper-
ature range than consumer grade components. For key components the radiation tolerance was also
taken into account. An inherently radiation tolerant magnetoresistive random-access memory was
selected for the FPGAs configuration storage. Both transceivers were validated as part of the TDP-3
Vanguard experiment on BEXUS 22 in October 2016. During this mission the communication link
was tested in the stratosphere over a distance of 270 km.13
Payload
As its scientific goal, the MOVE-II CubeSat will be used for the verification of novel 4-junction
solar cells under space conditions. On top of the CubeSat one full size solar cell (8x4 cm2) and
four corresponding isotope cells (2x2 cm2) are located . An additional isotope cell will be mounted
without a cover glass to study the resulting accelerated degradation process. In Figure 5 the circuitry
of the PL on MOVE-II is schemed. The PL of MOVE-II measures the current-voltage curve of each
solar cell. For these measurements, all solar cells are connected for 4-wire sensing. The voltage
at the solar cell is measured between the contacts and the actual current of the cell is measured as
a voltage drop across a shunt resistor. For the sweep of the current-voltage curve, a MOSFET is
added to the circuit which is used as a variable load. On the backside of the PL board, temperature
sensors are attached behind each solar cell. Furthermore, a sun sensor evaluates the actual sun angle
seen by the solar cells.
Figure 5: (a) Circuit for the measurement of the current-voltage curve of solar cells on MOVE-II
(b) Top side of the CubeSat with solar cells of the payload and one sun sensor
For the verification of the PL measurements, various tests were conducted. The accuracy of the
measuring circuit on the final flight model was evaluated with a Keithley 2400 sourcemeter. The
observed uncertainties were less than ±0.1% for the voltage measurement and less than ±1%for
the current measurement. A significant deviation of the stated accuracy can be evaluated with a self
test of the PL, which is regularly performed before the start of the measurements. The setup proved
functional and measured reliably in vacuum under the expected illumination in space. Furthermore,
all components of the measuring circuit are radiation tolerant and should not exhibit degradation
effects before 10 krad.14
6

Attitude Determination and Control System
As mentioned before, the hardware of the ADCS consists of six PCBs in total. Figure 6 illustrates
the arrangement of all PCBs. The ADCS mainboard, referred to as Mainpanel, is the central unit
of the hardware and is located in the board stack and connected to the remaining satellite by a
PC/104 interface. Each Sidepanel and the Toppanel are connected over two individual SPI buses
to the Mainpanel. Each panel features a PCB integrated magnetorquer coil, a corresponding coil
driver, a microcontroller and a three-axis magnetometer and a three-axis gyroscope. In addition,
all Sidepanels and the Toppanel are equipped with a sun sensor. The measurements of the sensors
are independently acquired and pre-processed on each panel. These data are accumulated on the
Mainpanel and used for the computation of the attitude determination and control algorithms.15
1 Toppanel (shared with payload)
1 Mainpanel (in stack)
4 Sidepanels
Figure 6: Toppanel, Mainpanel and Sidepanels of the ADCS on the MOVE-II CubeSat
The MOVE-II mission requires two main control strategies on which the design of the ADCS
system is based: Detumbling and sun pointing. After ejection from its deployer, the satellite may
experience undesired high angular velocities. A simple and robust B-dot controller, which has
been implemented on several CubeSat missions, is used to slow down the rotation of the satellite.
To ensure scientific operation, the top side of the satellite is directed towards the sun by using a
linear model-based control approach. Since the Toppanel is equipped with payload and solar cells,
sun pointing provides enough power for the satellite and maintains the orientation of the payload.
Moreover, an Extended Kalman Filter (EKF) is implemented to estimate the satellite’s attitude by
using a provided set of sensors.16
Investigating the system functionality and performance requires appropriate testing environments.
The challenges of testing our ADCS yield to the development of an ADCS prototype and a Hardware-
in-the-Loop setup. They are presented in detail in the chapter ”Low-cost ADCS testing environ-
ment”.
7

Thermal Design
As MOVE-II was designed with a high power consumption due to two transceiver boards and the
six coils build in the sidepanels for attitude control of the satellite, a prototype which represents the
overall thermal balance of the system was build early on in the design phase. The thermal prototype
(see Fig. 7) consisted of an aluminum frame from an earlier design iteration and several two-layered
PCB’s representing each board of the different subsystems. To simulate the heat loads on the boards,
heating foils and resistors were mounted on the correspondent places of the future heat dissipation
on the PCBs.The prototype was then put into LRT’s thermal vacuum chamber (TVAC) to determine
which board stacking order provides the least amount of thermal stress on the battery, the most
critical system with the most stringent operational temperature limits (between -10°C and +50°C).
Figure 7: Thermal Prototype of MOVE-II and TVAC of LRT
After some iterations the best stacking order with regards to the temperature of the battery was
determined. It resulted in the S-Band transceiver, the one with the most heat dissipation, being the
lowest board, followed by the UHF/VHF transceiver, the ADCS mainpanel, the Electrical Power
System (EPS) board with the battery stack and finally the Command and Data Handling (CDH)
board on top of the PCB stack. The ADCS Mainpanel and the CDH board dissipate less heat
thus serving as an insulation from the high heat dissipation of the UHF/VHF transceiver and the
Toppanel which is, ideally, in direct sunlight all the time due the sunpointing requirement of MOVE-
II. Besides the determination of the best stacking order, testing of incoming subsystem PCBs was
one of the major tasks of THM out of lessons learned from First-MOVE. As PCB hardware arrived,
it was put into the TVAC and equipped with external thermocouples to detect faulty craftsmanship
and to get an impression of its thermal behavior in vacuum.
With the acquired knowledge during the TVAC tests with the thermal prototype, the initial ESA-
TAN model, which represented the geometry coarsely the geometry of MOVE-II and used material
property values found in literature, was refined. Thermal conduction through the PC/104 and the
standoffs could be adjusted,and optical and material properties corrected. After testing the subsys-
tem hardware in the TVAC, the initial power budget was updated and the changes implemented in
the ESATAN model. Several orbital simulations according to the concept of operation in orbit were
performed. These simulations calculated battery temperatures which were close to the upper limit
of the operational temperature. To lower the battery temperature additional simulations with a white
coating on the Sidepanels (initially green) were conducted. The results showed that just by changing
the optical properties of the Sidepanels, the battery temperature was reduced by around 12°C, thus
8

increasing the margin to the upper operational temperature threshold.
First thermal balance tests on the Engineering Model (EM) provided new insights with regard
to material properties, to thermal coupling between subsystems and structure and to the thermal
behavior of the whole satellite. These informations were used for the correlation of the ESATAN
model. The geometry was refined by adding the cages of the transceiver boards and adjusting the
mesh of some boards for a better representation of hot spots. An overall accuracy of ±10°C was
achieved. The most critical part, the battery, achieved in the worst cold case (assuming no internal
heat dissipation) and the worst hot case (active uplink on the UHF/VHF transceiver) temperatures
of 1.8°C and 25°C. With a margin of ±10°C the battery is still within the operational temperature
limits. The simulated temperature distribution during an overpass with an active UHF/VHF uplink
can be seen in Fig. 8).
Figure 8: Calculated temperature distribution with an active UHF/VHF transceiver uplink of the
MOVE-II ESATAN model with inner board stack
After all the hardware components were finished, the engineering model (EM) was built and
tested in the laboratory and in the TVAC. In the TVAC thermal balance tests and thermal cycling
tests were conducted. For the thermal balance tests different operating modes of the satellite were
active until each mode reached a thermal steady state. These tests were conducted at a warm as well
as a cold environmental temperature. Thermal cycling was done to expose the satellite to thermal
stress and find faulty craftsmanship. Hereby several hot, with maximum heat dissipation on the
satellite, and cold cycles, with minimum heat dissipation on the satellite, were performed. The
same test procedure in the TVAC is currently ongoing on the flight model (FM).
9

RELIABILITY ASSURANCE AND RISK MITIGATION IN MOVE-II
The success story of CubeSats is currently jeopardized by many dead-on-arrival (DOA) and in-
fant mortality cases.6, 7 Applying lessons learned of First-MOVE, other CubeSats, but also using
methods from terrestrial applications, we tried to reduce the risk of facing early failure in MOVE-II.
In the following, we will report on selected methods, applicable also for other CubeSat teams: Addi-
tive manufacturing can help mitigate integration errors and can provide fast access to ground support
equipment (GSE). We chose Agile Software Development as the most suitable method for develop-
ing our CDH software, since we wanted to not only test our hardware but also the software early
and rigorously. A Low-cost hardware testbed for ADCS as well as an ADCS hardware-in-the-loop
testbed are examples of low-cost test equipment, based on open-source single-board computers, that
were created to test the ADCS in a test-as-you fly manner. Finally, we will report on our ongoing
effort to create a Reliability Growth Model, based on results of system level tests, and how we
maximize system level testing time and heterogeneity of tests vectors in MOVE-II.
Additive Manufacturing for Risk Mitigation
We manufactured a 3D printed structural model of MOVE-II early in the design process (see
Fig. 9). Being a mechanical representation of satellite, it had no electrical functionality. The inten-
tional purpose of this prototype was to prove that our satellite can be integrated and to determine the
final cable paths. For the boards we chose the Fused Deposition Modeling (FDM) technology. Some
components on the boards were implemented by plastic or wooden blocks glued on the boards. We
also produced a prototype of the frame by laser-sintering, as FDM did not yield the required accu-
racy. The Side- and Flappanels were simply cut out of polymer or carbon fiber reinforced polymer
plates to facilitate the production.17
The first usage of the prototype was the development of the cable harness. With an exact copy of
the real hardware, the exact positions and lengths of the cables were relatively easy to determine.
This process was faster than the traditional approach (using 3D modeling software) and allowed us
to build the complete Engineering Model cable harness before having a single piece of EM hard-
ware available. The integration procedure could be developed by assembling the prototype several
times without harming operational hardware. We were able to refine our mechanical and electrical
design and also to develop Ground Support Equipment (GSE) by testing the assembly process. The
decisions for design changes were facilitated by implementing all alternatives in the prototype and
assessing them cost-effectively. Minor mechanical collisions due to design changes could be fed
back to the circuit board design with a demonstrative object of study. We were able to proof the
basic functionality (e.g. deployment) at all points in time, although a detailed tolerance assessment
was prevented by the manufacturing inaccuracies due to the rapid prototyping production processes.
Due to the early integration of the prototype, GSE and specific tools could be defined ahead of
time. Rapid prototyping methods were used to produce this equipment to ensure an agile develop-
ment process. Several stands for the satellite have been developed to ensure a safe and reproducible
integration of the satellite. The challenge was to consider different attachment points for holding
mechanisms for different integration steps. Additional stands and test equipment was produced to
allow fast and reproducible tests like an automated deployment pin release mechanism for Thermal
Vacuum Chamber (TVAC) deployment tests. To test the deployment we had to reset the Hold Down
and Release Mechanism (HDRM) on a regular basis. This process is very complex and has the
10

Figure 9: 3D Printed Prototype of MOVE-II
potential for damage on the solar cells. A reset tool was designed and produced by FDM to make it
safer and reproducible. The satellite is held by a plastic frame and the Flappanels are pushed into the
exact reset position by arms attached to this frame. That made it possible to push down the Antenna
Deployment Mechanism (ADM) by hand without any further adjustment while the HDRM is open.
We were able to reset the satellite within ten minutes for the next deployment test due to the shape
memory alloy based design of the HDRM and the reset tool.
Finally, it is very difficult to describe a system as complex as a satellite that just exists in CAD
files. Having a physical representation of the satellite in an early project phase was very helpful
to acquire new team members and to introduce the satellite to new members. With the 3D printed
prototype, we are able to show our deployment strategy and also our structure composition on a
model of the same size as the real satellite.
Agile Software Development
Software development for space applications is often characterized by historically grown struc-
tures and conservative methods, resulting in high project risk and delays. Many uncertainties re-
garding the planned cost and time budget, possible requirement changes in later project phases as
well as unforeseeable complications have made software one of the critical aspects of success or
failure in space missions. Multi-million dollar losses like Mars Climate Orbiter,18 Ariane 5 flight
50119 and Mars Polar Lander20 can be traced back directly to software flaws. Traditional processes
imply very limited flexibility and often result in highly time-consuming planning, implementation
and, if necessary, problem solving.
11

Contrary, CubeSats and their voluntary nature cause a high fluctuation in the numbers of active
students and weekly working hours, as well as a more complicated transfer of knowledge between
the participants. These circumstances also greatly affect the management of the project including
the adherence to the project plan and deadlines, causing an even bigger conflict between the three
typical forces in project management of using limited resources within a defined time frame to
ensure an acceptable quality.
Agile software development processes are iterative processes where the created artifacts evolve
incrementally. Agile software development is often used in changing environments, and an existing
result of any iteration can be delivered to the customer and further improved, changed and extended
in the next iteration. It allows to have a usable product at an early stage of the product lifecycle and
therefore allows early testing as well as iteratively delivering improved versions. At the same time
the previous version acts as a fallback in case the newest version does not work as intended and
enables to deliver a minimum viable product at any given time in the process. Thus, we chose agile
software development as the method for software development in MOVE-II.21
In MOVE-II, after the collection of initial requirements, the first goal was to implement a very first
version of all the software components in a few days. This version constituted the Minimum Viable
Product of our software and therefore included the most important functionality and interfaces and
allowed us to run it together with the other components on the hardware. This enabled us to detect
problems that occurred in interaction with other subsystems and their software at an early stage and
quickly find solutions for those problems. After the implementation of the Minimum Viable Product
there has always been an artifact that could be tested and incrementally changed. This means that
the basic functionality can be improved and extended, and that additional features can be added.
Using automatic build pipelines and the version control system git and the web interface GitLab,
every change to our software triggered the delivery of a new artifact that we could deploy to our
hardware and test together with the rest of the system. In case the new feature did not work, we were
able to roll back to the last version that was used and continue development with this successfully
tested artifact. Incorporating agile methods like Scrum the software development was organized into
weekly sprints for which the tasks were prioritized, estimated and then committed to by the team of
developers once a week. Thus, every week brought a new version of our software components that
we deployed to the satellite and tested.
Furthermore, all changes to our stable and already tested version were reviewed by another devel-
oper before they were incorporated into the existing version. This ensured a high code quality and
a broader distribution of knowledge about changes, known issues, best practices and the progress in
the team.
Low-cost ADCS testing environment
To test the ADCS independently of all other subsystems, it needs a power supply and a data
interface. At the beginning of the development we used several breakout boards to supplement these
interfaces. The successor to this solution was a PC/104 compatible board emulating the functionality
of the CDH, EPS and COM. The carrier board is depicted in figure 10. The CDH and COM are
substituted through a Beaglebone Black Wireless (BBBW). A BBBW is small enough to fit on a
CubeSatKit sized PC/104 PCB without any alterations. The Beaglebones SPI, I2C and GPIO pins
are directly connected to the PC/104 bus.Via the WIFI connection, the developers can log in to the
Beaglebone remotely. This enables them to issue commands and log sensor data even from their
homes. Two serial connections allow logging of the debug outputs of the ADCS.
12

Figure 10: The PC/104 compatible carrier board for a Beaglebone Black Wireless. It also includes
basic features of an EPS necessary for testing.
The emulated EPS on this board features an efficient 5 V, 2 A step-down converter and a 3.3 V,
500 mA converter. The converters are internally over-current and over-temperature protected. Both
voltage lines are equipped with a polyfuse matched to the ADCS maximal consumption. The poly-
fuse allows our developers to create short-circuits while testing, without causing damage. Two
power sensors continuously measure voltage and current on the Beaglebone, enabling developers to
directly assess the effectiveness of power saving techniques. Power switches allow the 3.3 V and
5 V lines to be turned on and off remotely. Two 9.6 Wh Li-Ion batteries allow up to 5 h of au-
tonomous operation. This is needed for long tests (e.g. continuous detumbling tests), during which
the ADCS has to be operated for a long time. A battery charger capable of 1.5 A of charging current
is wired to the PC/104 external access charging line. It enables charging of the batteries through the
MOVE-II common external debug interface.
Hardware-in-the-Loop Testbed
For validating the control algorithms, a real-time simulation containing the space environment as
well as actuator and sensor models was connected to the Mainpanel of the ADCS. Together, they
form a closed control loop that can simulate the ADCS in all mission phases. The ADCS control
loop is shown in Fig. 11. It includes the Mainpanel as the controller, the actuators on the Sidepanels,
disturbance torques stemming from the parasitic dipole and the atmosphere, the space environment,
spacecraft dynamics, and sensors on the Sidepanels. For simplicity, the Toppanel is referred to as a
Sidepanel.
Approach. Many CubeSat teams arrange a setup with a Helmholtz cage, a low friction bearing,
such as an air bearing or a thin wire, and a sun simulator to verify the function of their ADC
systems.22 This approach has the advantage of including all components of the ADCS in the test.
On the other hand, the friction of the bearing limits the maneuverability in the test setup and greatly
affects the dynamics of the satellite during testing. The MOVE-II team used a Helmholtz cage
13

to verify the B-dot detumbling algorithm. For the Hardware-in-the-Loop (HiL) testbed, the only
dedicated hardware is the Mainpanel and auxiliary boards for interfacing between the simulation
PC and the Mainpanel. The actuators and sensors are approximated with models resembling the
worst-case noise and bias of their real-life counterparts.
Figure 11: ADCS Control Loop23
Implementation. The plant shown in Fig. 11 is implemented as a Simulink model running in
real-time. The model also contains a Simulink implementation of the control algorithms to verify
the firmware running on the Mainpanel. The simulation PC is connected over Ethernet to a device
called Panel Emulator. The Panel Emulator is equipped with a Beaglebone Black single-board
computer and five microcontrollers resembling the Sidepanels. The Mainpanel is connected to
the Panel Emulator in the same way as to the Sidepanels and runs in flight configuration. The
stack of the Mainpanel, the Panel Emulator, and the ADCS testing board described in the previous
section is shown in Fig. 12. The simulation and the Mainpanel parameters can be configured with a
Matlab script that allows automated testing of different controller gains with varying environmental
conditions.
Figure 12: Mainpanel in the HiL Testbed between the ADCS Testing Board and the Panel Emula-
tor.23
B-Dot Detumbling. The detumbling controller uses the B-dot algorithm. With a worst-case ini-
tial velocity of 0.5 rad/s in every axis, the detumbling controller reduces the angular velocity to 0.01
rad/s in every axis within 162 minutes or 1.7 orbits. The detumbling behavior is shown in Fig. 13.
Reducing the velocity from 0.1 rad/s in every axis, expected after separation from the launcher, to
0.075 rad/s in every axis, from where the satellite switches to sun pointing mode, takes 12 minutes.
14

Figure 13: B-Dot Detumbling Controller Spinning Down from ω0= (0.5 0.5 0.5) rad/s to (0.01 0.01
0.01) rad/s.
Sun Pointing Controller. A state-feedback controller stabilizes the satellite in a spin around its z-
axis at 0.1 rad/s and maneuvers the spinning satellite’s top face towards the sun.24 Fig. 14 shows four
orbits with the sun pointing controller enabled. The pointing error is 21 degrees on average which is
primarily caused by the parasitic dipole that is estimated at 0.02 Am2. Recent measurements have
quantified the real parasitic dipole at 0.007 Am2to which the ADCS responds with a reduction of
the pointing error by a factor of two.
Figure 14: Sun Pointing Controller Adjusting Spin and Reducing Pointing Error. The Eclipse is
marked in grey.
Power Estimation. The lower graph of Fig. 14 shows the energy charged into the battery. It con-
siders the generated solar power, the power consumption of the ADCS (avg. 0.76 W), the computer
(avg. 0.4 W), the Electrical Power System (quiescent consumption of 0.6 W plus conversion losses),
15

and the UHF/VHF transceiver (avg. 1.5 W assuming 8 min contact on every orbit). After 10 min-
utes, the pointing error is reduced to 55 degrees and the solar panels generate enough power to start
charging the batteries. The pointing error reduces the solar power by 8% compared to a perfectly sun
pointed attitude, which is acceptable. The positive estimated power-budget in worst-case conditions
builds confidence in the ability of MOVE-II to allow continuous operation of the basic subsystems
and charge the batteries for short-term operation of the payload and the S-Band transceiver.
Reliability Growth for System-Level Testing
Creating a reliable system is by far the greatest challenge for any CubeSat team. As the satellite
can only be reliable, if all critical systems work flawlessly together, system-level tests are absolutely
mandatory. However, an insufficient approach to system-level testing is seen as one of the main
reasons for the low reliability of CubeSats.6,7 Challenges we encountered at MOVE-II for system-
level tests are: time pressure, produced by the delay of the previous project phases; dependence
on systems that are not developed far enough (in case of in-house developments); delayed delivery
(several months) on COTS hardware and lacking experience in test planning.
To address these challenges we decided to set up a remote-controllable testing environment (com-
pare Figure 15). The command line interface was made accessible via remote tools as well as a logic
analyzer and a multimeter, reading all logical signals and voltages on the bus as well as a camera
recording all debug LEDs. This enabled developers to test fast and efficient without having come to
the facility and reduces the risk of hardware being damaged by testers. Apart from this the following
principles were applied: All encountered bugs are documented in a ticketing system, all quantitative
data streams are visualized to find irregularities and patterns, the system is online 24h a day, the fear
of breaking something is no sufficient excuse to not test something. This last point is especially
important in our eyes and was applied on environmental and operational tests as well as tests on
critical malfunctions like insufficient power for continuous operation. Furthermore, through 24h
remote accessibility, we tried to maximize the number of testers and therefore the heterogeneity of
our test vectors.
Figure 15: First remote testing setup
As the main challenge for any CubeSat is to overcome the DOA syndrome and infant mortality,7
24 hour tests were conducted regularly. The goal of these tests was proving the first 24 hours of
the satellite’s operational lifetime, including orbital injection, deployment of the solar panels, first
16

contact, disabling of the LEOP sequence and enabling all systems that are deactivated during LEOP.
These tests proved to be very effective in showing up faults of subsystem interaction and software
interaction.
Figure 16 gives an overview of the chronological sequence of system-level tests on MOVE-II.
The graph is separated in four phases: I) Flatsat testing: All subsystems were connected by an
external harness, giving access to all electronic connections. II) Engineering Model testing: The
system was integrated completely for the first time, last modifications of the hardware were con-
ducted and environmental tests (shaker, acceleration, thermal vacuum testing) were conducted.
III) Flight Model testing: In parallel to the Engineering Model tests, the Flight Model was pro-
duced. In addition to environmental tests and further sensor calibration and functional testing,
tests under operational environment conditions were conducted in phase III. Communication via
debug interfaces was replaced by the satellite’s UHF/VHF link. For these tests access to the
systems was limited to a set of six overpasses per day, during which software updates and tests
were conducted. These tests especially helped to verify the usability of important system anal-
ysis tools, file transfer mechanisms and reliability of the space - ground communications chain.
IV) Concurrent Engineering Model and Flight Model testing: In phase IV both instances of MOVE-
II were tested in parallel, relying on the operations interface. By releasing the operations interface
during the testing phase, the complete chain of functions and interfaces was tested accordingly.
IV
III
III
c
b
a
Figure 16: Total amount of error reports over time25
The positions a, b and c mark the occurrence of a high amount of error reports in very short time.
In case of a and b, these marks fall exactly on the conduction of the previously described 24 h tests.
The steep increase marked as c was due to an upcoming major internal deadline.
17

CONCLUSION
With MOVE-II almost on the pad for its launch in early 2018, TUM and LRT look back at over 10
years of successful hands-on space education of students. Besides the technological and educational
progress made in the program, we hope that the shown methods for reliability assurance and risk
mitigation will guide other CubeSat teams towards higher success rates without losing the spirit
of using novel, state of the art technology. We believe that CubeSats have to be developed in fast
mission timelines, without drawing too much resources nor imposing too many burdens on the
CubeSat teams, and will further improve our work to help to evolve CubeSats into more reliable
and accepted platforms for scientific payloads and commercial applications.
ACKNOWLEDGMENT
The authors acknowledge the funding of MOVE-II by the Federal Ministry of Economics and
Energy (BMWi), following a decision of the German Bundestag, via the German Aerospace Center
(DLR) with funding grant number 50 RM 1509. The MOVE-II team furthermore would like to
thank all external reviewers and staff of LRT for their invaluable help.
REFERENCES
[1] M. Czech, A. Fleischner, and U. Walter, “A First MOVE in Satellite Development at the TU-M¨
unchen.
Small Satellite Missions for Earth Observation,” Small Satellite Missions for Earth Observation, R.
Sandau, H.-P. Roeser und A. Valenzuela, Springer Berlin Heidelberg, 235-245, 2010.
[2] M. Langer, C. Olthoff, J. Harder, C. Fuchs, M. Dziura, A. Hoehn, and U. Walter, “Results and lessons
learned from the CubeSat mission First-MOVE,” Small Satellite Missions for Earth Observation, R.
Sandau, H.-P. Roeser und A. Valenzuela, Springer Berlin Heidelberg, 2015.
[3] M. Langer, N. Appel, M. Dziura, C. Fuchs, P. Gnzel, J. Gutsmiedl, M. Losekamm, D. Messmann, and
C. Trinitis, “MOVE-II der zweite Kleinsatellit der Technischen Universit¨
at M¨
unchen,” Deutscher Luft-
und Raumfahrtkongress 2015, Rostock, Germany, 2015.
[4] D. Voss, K. Alexander, M. Ford, C. Handy, S. Lucero, and A. Pietruszewski, “Educational Programs:
Investment with a large return,” Proceedings of the 26th Annual AIAA/USU Conference on Small Satel-
lites, Logan, UT, August, 2012, Paper SSC12-VII-1, 2012.
[5] J. T. Emison, K. Yoshino, S. E. Straits, and H. D. Voss, “Satellite Design for Undergraduate Senior
Capstone,” ASEE National Conference. Indianapolis, IN, USA, 2014.
[6] M. Swartwout, “The First One Hundred CubeSats:A Statistical Look,” Journal of Small Satellites, 2013.
[7] M. Langer and J. Bouwmeester, “Reliability of CubeSats Statistical Data, Developers’ Beliefs and the
Way Forward,” Proceedings of the 30th Annual AIAA/USU Conference on Small Satellites, Logan, UT,
6-11 August, 2016, Paper SSC16-X-2, 2016.
[8] J. Gutsmiedl, M. Dziura, M. Langer, M. Losekamm, M. Grulich, and M. Mutschler, “Providing Hands-
On Space Education by Involvement of Collaborating Self-Reliant Student Teams,” 1st Symposium on
Space Educational Activities, ESA, Padua, Italy, 9-12 December 2015, 2015.
[9] A. Mehrparvar, D. Pignatelli, J. Carnahan, R. Munakat, W. Lan, A. Toorian, A. Hutputanasin, and
S. Lee, “CubeSat Design Specification Rev 13,” The CubeSat Program, Cal Poly San Luis Obispo, US,
2014.
[10] M. Langer, C. Olthoff, L. Datshvili, H. Baier, N. Maghaldadze, and U. Walter, “Deployable Structures in
the CubeSat Program MOVE,” Proceedings of the 2nd International Conference Advanced Lightweight
Structures and Reflector Antennas, pp. 224-233, Tbilisi, Georgia, 1-3 October 2014, 2014.
[11] M. Grulich, A. Koop, P. Ludewig, J. Gutsmiedl, J. Kugele, T. Ruck, I. Mayer, A. Schmid, and K. Di-
etmann, “SMARD-REXUS-18: Development and Verification of an SMA Based CubeSat Solar Panel
Deployment Mechanism,” Proc. 22nd ESA Symposium European Rocket & Balloon Programmes and
Related Research, 2015, pp. 7–12.
[12] N. Appel, S. R ¨
uckerl, and M. Langer, “Nanolink: A robust and efficient protocol for Small Satellite
radio links,” Proceedings of the Small Satellites Systems and Services The 4S Symposium 2016, Valletta,
Malta, 2016., 2016.
18

[13] N. Appel, A. Kimpe, K. Kraus, M. Langer, M. J. Losekamm, M. Milde, T. P¨
oschl, S. R¨
uckerl, F. Sch¨
afer,
A. Stromsky, and K. W ¨
url, “TDP-3 VANGUARD: Verification of a New Communication System For
CubeSats on BEXUS 22,” 23rd ESA Symposium on European Rocket and Balloon Programmes and
Related Research, Visby, Sweden, 2017.
[14] M. Rutzinger, L. Krempel, M. Salzberger, M. Buchner, A. H¨
ohn, M. Kellner, K. Janzer, C. G. Zimmer-
mann, and M. Langer, “On-orbit verification of space solar cells on the CubeSat MOVE-II,” 2016 IEEE
43rd Photovoltaic Specialists Conference (PVSC), 2016, pp. 2605–2609.
[15] D. Messmann, T. Gr¨
ubler, F. Coelho, T. Ohlenforst, J. v. Br¨
ugge, F. Mauracher, M. D ¨
otterl, S. Pla-
mauer, P. Schnierle, T. Kale, M. Seifert, A. Fuhrmann, E. Karagniannis, A. Ulanowski, A. Meraner, and
M. Langer, “Advances in the Development of the Attitude Determination and Control System of the
CubeSat MOVE-II,” 7th European Conference for Aeronautics and Space Sciences (EUCASS), Milan,
June 3 - June 6, 2017, 2017.
[16] D. Messmann, F. Coelho, P. Niermeyer, M. Langer, H. Huang, and U. Walter, “Magnetic Attitude
Control for the MOVE-II Mission,” 7th European Conference for Aeronautics and Space Sciences (EU-
CASS), Milan, June 3 - June 6, 2017, 2017.
[17] M. Weisgerber, F. Schummer, K. Steinkirchner, and M. Langer, “Risk Reduction and Process Acceler-
ation for Small Spacecraft Assembly and Testing by Rapid Prototyping,” Deutscher Luft- und Raum-
fahrtkongress 2017, Munich, Germany, 2017.
[18] J. S. R. Board, “Report on the Loss of the Mars Polar Lander and Deep Space 2 Missions,” March 2000.
[19] L. J.L., “Ariane 5 Flight 501 Report of the Inquiry Board,” July 1996.
[20] E. E. et.al., “The Failures of the Mars Climate Orbiter and Mars Polar Lander: A Perspective from the
People Involved,” Proceedings of Guidance and Control 2001 paper AAS 01-074, 2001.
[21] A. Lill, D. Messmann, and M. Langer, “Agile Software Development for Space Applications,”
Deutscher Luft- und Raumfahrtkongress 2017, Munich, Germany, 2017.
[22] M. K. Quadrino, “Testing the Attitude Determination and Control of a CubeSat with Hardware-in-the-
Loop,” Master’s thesis, MIT, 2014.
[23] J. Kiesbye, “Hardware-in-the-Loop Verification of the Distributed, Magnetorquer-Based Attitude Deter-
mination & Control System of the CubeSat MOVE-II,” Master’s thesis, Technical University of Munich,
2017.
[24] D. Meßmann, “Development of a Sun Pointing Attitude Controller using Magnetic Actuation for the
MOVE-II CubeSat Mission,” term paper, Technical University of Munich, 2017.
[25] F. Schummer, “Robustness Analysis on Small Spacecraft Design,” Master’s thesis, Technical University
of Munich, 2017.
19