Conference PaperPDF Available

MOVE-II THE MUNICH ORBITAL VERIFICATION EXPERIMENT II

Authors:

Abstract and Figures

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.
Content may be subject to copyright.
(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.
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
... After a successful launch in December 2018, the spacecraft is now in orbit since over 2.5 years and performing well (Rückerl, S. et al (2019); Roberts and Hadaller (2019)). The mission is a typical case of small spacecraft developments; parts of the system such as the Command and Data Handling software, the payload, the structure and mechanisms or the Attitude Determination and Control System were designed and built in house by students, while other subsystems, such as the hardware for the Command and Data Handling system or the Electrical Power System were acquired by external vendors (Langer et al. (2017)). The SysML model employed for the analyses in this paper covers the structure of the whole spacecraft, including any data flows and electrical flows, any sensor measurements and the satellite's software. ...
Preprint
Full-text available
Model-Based Systems Engineering aims at creating a model of a system under development, covering the complete system with a level of detail that allows to define and understand its behavior and enables to define any interface and workpackage based on the model. Once such a model is established, further benefits can be reaped, such as the analysis of complex technical correlations within the system. Various insights can be gained by displaying the model as a formal graph and querying it. To enable such queries, a graph schema needs to be designed, which allows to transfer the model into a graph database. In the course of this paper, we discuss the design of a graph schema and MBSE modelling approach, enabling deep going system analysis and anomaly resolution in complex embedded systems. The schema and modelling approach are designed to answer questions such as what happens if there is an electrical short in a component? Which other components are now offline and which data cannot be gathered anymore? Or if a condition cannot be met, which alternative routes can be established to reach a certain state of the system. We build on the use case of qualification and operations of a small spacecraft. Structural and behavioral elements of the MBSE model are transferred to a graph database where analyses are conducted on the system. The schema is implemented by an adapter for MagicDraw to Neo4j. A selection of complex analyses are shown on the example of the MOVE-II space mission.
... The goal of hands on student education also greatly impacted the development team's setup [1]. As scientific payload the CubeSat carries quadro-junction solar cells, of which the degradation in the space environment over time shall be measured [2], [3]. ...
Conference Paper
Full-text available
This paper covers the lessons learned on applying MBSE in the MOVE-II mission, with a focus on Assembly-Integration-Testing and Operations of the spacecraft. It shows the states of implementing MBSE across the various project phases. Furthermore, it shows the implementation of these lessons learned on the MOVE-III mission and what has been learned based on this application. MOVE-III was initiated in 2019. Taking the input from both missions and the results of ten interviews with ESA specialists in the fields of AIT and MBSE, we progress to the aims of the "MBSE to DataLakes project". This new activity heads the primary objective of increasing efficiency of spacecraft AIT by employing MBSE, matching ESA's overall MBSE strategy. Set up as a public funded project, with the aim of hands-on education for future spacecraft engineers, the MOVE-II project followed the typical design stages of any spacecraft development. Combined with the lack of inherited liabilities and the limited complexity compared to larger spacecraft programs, this makes it a good reference project for MBSE implementation. While the spacecraft is in orbit since December 2018 and is being operated successfully since then, the focus of this paper is set on lessons learned in the implementation of MBSE throughout the design and qualification of the spacecraft, up to its daily operations in orbit over the past five years.
... The startup OroraTech has the plan of deploying a satellite-based wildfire detection system that covers the whole earth's surface [2]. The newly developed satellites will rely on knowledge and experiences from the 1U Munich Orbital Verification Experiment -II (MOVE-II) satellite that was developed at the Chair of Astronautics (LRT) at TUM and was launched in 2018 [3][4][5][6][7]. The company's goal is to detect fires down to 100 m² within 15 to 30 min by launching a constellation of CubeSats in LEO. ...
Conference Paper
Full-text available
CubeSats have been on the rise during the last decade and have the potential to substitute large, expensive satellites in many commercial and scientific applications. A reasonable commercial application of these standardized small satellites are Earth Observation constellations with medium spatial and high temporal resolution. The company Orbital Oracle Technologies GmbH (OroraTech) works on such a constellation of CubeSats to detect and monitor wildfires and other high-temperature events. One of the design challenges for any small satellite with high power instruments is thermal design and its thermal stability. The changing thermal environment of the Low Earth Orbit (LEO), the varying power consumption and thereby thermal activity of sensors and processing units combined with the low thermal inertias of small satellites create a challenging task for the design and simulation of small satellites. In the case of OroraTech, each 3-unit (U) CubeSat is equipped with an infrared sensor ensuring a resolution of 200m/pixel. The thermal stability of the sensor is a main driver of the design of the satellite, to achieve a reasonable measurement quality. Furthermore mass, volume, and power restrictions of 3U CubeSats, but also the design for robustness of the satellite, limit the application of active thermal control for this use case. Thus, in a research collaboration between OroraTech, the TUM, and Fraunhofer IGCV this problem was addressed investigating different thermal control systems (TCS). The use of phase change material (PCM) was chosen as the most appropriate solution to achieve the desired stability and robustness. This paper will evaluate different PCM design aspects, namely material, containment, and conduction enhancement. The final design and its validation through thermal analysis in COMSOL and ESATAN-TMS are addressed. The presented passive TCS will ensure the thermal stability for the first in-orbit verification (IOV) mission of OroraTech, which is scheduled for launch in Q4 2021.
... Low-cost CDH: MOVE-II's CDH was a commercial component that was only bought for the Engineering-Model and the Flight-Models of MOVE-II and MOVE-IIb. To overcome the shortage of hardware, the team built a Beaglebone-based low-cost CDH with a PC/104 connector that runs the MOVE-II Linux operating system plus all software controlling the subsystems [8]. This cheap and simple solution found its way into many prototypes of the satellite including several HIL setups. ...
Article
Full-text available
This article reports the ongoing work on an environment for hardware-in-the-loop (HIL) and software-in-the-loop (SIL) tests of CubeSats and the benefits gained from using such an environment for low-cost satellite development. The satellite tested for these reported efforts was the MOVE-II CubeSat, developed at the Technical University of Munich since April 2015. The HIL environment has supported the development and verification of MOVE-II’s flight software and continues to aid the MOVE-II mission after its launch on 3 December 2018. The HIL environment allows the satellite to interact with a simulated space environment in real-time during on-ground tests. Simulated models are used to replace the satellite’s sensors and actuators, providing the interaction between the satellite and the HIL simulation. This approach allows for high hardware coverage and requires relatively low development effort and equipment cost compared to other simulation approaches. One key distinction from other simulation environments is the inclusion of the electrical domain of the satellite, which enables accurate power budget verification. The presented results include the verification of MOVE-II’s attitude determination and control algorithms, the verification of the power budget, and the training of the operator team with realistic simulated failures prior to launch. This report additionally presents how the simulation environment was used to analyze issues detected after launch and to verify the performance of new software developed to address the in-flight anomalies prior to software deployment.
... Due to the relatively low costs, a new generation of space missions have been accomplished even as university projects (Heidt et al., 2000). One such student-led project was initiated in 2006 at Technical University of Munich (TUM), called MOVE (figure 1) (Langer et al., 2017). Three 1U CubeSats are already in orbit under the tutelage of MOVE and this project could be termed a spinoff application. ...
Conference Paper
Full-text available
Wildfires cause large scale devastation to human settlements and forests every year and their frequency and severity is on the rise. A major reason for this devastation is the significant delay in their detection due to their remote locations in forests. To mitigate this, a constellation of nanosatellites in Low Earth Orbit (LEO) equipped with multi-spectral visible to Infrared (IR) cameras is proposed leveraging the modular and affordable architecture of CubeSats. Coupled with the payload design, meticulously planned constellation and a ground support system, all surface points on the planet will be revisited at least once in an hour. Capturing a surface location with a high resolution in MidWavelength Infrared (MWIR) and LongWavelength Infrared (LWIR) allows a precise estimation of thermal output of the surface. Simulations indicate that a fire of about four hundred square meters can be easily detected from this satellite payload. Through onboard data processing, wildfires can be already detected in space, minimizing bandwidth requirements for real-time alerts. This enables an early wildfire warning within 30 min by utilizing existing satellite internet networks. Additionally, compressed raw images will be transmitted on fixed ground station passes to provide a global thermal data updated every 90 min. The near real-time multi-spectral data provides opportunity for several other applications like weather forecasting besides wildfire detection.
... The ADCS simulation environment described in [16] was extended, so the solar irradiation of the satellite both with active and inactive ADCS could be studied in detail culminating in a Hardware in the Loop (HiL) simulation that could assess the performance of the maximum powerpoint trackers and all subsequent power conditioning circuitry of MOVE-II's EPS. The solar array simulator described in [15] can simulate the realistic IV-curve of a solar array in real-time based on the solar irradiation and temperature of the array which the space environment simulation calculates. ...
Conference Paper
Full-text available
MOVE-II (Munich Orbital Verification Experiment) is the second satellite of the Technical University of Munich's educational CubeSat program. On December 3, 2018, the satellite was launched on the SSO-A SmallSat Express from the Vandenberg Air Force Base. The following paper shows on-orbit results of the first eight months of operations. It includes analyses based on our own data as well as the open-source ground station network SatNOGS. Lessons learned from mission operations and recommendations for future educational missions are provided. The technical goals of the mission are verifying the satellite's bus and the qualification of a novel type of quadro-junction solar cells. Over 200 students have been developing and testing all components of the satellite since the beginning of the project in April 2015. During the course of the project, the students designed all necessary technology for a CubeSat bus, with the exception of the electrical power system and the on-board computer's hardware. Furthermore, the students developed ground station software as well as an operations interface from scratch. The technological achievements of the mission range from a linux-based onboard computer software over a magnetorquer-based attitude determination and control system to two novel transceivers for UHF/VHF and S-Band. A reusable mechanism, based on shape-memory-alloys, deployed the four solar panels, providing the necessary power. Only hours after the deployment, we received the first signals of the satellite. The commissioning of the ground station and the effects of an insufficient power budget of the tumbling satellite preoccupied us during the first month, as well as frequent watchdog resets. During the commissioning of the Attitude Determination and Control System (ADCS), a spin rate of 200 °/s was observed, although the actuators were not activated yet. Detailed analysis with the help of recordings provided by our own ground station as well as the SatNOGS ground station network revealed a slow increase of the spin rate since the launch. In the following weeks the spin rate further increased to over 500 °/s. Afterwards we were able to modify our ADCS actuation in a way to reduce the spin rate again. Currently MOVE-II is detumbled and we are moving towards regular scientific operation. After a presentation of the results, lessons learned from our mission operations are discussed. The paper discusses the measured values and analyzes the reasons for the observed behaviour. Also the changes made on MOVE-IIb, a slightly improved copy of MOVE-II, will be explained. The paper concludes with recommendations for designers of upcoming educational satellite missions, especially regarding resilience against negative power budgets.
... MOVE-II [2], the successor mission of First-MOVE, was under development since April 2015. An interdisciplinary team of students was developing, building, and testing this one-unit (1U) CubeSat under supervision of members of the LRT. ...
Conference Paper
Full-text available
In this paper, we will report on the results and lessons learned of the development, test and operation of two software-defined transceivers on the CubeSat mission MOVE-II (Munich Orbital Verification Experiment II). MOVE-II, a single-unit CubeSat, is the second satellite of the CubeSat program MOVE of the Technical University of Munich (TUM). The main goals of the mission are verification of a novel satellite bus for demanding payloads, verification of a novel type of solar cells as well as education of students. The MOVE-II satellite bus features two independent communication systems. The system for telemetry and telecommand of the satellite is a software defined radio (SDR) based full duplex UHF/VHF system. All signal processing and protocol handling is done in a XILINX Spartan 6 field programmable gate array (FPGA). It has a fixed baud rate and supports different coding and modulation schemes allowing slightly higher data rates depending on the link margin. For high-speed data transfer, the S-Band system provides additional bandwidth. It is an SDR based half duplex system supporting the same channel coding and modulation schemes at a significantly higher baud rate. The downlink data rate of this system is 3 MBit/s. MOVE-II uses a novel data link layer protocol called Nanolink. We tailored this protocol specifically for the needs of a CubeSat and features virtual channels and optional automatic repeat request (ARQ) while maintaining its low overhead. Thus, it enables an efficient use of the available bandwidth. We verified the functionality and our simulations with different measurements in laboratory environments as well as a BEXUS stratosphere balloon mission. Currently we are performing final preparations and trainings for the launch and early operation phase. The launch of the satellite is scheduled for November 2018. We will report on the development process of the communication architecture within the resource-constraint environment of a university, and focus on the verification of the transceivers' functionality.
Thesis
Low Earth Orbit (LEO) applications are described by the need of high reliability, limited access from the ground and limited available bandwidth when considering the communication system. Especially for small-size systems strict power constraints and price are further limiting factors in system design. This thesis evaluates the use of UHF transceivers for small-size LEO applications. First, requirements for a transceiver chip are derived from a typical LEO CubeSat mission. Included characteristics are constraints on the level 2 protocol, frequency ranges, supported modulation, bitrate ranges, sensitivity, power consumption and output power. Forward error correction, chip packaging, clock stability and its deviation under changing temperature, electronic interfaces and the need of additional electrical components are discussed as well. Documentation, availability and existing applications are also taken into consideration. Evaluated chips are the following: at86rf215, Microchip Technology; ax5243, ON Semiconductor; cc1125, Texas Instruments; ol2385ahn, NXP; si4432 and si4460/61/63/64, Silicon Labs; sx1231 and sx1276, Semtech; s2-lp, ST Microelectronics; adf7024, Analog Devices A preselection of chips is done based on their datasheets. It is described how to measure them with high frequency measuring equipment including a spectrum analyzer and a software defined radio as well as standard electronics measurement equipment. The test setups and their use are documented. Also a test setup to determine effects of temperature is demonstrated.
Conference Paper
Full-text available
Software development for space applications is characterized by historically grown structures and conservative methods derived from traditional project management. Many of these methods are not easily transferable from normal product development to software development. Project risk is high and delays are the rule due to the many uncertainties regarding the planned cost and time budget, possible requirement changes in later project phases as well as unforeseeable complications. Furthermore, these methods have very limited flexibility and come with highly time-consuming planning, implementation and, if necessary, problem solving. Agile software development does not require that all requirements are known and well-defined at the beginning of the project. The development is incremental and generates a usable and testable software product with every new iteration. This makes the development more flexible and problems can be detected earlier and solved with less effort. Due to the frequent integration into the existing system, a close collaboration is possible across subsystems as well as the customer or the project partners. This increased flexibility and improved cooperation reduces project risk, cost and time until delivery. This paper shows the application of agile software development in the space sector applied to a CubeSat project. Within the student satellite project Munich Orbital Verification Experiment II (MOVE-II) at the Technical University of Munich (TUM) the concept of agile software development was successfully applied to develop the software of the on-board computer within a few months. The agile methods presented in this article demonstrate software development that does not require the final requirements at the beginning of the development process. These methods allow that a new version of the software can be tested and operated after every iteration of the process. The launch of our CubeSat MOVE-II is scheduled for early 2018.
Conference Paper
Full-text available
Changes due to design flaws impose major costs, delays and high risks on any spaceflight project. The later the change, the riskier and more expensive it is. System changes due to failures detected during spacecraft assembly are usually one of the last hardware flaws to be found and therefore impose major risks on the overall project. Traditionally, this is overcome by metal or wooden mock-ups early in the process. However, to respond to design changes in a fast manner and to properly explore the remaining options by building multiple full size mock-ups in a short time interval, rapid prototyping was used by the authors. This paper provides lessons learned of the Munich Orbital Verification Experiment II (MOVE-II), related to rapid prototyping technologies used during the development phase. MOVE-II is the second CubeSat mission of the Chair of Astronautics at the Technical University of Munich (TUM). Early in the design process, a 3D printed structural model of the CubeSat was built to verify the CAD model, the assembly strategy, and to track down potential system level design deficiencies. By doing so, minor and major flaws concerning integration of the satellite were found in an early project phase. Furthermore, multiple design alternatives were 3D printed during the development process, not only exploring different solutions but also defining cable paths and cable lengths and evaluating the corresponding assembly process. In difference to traditional methods, 3D printing allows for a shorter implementation time span of different design options. In addition it was possible to conduct dress-rehearsals of the integration procedure early on in order to save time in later project phases, and without potentially harming expensive hardware. Due to the early integration of the prototype, Ground Support Equipment (GSE) and specific tools could be defined ahead of time. The biggest non-technical benefit was, that the physical model simplified communication of problems and possible configurations as well as introductions to the system. Display material was always available for the developing team, either for presentations of the project or for recruitment of new team members. The paper concludes with a brief assessment of the limitations of rapid prototyping technologies for risk reduction and process acceleration. Assessment of mechanical functionality as well as mechanical fits are limited due to production tolerances. Therefore the deployment mechanism of MOVE-II could not be tested sufficiently. Finally, future improvements are shown for upcoming CubeSat missions of the TUM.
Conference Paper
Full-text available
This paper presents the fundamental work on the attitude control design using solely magnetic actuation for the MOVE-II mission. Two control modes are primarily considered: detumbling and sun pointing control. Regarding the sun pointing control, two approaches are discussed. The first is the Spin Stabilized Sun Pointing Control (SSPC) which provides gyroscopic stiffness against disturbances. The second is a non-spinning approach called Reduced Sun Pointing Control (RSPC). Simulation results have shown satisfactory performance providing proof of concept and motivation for further work.
Conference Paper
Full-text available
MOVE-II (Munich Orbital Verification Experiment) will be the first CubeSat of the Technical University of Munich (TUM) utilizing a magnetorquer-based active attitude determination and control system (ADCS). The ADCS consists of six circuit boards (five satellite side panels and one central circuit board in satellite stack), each equipped with a microcontroller, sensors and an integrated coil. The design enables redundancy and therefore forms a fault-tolerant system with respect to sensors and actuators. The paper describes the hardware implementation, algorithms, software architecture, and first test results of the integrated ADCS on the engineering unit. A possibility to upgrade and extend our software after launch will enable further research on new and innovative attitude determination and control strategies and distributed computation on satellites. The MOVE-II flight unit is in the integration and test phase with an intended launch date in early 2018.
Conference Paper
Full-text available
Several promising multi-junction solar cell concepts for space applications are currently under development worldwide. On-Orbit Verification on CubeSats is a cost-efficient method to gain data on critical hardware early in the design validation process. The MOVE-II CubeSat will be used for the verification of novel 4-6 junction solar cells. With a footprint of 10x10 cm², the payload consists of one full size solar cell (8x4 cm²) and up to 7 positions (each 2x2 cm²) for corresponding isotype solar cells. The measurement electronics is based on commercial off-the-shelf hardware. MOVE-II is planned to launch in early 2018 into a 500-550 km sun-synchronous orbit.
Conference Paper
Full-text available
In this paper we investigate the data on 178 launched CubeSats and conduct a nonparametric and parametric analysis, where the dead-on-arrival (DOA) cases as well as the subsystem contribution to failure are specifically addressed. Using Maximum Likelihood Estimation, a Single Weibull and a 2-Weibull mixture parametric model are fitted to the non-parametric data. Furthermore, by combining developers' beliefs on several reliability aspects from a survey conducted in late 2014 with data from past missions, we make a first attempt to correlate space engineering " best guesses " and intuition to actual data. Finally, the probabilistic CubeSat reliability estimation tool is introduced as a method to reduce the infant mortality of CubeSats: CubeSat developers should be able to estimate their required functional testing time on subsystem and system level at an early project stage, while targeting a desired reliability goal on their CubeSat.
Conference Paper
Full-text available
The Institute of Astronautics (LRT) at Technical University of Munich (TUM) incorporates self-reliant student teams to provide hands-on space education. Organized within the student group WARR almost 200 students are developing space hard- and software supervised by the institute’s staff members. The CubeSat project MOVE-II is one of the most challenging ongoing projects. About 40 students are developing a satellite with high requirements in terms of power and data transmission. To qualify the CubeSat’s hold-down and release mechanism, a collaborating student team launched a prototype within the REXUS 18 campaign. As a reference payload the Multi-Purpose Active-Target Particle Telescope (MAPT) is developed by a another student team. Once tested on the BEXUS 18 campaign, another qualification flight is planned on BEXUS 22/23. Meanwhile WARR’s oldest branch consisting of almost 50 students develops a cryogenic hybrid rocket engine - aiming to brake the European altitude record for amateur rockets with the WARR-EX 3. Successfully launching the hybrid sounding rocket WARR-EX 2 in 2015 in Brazil the team gained important experience.
Conference Paper
Full-text available
We present Nanolink, a data link layer protocol for CubeSats and other spaceborne assets with similar bandwidth and hardware resources. The protocol is designed to operate with high efficiency and high reliability over links with a small bandwidth-delay product and moderate to weak signal quality. A type-I hybrid automatic repeat request (ARQ) scheme and an extensible header structure reduce the overhead added by unused protocol features, thus minimizing the overhead added on the return channel by the ARQ. Simulations show a good performance of the protocol, despite high bit error rate on the channel. Furthermore, the return channel bandwith efficiency of the protocol allows its use on asymmetric links.