TTK4550 - Engineering Cybernetics, Specialization Project

Hardware Review of an On Board

Controller for a Cubesat

Norwegian University of Science and Technology

Trondheim

M AGNE A LVER N ORMANN

Fall 2015
Executive Summary

In this report a partially existing On Board Controller (OBC) for a Cubesat is reevaluated
with concern to choice of microcontroller and external memories. As a first step toward
this, a strategy for documentation of various specifications for the satellite is presented
and a functional requirement as well as a non-functional requirement specification for the
On Board Computer is created and discussed. Various microcontrollers are then evaluated
for the OBC and the currently used UC3-family microcontroller is deemed as the most
appropriate as it has no critical shortcomings and offers the shortest time to completion
due to the already implemented code base. The author therefor recommends that the main
microcontroller is not changed unless the bus interface does. The author does also argue
for replacing the SRAM of the OBC with a more radiation resistant MRAM.

The paper then discusses how the functional requirements can be satisfied, and presents
a software architecture for this purpose. The service contract of the OBC should be out-
lined in order to further establish the way other satellite systems can interact with the OBC.

The report ends with a general discussion of the work that has been done, the lessons
learnt, and what the future might hold for this project.

i
Problem

The current focus of the NUTS project is to finish the design and build hardware for an
integrated engineering model. Through this project, the student should focus on the top-
level system design in general, with particular focus on the choice of Microcontroller Unit
(MCU) and its software for the on-board computer subsystem.

The OBC is one of the principal components of the satellite, and is able to control the
rest of the system by granting or denying subsystems access to power and the databus.
Other OBC tasks include logging of system parameters in addition to preparing and read-
ing data transmitted to and from the communication systems.

The OBC must be designed to be reliable, as maintenance is impossible after launch. Chal-
lenges due to the space environment, such as temperature cycles, radiation environment
and vacuum must be identified and discussed. In areas where mitigation of such problems
is possible, solutions should be presented. Whether the solutions be implemented should
be based on a cost/benefit analysis.

Key tasks for the student:

• The project should explore and determine the requirements for the OBC in order for
it to meet the requirements for the NUTS mission.
• The project should research different types of MCUs for different tasks and compare
their strengths and weaknesses, and present a justified choice for the NUTS mission.
• Software architecture for the OBC should be outlined and designed as detailed as
time allows for.
In addition to the given tasks, the student is expected to participate in relevant group work.
The NUTS project is a multi disciplinary project, which requires more involvement from
the student than just the completion of the individual task and report.

Supervisor: Amund Skavhaug

Co-supervisor: Roger Birkeland

ii
Table of Contents

Executive Summery i

Problem ii

Table of Contents iv

List of Tables v

List of Figures vi

Acronyms vii

1 Introduction 1
1.1 Project Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 The NTNU Test Satellite . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3 The Purpose of the OBC . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4 The Approach Taken in this Report . . . . . . . . . . . . . . . . . . . . . 3

2 Background 4
2.1 Reliability Theory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.1 Reliability, Failures and Errors . . . . . . . . . . . . . . . . . . . 4
2.2 Space Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.1 Space Radiation . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.2 Total Ionizing Dose . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.3 Single Event Effects . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3 Earlier Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3 Requirement Specification 11
3.1 What Are Requirement Specifications and Why Are They Important? . . 11
3.2 Satellite Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.3 NUTS Specification System . . . . . . . . . . . . . . . . . . . . . . . . 12
3.3.1 Creating a Requirement Specification . . . . . . . . . . . . . . . 12

iii
 3.3.2 Naming Convention . . . . . . . . . . . . . . . . . . . . . . . . 13
3.4 OBC Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . 15
3.4.1 Satellite Initialization . . . . . . . . . . . . . . . . . . . . . . . . 15
3.4.2 Satellite Housekeeping . . . . . . . . . . . . . . . . . . . . . . . 15
3.4.3 OBC Executables . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.4.4 Satellite Executables . . . . . . . . . . . . . . . . . . . . . . . . 17
3.5 OBC Non-Functional Requirements . . . . . . . . . . . . . . . . . . . . 18
3.6 Determining the Complexity . . . . . . . . . . . . . . . . . . . . . . . . 18
3.7 Estimating the Size, Weight, and Power . . . . . . . . . . . . . . . . . . 19

4 Determining the Components 20

4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.2 Choosing a Microcontroller . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2.1 Microcontroller Requirements and Criteria . . . . . . . . . . . . 21
4.2.2 The Competitors . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.2.3 Microcontroller Discussion . . . . . . . . . . . . . . . . . . . . . 24
4.2.4 Microcontroller Conclusion . . . . . . . . . . . . . . . . . . . . 28
4.3 Chosing External Memories . . . . . . . . . . . . . . . . . . . . . . . . 28
4.3.1 Non-Volatile Memory . . . . . . . . . . . . . . . . . . . . . . . 29
4.3.2 Volatile Random Access Memory . . . . . . . . . . . . . . . . . 30
4.3.3 Common Cause Failures and Risk Reduction . . . . . . . . . . . 33
4.3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

5 Software Architecture 34
5.1 The Software Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.2 The Software Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 35

6 Reflections 36
6.1 Further Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Bibliography 37

Appendix A: OBC Service Contracts 42

iv
List of Tables

2.1 Single Event Effects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.1 NUTS Satellite Functional Requirements . . . . . . . . . . . . . . . . . 12

3.2 OBC initialization requirements . . . . . . . . . . . . . . . . . . . . . . 15
3.3 OBC Housekeeping requirements . . . . . . . . . . . . . . . . . . . . . 16
3.4 OBC general requirements . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.5 OBC External interface requirements . . . . . . . . . . . . . . . . . . . . 17
3.6 OBC non-functional requirements . . . . . . . . . . . . . . . . . . . . . 18
3.7 OBC size, weight and power requirements . . . . . . . . . . . . . . . . . 19

4.1 ARM Cortex-M Processors . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.2 MCU comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.3 UC3A3, UC3C and SAM E70 comparison . . . . . . . . . . . . . . . . . 26
4.4 FRAM Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.5 SRAM, MRAM comparison . . . . . . . . . . . . . . . . . . . . . . . . 32

v
List of Figures

1.1 The NUTS modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2.1 The fault, error, failure, fault chain . . . . . . . . . . . . . . . . . . . . . 5

2.2 Sources of errors and service failures as presented in Reliable Computer
Systems [1]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 NUTS satellite as imagined in LEO . . . . . . . . . . . . . . . . . . . . 6

3.1 NUTS Backplane and OBC . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.1 OBC Hardware Modules . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.2 The Delfi-n3Xt OBC containing two MSP430 [2] . . . . . . . . . . . . . 23
4.3 NVM Comparison by NASA . . . . . . . . . . . . . . . . . . . . . . . . 29
4.4 Magnetoresistive RAM from Everspin [3] . . . . . . . . . . . . . . . . . 31

5.1 The software architecture of the OBC . . . . . . . . . . . . . . . . . . . 35

vi
Acronyms

ADCS Altitude Determination and Control System.

ANSAT The Norwegian Student Satellite Project.

ASC Andøya Space Center.

CCF Common-Cause Failures.

EPS Electrical Power System.

GCRs Galactic Cosmic Rays.

HiN Høgskolen in Narvik.

JTAG Joint Test Action Group.

LEO Low Earth Orbits.

MCU Microcontroller Unit.

NAROM Norwegian Centre for Space-related Education.

NSC Norwegian Space Centre.

NTNU Norwegian University of Science and Technology.

OBC On Board Controller.

RSP Resilient System Prototype.

vii
SEGR Single Event Gate Rupture.

SEL Single Event Latchup.

SET Single Event Transient.

SEU Single Event Upset.

SW Software.

UHF Ultra High Frequency.

UiO University in Oslo.

VHF Very High Frequency.

viii
Chapter 1
Introduction

In this chapter, the reader will be introduced to the Norwegian University of Science and
Technology (NTNU) Test Satellite project, as well as the scope of this report.

1.1 Project Background

In 2006, Norwegian Centre for Space-related Education (NAROM), the Norwegian Space
Centre (NSC) and Andøya Space Center (ASC) decided to initiate a student satellite pro-
gram; The Norwegian Student Satellite Project (ANSAT). The goal for this initiative was
to launch three CubeSats within 2014 [4]. Three projects were started, one at Høgskolen
in Narvik (HiN), one at the University in Oslo (UiO) and one at the NTNU [5]. The satel-
lite project at HiN, HiNCube, was completed and launched 21st of November 2013 [6].
Unfortunately, contact could not be established with the satellite after the launch [7]. The
HiNCube is, to date, the only satellite to have been launched from the ANSAT project, and
although the time frame of the initial initiative has been superseded, a successful student
satellite has yet to be launched.

1.2 The NTNU Test Satellite

The satellite is a double CubeSat, measuring 10 cm x 10 cm x 20 cm and weighing less
than 2.66 kg, which conforms to the CubeSat Standard. The satellite will carry a high
definition camera for earth observational purposes.

The satellite consists of:

• Electrical Power System (EPS)
• Altitude Determination and Control System (ADCS)
• Ultra High Frequency (UHF) Radio
• Very High Frequency (VHF) Radio
• OBC

1
 • Payload Camera
• Communication subsystem
• Antenna
• Mechanical Structure

The EPS is connected to solar panels and batteries, and is responsible for supplying the
power bus with enough electrical power to drive the satellite. The ADCS is entrusted
with the de-tumbling and pointing of the satellite. A communication subsystem is im-
plemented as a backplane and is used as a power and communication bus so that module
cards easily can be plugged in an out without disassembling the whole satellite. The satel-
lite is equipped with both a UHF radio and a VHF radio so that failures in one radio will
not cause a mission failure. When it comes to the mechanical structure, this project has
decided not to use the standard aluminium frame but rather aims to utilize composite ma-
terials (carbon fiber/epoxy). Although some minor components have been made of carbon
fiber in the past, launching a CubeSat with an all-composite primary structure has not yet
been done. As a gateway between the radios and the satellite bus, is the OBC.

Figure 1.1: The NUTS modules

1.3 The Purpose of the OBC

The main responsibility of the OBC is to monitor the health of the system and to take
necessary actions when situations demand for it. It monitors the health of the satellite by
periodically requesting health packages from software instances as well as polling sensors
for the different modules’ power consumption. It also monitors the satellite battery power

2
level, and sets the satellite state appropriately. In addition to this the OBC also acts as
a gateway between the satellite bus, and the radio link to ground station. The satellite is
designed as a distributed system with redundant functionalities implemented in different
modules. The OBC has a sister microcontroller at the UHF Radio module, with a very
similar hardware and software setup. OBC functionalities are therefore also implemented
in the UHF Radio module. The two modules rely on cold redundancy, meaning that only
one of the modules will take the role as an OBC at a time. Both UC3 microcontrollers
are connected to a Joint Test Action Group (JTAG) standard bus, and have the ability to
reprogram the other MCU if necessary.

1.4 The Approach Taken in this Report

Wertz and Larson states that analysis and designs are iterative, gradually refining both the
requirements and methods of achieving them [8]. When a hardware prototype was created
for the OBC, the requirements imposed on it was not yet fully known and thus no re-
quirements specifications were made. This report will therefor approach the OBC system
design by launching the next iteration of analysis and design. The author has chosen to
adhere to the Command and Data Handling System Baseline Process presented by Berget
in [8], as seen as the ”Level One steps” below. During this process the OBC requirements
will be analysed and both a functional as well as a non-functional requirement specifica-
tion will be created and presented. After this, an estimate of the size, weight and power
consumption of the OBC will be made. The report will then evaluate different hardware
components up against the OBC requirement specifications. The author will discuss and
compare different parts and setups and present his conclusion and recommendation for
what components that are to be used.

A software architecture that might satisfy the requirement specification will be presented
and the service contract it will conform to, for the rest of the system, will be presented.
Lastly, a reflection chapter is added to reflect on what has been done and what is next for
this project. The road map can be seen below.

Level One steps:

1. Identify which functions are to be performed by the system.
2. Identify requirements and constraints .
3. Determine complexity of functions.
4. Determine overall complexity.
5. Estimate size, weight and power for each component.
Level Two steps:
1. Determine suitable hardware components
2. Present initial top level software architecture design
Discussion and conclusion.

3
Chapter 2
Background

This chapter aims at presenting some of the terms and definitions that will be used when
discussing reliability and space radiation effects on electronics throughout this report.
There is also included a short summery of the most notable contributions to the OBC in
order to give the reader an understanding of what work already has been done concerning
the OBC.

2.1 Reliability Theory

This section aims at presenting some of the terms and definitions relating to reliability
theory.

Reliability is by Randell et al. defined to be a measure of the success with which a system
conforms to some authoritative specification of its behavior [9]. For a satellite launched
into orbit, reliability is of particular importance as repair after launch will not be feasible,
or at least not economically within the budgets for the NUTS satellite. Before proceeding
to how reliability may be achieved, it is important to define some further terms as to avoid
any misconceptions or misunderstandings.

2.1.1 Reliability, Failures and Errors

In reliability theory one usually differentiates between faults, errors and failures. In this
paper these terms will be used as they are defined in Reliable Computer Systems [1, p. 22]
• Fault is an incorrect state of hardware or software resulting from failures of com-
ponents, physical interference from the environment, operator error, or incorrect
design.
• Error is the manifestation of a fault within a program or data structure; errors can
occur some distance from the fault sites.
• Failure occurs when the delivered service deviates from the specified service; fail-
ures are caused by errors.

4
 Figure 2.1: The fault, error, failure, fault chain

The relationship between fault, error and failure can be seen in Figure 2.1. In addition to
these terms it is common to distinguish three types of faults; permanent, intermittent or
transient [10]. These terms are defined as below:
• Permanent describes a failure or fault that is continuous and stable; in hardware,
permanent failures reflect an irreversible physical change. An example is a bitflip in
the program memory, a broken wire or a software design.
• Intermittent describes a fault that is only occasionally present due to unstable hard-
ware or varying hardware or software states (e.g. as a function of load or activity)
• Transient describes a fault resulting from temporary environmental conditions. It
only remains in the system for a limited period of time before disappearing. They
can be dormant during all their lifetime (which means that they do not generate an
error), or can activate at some point (inducing an error). An example of such faults
is a bit-flip in a RAM memory.
The different categories of faults and their origins can be seen in Figure 2.2.

Figure 2.2: Sources of errors and service failures as presented in Reliable Computer Systems [1].

5
2.2 Space Environment
This section aims to give the reader a short introduction to some of the important concepts
and definitions concerning space radiation and the effects space radiation can have on
electronics.

2.2.1 Space Radiation

One of the aspects that makes the design of space technologies so challenging is the ex-
treme constraints imposed by the harsh outer space environment [11]. A satellite has to be
carefully designed to contend with void, extreme temperature variations, intense acceler-
ations and space radiation. The NUTS satellite is to enter a Low Earth Orbits (LEO), and
for most LEOs, the radiation environment is harsher compared to Earth’s surface, but not
as harsh as the higher orbits or deep space [12].

Radiation in space is produced by particles emitted from either the sun (solar radiation) or
from outside of the solar system, Galactic Cosmic Rays (GCRs). Radiation effects from
these solar and galactic emitted particles can not only cause degradation, but can also cause
failure of the electronic and electrical systems in space vehicles or satellites.

Figure 2.3: NUTS satellite as imagined in LEO

The two most common metrics used when talking about space radiation and electronics are
the effect of the radiation, and the absorbed radiation dose. The effect of the radiation can
be expressed by it’s Linear Energy Transfer or LET, which is expressed in M eV ·cm2 /mg.
The radiation LET describes how much energy an ionising particle transfers to the material
transversed per unit distance [13]. The material in question is usually Si for MOS devices
[14].

When it comes to the absorbed radiation dose, this is usually expressed in rad, where
one rad is equal to 0.01 joule per kg matter. The material is always specified in parenthe-
ses, e.g., rad(Si). However the international system of units (SI) uses gray ”GY”, where
1 GY = 100 rads. Due to the repeated use of rad(Si) in the bibliography for this paper,
rad(Si) will be used as the main metric for absorbed radiation.

6
One can by investigating the radiation toughness of components get an understanding
of the failure rate one might expect. When categorizing components base on radiation
tolerance, three categories are usually used; commercial, rad tolerant, and rad hard. The
characteristics parented in the list below are all gathered from NASA [15].

Commercial:
• Process and Design limit the radiation hardness
• No lot radiation controls
• Hardness levels:
– Total Dose: 2 to 10 krad (typical)
– SEU Threshold LET: 5 MeV/mg/cm2
– SEU Error Rate: 10−5 errors/bit-day (typical)
• Customer performs rad testing, and assumes all risk
• Customer evaluation and risk

Rad Tolerant:
• Design assures rad hardness up to a certain level
• No lot radiation controls
• Hardness levels:
– Total Dose: 20 to 50 krad (typical)
– SEU Threshold LET: 20 MeV/mg/cm2
– SEU Error Rate: 10−7 - 10−8 errors/bit-day
• Usually tested for functional fail only, risky
• Customer evaluation and risk

Rad Hard:
• Designed and processed for particular hardness level
• Wafer lot radiation tested
• Hardness levels:
– Total Dose: >200 krad to >1 Mrad
– SEU Threshold LET: 80-150 MeV/mg/cm2
– SEU Error Rate: 10−10 - to 10−12 errors/bit-day

NUTS, as most CubeSats mostly apply commercial of-the-shelf (COTS) components and
thus faces some serious risks of various radiation induced errors. A short introduction to
the most common effects will now be presented.

2.2.2 Total Ionizing Dose

Total ionizing dose (TID) is the accumulation of ionizing dose deposition over time. This
occurs mainly as an effect of protons and electrons, and the ionization creates charges or
electron-hole pairs in oxides. This could lead to circuit parameter changes and over time
make the circuit ceases to function [16].

According to NASA the expected radiation levels in Low Earth Orbit for higher incli-

7
nations (20-85 degrees) is to be about 1 − 10krad(Si)/year [15], and typical total dose
failure levels of microprocessors at 15-70 krad(Si) [12]

2.2.3 Single Event Effects

Electronic components are vulnerable to a number of effects when exposed to cosmic rays.
The collective term for the different failure mode occurrences is Single Event Phenomena
(SEP) or Single Event Effects (SEE). A brief overview of the most common SEEs can
be seen below. The SEU threshold LET is described as the energy level per amount of

Name Effect
Single Event Transient (SET) Soft intermittent fault Propagating through cir-
cuit.
Single Event Upset (SEU) Soft transient fault State change on latch or
memory.
Single Event Latchup (SEL) Apparent short circuit Can be mitigated with
power cycling Can cause destructive thermal
runaway.
Single Event Gate Rupture (SEGR) Permanent failure.
Single Event Burnout, SEB Permanent failure.

Table 2.1: Single Event Effects

material of the radiation that will trigger SEU events. The energy of most comic rays
range between 100 − 10000M eV · cm2 /mg [17], and as seen earlier the expected SEU
error rate for COTS in LEO is by NASA estimated to be around 10−5 error/bit per day.
This s of course a rough number as it doesn’t even mention for what type of memory it
is applicable. It does however give some understanding to in what magnitude errors can
be expected. If we assume this error rate is correct, a 128 kB of RAM would for instance
experience around 10 errors accumulated per day in orbit [12].

2.3 Earlier Work

This section will shortly present some of the theses that have contributed to the OBC in
the the past.

Internal Data Bus of a Small Student Satellite - Marius Lind Volstad

Volstad’s master thesis is the first and maybe the most substantiating contribution to the
OBC. In this thesis Volstad designs the inital hardware both for the backplane as well as
the OBC. Both the OBC and the backplane hardware are produced and tested to be mostly
functional. Some test drivers for the OBC hardware was also implemented to verify the
setup. Unfortunately as the thesis covers so much, many of the reasons and discussions
for choosing the various solutions have not been included.

8
Memory management and error handling in FreeRTOS for a CubeSat project - Diaa
Jadaan
Jadaan explains the different memory management schemes in FreeRTOS, as well as how
stack overflows can be detected. The paper also investigates how an exception handling
framework, Exceptions4c, can be used for exception handling in POSIX-based systems.
Jadaan states that in order for this to be useful in FreeRTOS porting is needed, but that this
is a complicated task that he was not able to finish within the timeframe given. The paper
also states that RAID 4 techniques can be used for error detection for embedded systems,
and a small demonstration is written in C++.

Implementing CSP over I2C for the new repository on the NTNU Test Satellite -
Erlend Riis Jahren
Jahren imports the Cubesat space protocol library into the NUTS project and implements
the NUTS Reliable Protocol on top of it. He also tests the various functionalities rather ex-
tensively and discusses the results. Jahren states in the report that ”almost all of the mem-
ory is already used in the FreeRTOS, CSP and NRP implementations, leaving only the
leftover memory available to be used in testing”[18]. He attempted to solve this by trying
to move the heap into an external SRAM, but it was never completed successfully. Despite
this he was however able to prove that most of the NRP functionalities were succesfully
implemented, where as the only exception was that of multiple concurrent streams, as a
server was not able to receive concurrent streams from two clients.

Mission Event Planning & Error-Recovery for CubeSat Applications - Magnus Haglund
Arnesen and Christian Elias Kiær
Arnesen & Kiær presents the most important system level mission event plans. Their pa-
per investigates the battery charging and discharging and presents a power budget, and a
design for an external watchdog is presented and tested.

Improvement in the Reliability of a Bi-Processing Unit Satellite Subject to Radiation-

Induced Bit-Flips - Mayeul Marcadella
In his thesis Marcadella presents and implements the Resilient System Prototype (RSP).
The RSP is a software project using the same microcontrollers as the OBC and the sister-
OBC. It implements cold dynamic redundancy between the two modules, where one can
coop and/or reprogram the other in the event of a failure. The project implements a sim-
ple JTAG controller, a program memory corruption detection and correction facility, and
a bit-flip injector for testing purposes. The setup was tested for 8 hours under a simulated
bit-flip density 250 times higher than the expected on-orbit rate [11]. The downsides are
that the project has not been tested on the actual OBC, the project uses a USART that is
not implemented in the OBC design and there are also quite some work left as the project
only emulates the use of external memories and doesn’t actually interface any external
memories itself.

Error Detection and Correction for Low-Cost Nano Satellites - Kjell Arne Ødegaard
Ødegaard evaluates low-cost measures for dependability and robust Error Detection and
Correction for use in applications such as nano satellites. Different methods are evaluated,

9
with the main result being the mitigation failures due to bit-flips in system memory by
using BCH codes [19]. An implementation is then made, tested and the result is discussed.

As can be seen form the theses presented above, there has been written multiple papers
on how reliability can be assured for the OBC through the use of various software tech-
niques. This paper therefor focuses on the implementation design of the actual OBC, using
the already documented research of the former theses as a starting point. Before an archi-
tecture can be decided upon, one has to create a requirement specification to ensure that
one solves the correct problem. This will be presented in the next chapter.

10
Chapter 3
Requirement Specification

In this chapter, the requirements imposed upon the OBC will be analysed and discussed.
A functional, as well as a non-functional requirement specification for the OBC will be
presented. After the specifications have been formed, the complexity of the OBC will be
determined and a size, weight and power budget will be estimated.

3.1 What Are Requirement Specifications and Why Are

They Important?
By far the most common project risks in system development are poor requirements and
poor project planning. Researchers at Hewlett-Packard, IBM, Hughes Aircraft, TRW, and
other organizations have found that purging an error by the beginning of construction al-
lows rework to be done 10 to 100 times less expensively than when its done in the last part
of the process, during system test or after release [20].

The NUTS satellite has an official mission goal list that has been used as guidelines to
what is to be implemented. In addition to this, Arnesen and Kiær presented a functional
requirement specification for the satellite in the paper ”Mission Event Planning and Error-
Recovery for CubeSat Application” [12]. These are however not made with consideration
to each other and are partially redundant. This chapter will therefor first unify the differ-
ent functional requirement specifications for the satellite before also constructing one for
the OBC, as up until now there has been none. In addition to this, guidelines on how to
document requirement and design implementations for subsystems of the NUTS satellite
are also proposed.

11
3.2 Satellite Requirements
A functional requirement specification specifies the general demands that are to be sat-
isfied by the system. The specification should be general and should not entail details
of how the system is constructed [21]. Though there are no official satellite requirement
documentation, a general list of requirements was proposed by Holmstr{om in 2012 [22],
in addition to one posted inside the NUTS private Wiki pages. These two lists now form
the basis for the new satellite functional requirement documentation that can be seen in
table 3.1. The requirement specification has been designed to entail all higher order de-
mands imposed upon the satellite. An effort has been made to exclude any demands that
are means to higher goals or are only valid under certain implementation choices. Like-
wise, non-functional requirements such as reliability and error handling are not included,
as these are considered to be means towards a goal, rather than a goal on their own.

ID Description
R01 Deliver a tested satellite according to mission specifications.
R02 Transmit a beacon signal receivable for radio amateurs.
R03 Confirm successful de-tumbling.
R04 Establish two-way communication and receive full telemetry.
R05 Test the payload camera.
R06 Initiate camera pointing.
R07 Initiate camera sequencing to capture meaningful images
R08 Receive a valid series of images

Table 3.1: NUTS Satellite Functional Requirements

3.3 NUTS Specification System

As there were no rules or guidelines for how requirement or design specification should
be done for the NUTS project, it was deemed necessary to establish certain guidelines to
enforce uniformity across the project documentation. These guidelines will be presented
below.

3.3.1 Creating a Requirement Specification

All modules should have at least one functional requirement specification and one design
specification. The functional requirement specification should specify what the purpose
of the module is. All tasks and services that are to be performed by the module for the
rest of the system should be included. Special care should be taken not to include any
implementation specific details, as these are to be included in the design specification
and not in the functional requirements. While the functional requirements are to describe
what kind of services a module should offer, the design specification shall describe how
these services shall be implemented. There can be multiple designs that can satisfy one
functional requirement specification, but only one will be implemented, and this is of

12
course the one that should be described in the design specification. Whenever a design
choice is made, new requirements are often introduced to the system as a consequence of
the design choice. These sub requirements should be documented as well by referencing
the design choice that introduced them.

3.3.2 Naming Convention

It is recommended that all modules are documented congruently. A proposed naming con-
vention for requirement and design specification will now be presented.

The naming convention is perhaps best explained though an example requirement spec-
ification such as this: R04-OBC-LOG-001: The OBC must keep a log of various house-
keeping data.
• R04 - The requirement is a sub requirement for ”R-04: Establish two-way commu-
nication and receive full telemetry.”
• OBC - The name of the satellite module the requirement is imposed upon (see list
of names further down).
• LOG - This is just a sub module, all requirement IDs containing this keyword will
be concerning the logging feature.
• 001 - This is the unique number of the ID differing this ID from the IDs of other
requirements in the same sub module.

Example design specification: D04-CAM-012: Captured images shall be stored on a SD-

card and only be sent to the OBC upon request.
• D04 - This means the design choice is aiming to contribute to the satisfying of the
”R-04: Satellite must be able to capture meaningful images on demand, and be able
to send this payload data to the ground station”.
• CAM - This is the name of the module, here referring to the camera module.
• 012- In this example a flat module hierarchy is assumed for the camera module, thus
the entire ID contains only two module specifiers and an unique ID number.

The rules abstracted from the examples above will now be presented for a more general
case. A specification ID is composed of:
• Three digit code linking the spec to the grander scheme of the satellite goals. Made
up of:
– One letter referencing whether the spec is concerned with a system require-
ment (R), or a design choice/implementation(D).
– Two digit number for the grander requirement the spec is contributing to sat-
isfy. If the spec is concerned with the satellite in its entirety, the 00-number
can be used.
• Two digit number for the grander requirement the spec is contributing to satisfy. If
the spec is concerned with the satellite in its entirety, the 00-number can be used.
• Three letter code indicating the module.
• As many additional three lettered codes as needed to properly describe the spec.
• A unique number in the range 0 to 999

13
Proposed names for the top modules:
• ADC - The Attitude Determination and Control System (ADCS)
• CAM - The camera module
• COM - The Internal satellite communication bus
• EPS - The Electrical Power System
• OBC - The On Board Computer
• UHF - The Radio OBC module containing the Happy Gecko and the UHF radio

Figure 3.1: NUTS Backplane and OBC

14
3.4 OBC Functional Requirements
As earlier work associated with the OBC has been concerned with reliability rather than
functionality, no OBC requirement specification has been articulated. The author thus
presents a functional requirement specification in the following section.

3.4.1 Satellite Initialization

After the satellite has been ejected from the Picosat Orbital Deployer (P-POD), the railing
switches will be released and the satellite will be activated. Following the CubeSat speci-
fication, the antennas must wait at least 20 minutes to deploy. Though there are redundant
systems for releasing the antennas, the OBC should be able to run a first-time start up of
the satellite that includes the release of the antennas. The list of actions to be preformed
by the OBC is based on the requirements described for the satellite start-up by Arnesen
and Kiær[12]

R00-OBC-INI-000 INI=INITIALIZATION.
The OBC must run an initiation of the satellite upon de-
ployment
R00-OBC-INI-001 The OBC must issue an antenna deployment signal
R00-OBC-INI-002 The OBC must start beacon transmission from the radios
R00-OBC-INI-003 The OBC must issue a de-tumble command to the ADCS
upon initial deployment
R00-OBC-INI-004 The OBC must enter normal operation mode

Table 3.2: OBC initialization requirements

3.4.2 Satellite Housekeeping

The command and data handling systems (CDH), such as the OBC, performs two major
functions. It receives, validates, decodes and distributes commands to other spacecraft
systems and gathers, processes, and formats spacecraft housekeeping and mission data for
downlink or use by an onboard computer [8]. This section is concerned with the latter,
namely the spacecraft housekeeping. The satellite functional requirement R04 demands
that full telemetry is sent back to the ground station and as seen from the CDH system
description above, this handling should be implemented in the OBC. Since this is a system
level functional requirement specification, care has been taken not to include too much
detail, as to what kind of sensors are to be used or how often they should be sampled.

15
 R04-OBC-HKP-000 HKP=HOUSEKEEPING.
The OBC must monitor and maintain the health of the satellite.
R00-OBC-HKP-001 The OBC must periodically check and act upon its own integrity.
R00-OBC-HKP-002 The OBC must periodically check and act upon the health of
other modules.
R04-OBC-HKP-003 The OBC must keep a log of the satellite’s health

Table 3.3: OBC Housekeeping requirements

3.4.3 OBC Executables

The first major function of the OBC is the receiving, validation, decoding and distribu-
tion of commands to other spacecraft systems. As can be seen from the table below, all
of the requirements are considered to be a sub-requirement of R01-OBC-EXE-000 ”The
OBC must be able to execute commands on demand from the ground station”. This re-
quirement is meant to assure that the OBC supports the ability to execute commands both
immediately as well as scheduling for execution at a given later time.

R01-OBC-EXE-000 EXE=EXECUTABLES.
The OBC must be able to execute commands on demand
from ground station
R01-OBC-EXE-CMD-000 CMD=COMMANDS.
The OBC must support a set of commands.
R00-OBC-EXE-CMD-001 The OBC must be able to perform a full, and/or partial
reset of the satellite.
R01-OBC-EXE-TIM-000 The OBC must be able to schedule commands to be exe-
cuted later.
R01-OBC-EXE-TIM-001 The OBC must keep track of time.
R01-OBC-EXE-TIM-002 The OBC must be able to set alarms to schedule future
executions.

Table 3.4: OBC general requirements

16
3.4.4 Satellite Executables
For the OBC to be of any use to the satellite, it must be able to interface with other satellite
systems. One of the most important of these systems, is the radio, as without control over
the radio no contact can be made with Earth. The first interface requirement for the OBC
is thus that it must interface with the radio. For any other functions that involve other
satellite modules, the OBC must be able to interface these as well. Each module has been
given a separate keyword so that all interface requirements related to that module can be
grouped under this ID.

R04-OBC-EXT-000
R04-OBC-EXT-RAD-000
R03-OBC-EXT-ADC-000
R03-OBC-EXT-ADC-001
R03-OBC-EXT-ADC-002
R03-OBC-EXT-ADC-003
R03-OBC-EXT-ADC-004
R07-OBC-EXT-CAM-000
R07-OBC-EXT-CAM-001
R07-OBC-EXT-CAM-002
R07-OBC-EXT-CAM-003
R08-OBC-EXT-CAM-004
R08-OBC-EXT-CAM-005
R07-OBC-EXT-CAM-006
EXT=EXTERNAL.
The OBC must interface with the other modules
The OBC must interface with the on-board radio
ADC=Altitude Determination and Control System.
The OBC must be able to configure and control the
ADCS.
Module reset, module power down.
Start de-tumbling.
Stop de-tumbling.
Point in a given direction.
CAM=CAMERA PAYLOAD.
The OBC must be able to configure and control the cam-
era.
Module reset, module power down/up, request statistics.
Schedule image capturing
Retrieve images, and send to ground station
Retrieve thumbnail images and send to ground station
Delete images
Set; gain, frame rate, frame size, and exposure time.

Table 3.5: OBC External interface requirements

17
3.5 OBC Non-Functional Requirements
Nonfunctional requirements specify system properties, such as reliability and safety [23].
Table 3.6 shows the top-level non-functional requirements for the OBC. The requirements
are still quite general and generic, and are expected to grow in details as the design process
matures.

ID
R00-OBC-NON-DUR-000
R00-OBC-NON-AVA-000
R00-OBC-NON-AVA-001
R00-OBC-NON-SUR-000
R00-OBC-NON-REL-000
R00-OBC-NON-REL-001
R00-OBC-NON-REL-002
R00-OBC-NON-REL-003
R00-OBC-NON-TES-000
R00-OBC-NON-MAI-000
Description
DUR=DURATION
Mission operation is 3 months.
AVA=AVAILABILITY
The mission capable rate should be ass high as possible, and
should not be less than 50%
The OBC must be able to handle multiple concurrent requests.
SURVIVABILITY
The OBC must survive its natural environment (space)
REL=RELIABILITY
The OBC mean time to failure (MTTF) should be greater than
the duration of the space mission.
No single failing task or component shall end the satellite mis-
sion.
The OBC must be able to recover from failures.
Execution of less-important tasks shall not affect the timeliness
of higher-prioritised tasks.
TES=TESTABILITY
A formal test procedure with measurable results must be enun-
ciated and performed.
MAI=MAINTAINABILITY
Code and documentation must be made easy to understand

Table 3.6: OBC non-functional requirements

3.6 Determining the Complexity

The complexity of the OBC is determined by the functions it must perform for the system.
For earlier proposals for the OBC it was assumed that the images from the payload camera
should both be processed and stored by the OBC. The author of this paper has however
argued that these functions are better implemented in the camera module itself. The argu-
mentation for this, is that this makes for better modularization, safer implementation and
eases the joint system demands.

The OBC does not need to be capable of image processing, as it is sufficient to simply
relay packages from the camera module. Due to the use of E-fuses to cut off power in
the event of SELs, there are no hard real time demands for the NUTS satellite. The most

18
resource exhaustive tasks of the OBC then seems to be the error checking itself. Ødegaard
argues that the best way to mitigate SEE caused bit flips is by using BCH codes which are
rather resource exhaustive [19]. BCH codes can be implemented in many different ways,
but as an example a BCH decoder can be implemented using tools such as pruned Fast
Fourier Transform (FFT) and gaussian elimination [24]. This warrants a microcontroller
capable of some more advanced mathematics and perhaps added hardware support for dig-
ital signal processing (DSP) or floating point calculations. The author therefor categorizes
the complexity as normal; some expensive processing is to be done, but there are no hard
real time demands for them to finish within.

3.7 Estimating the Size, Weight, and Power

The estimation of size, weight and power may not be of immediate importance for the
OBC designer at this point. Much more accurate estimates could have been made after
the next design iteration. However, as the satellite is a composite system, implementation
decisions made in one module will affect others. By investigating the requirements these
modules pose on the rest of the system at an early stage, any incompatibilities can be de-
tected and fixed at a much lower cost.

To estimate the size, weight and power requirements for the NUTS OBC one can inves-
tigate the already made hardware and use these measurements as preliminary metrics for
the estimation of size and weight. The volume is found by measuring the circuit board and
multiplying the width and length with the height (measured as the distance from the top
of the tallest top-side component to the top of the tallest component on the bottom-side).
As the OBC module measures 9x9x1.3 cm, the volume is 105.3 cm3 . The weight is found
to be 28 grams by weighing with a kitchen scale. Volstad measured the worst case power
consumption of the initial OBC version to be around 150 mW. He does not mention at
what frequency the OBC is running, which is unfortunate as this is one of the main factors
in the power consumption. In order to get more confidence in the power consumption esti-
mate, the theoretical power consumptions of one of the highest preforming candidates (to
be presented in the next chapter) is used. That is the SAM E70, and running at 300 MHz,
with all peripherals except USB and Ethernet MAC enabled. The typical power consump-
tion then adds up to 116 mA or 382 mW [25]. With the added power consumption found
in the datasheets of the components used for the original OBC the estimated peak load is
set to be 550 mW.

Parameter Typical Estimate max

Size [cm3 ] 105.3 105.3
Weight [g] 38 50
Power (nominal)[mW ] 45 550

Table 3.7: OBC size, weight and power requirements

19
Chapter 4
Determining the Components

In this chapter, the different hardware possibilities and restrictions for the OBC will be
discussed. Various microcontrollers and external memory will be presented and compared
against each other and the requirements of the OBC.

4.1 Overview
The originally presented OBC in Volstad’s thesis of 2011 consisted of a 32-bit MCU
(At32UC3A3256), a NAND flash memory for housekeeping logs, an static RAM (SRAM)
memory for processing variables, an one time programmable (OTP) memory for safe stor-
age of module firmwares, USB interface and a wireless intra-satellite communication mod-
ule (NRF24LE1)[26]. Volstad wrote drivers to test both SRAM and the NAND-flash and
measured the maximum power consumption to be around 45 mA or about 150mW. The
design also included a sister module with the same microcontroller and a very similar hard-
ware setup, enabling for redundant functionalities implemented in the two modules. Since
the original design, the OTP memory has been replaced by ferroelectric RAM (FRAM)
memory. The work on the intra-satellite communication module has been discontinued
due to lack of interest/workforce. It has therefore been removed from the design. The
USB connector has also been removed from the design. Unfortunately, though all of these
choices probably have been discussed thoroughly, they are only sparsely documented. As
Volstad’s thesis focuses on many aspects of the satellite, specific hardware choices are not
always adequately discussed. Most of the OBC hardware setup is therefor without argu-
mentation or justification and in need of reviewing. The current OBC setup will therefore
be explored and discussed in the next chapters. This is done to enforce that all design
choices are traceable, well thought-out, and made on the right premises. This ensures that
later revisions can easily incorporate or justly replace any component of the design, creat-
ing new revisions, instead of unnecessarily scrapping previous designs and starting from
scratch multiple times.

20
 Figure 4.1: OBC Hardware Modules

The latest list of the parts that makes up the OBC can be seen in the list below and in
figure 4.1, which also displays the interfaces of the microcontroller.
• At32UC3A3256
• 4 Mbit FeRAM B85R4001
• 16 Mbit SRAM IS61wv102416BLL-10TLI
• 32 GB NAND FLASH (MT29F16G08ABACAWP-ITZ:C)
• JTAG bus
• I2 Cbusinterf aceother

As this paper is written, there is being made an attempt to replace the I2 CbuswithaControllerAreaN etwor

4.2 Choosing a Microcontroller

A microcontroller consists of a microprocessor, on-board memory and I/O devices, and
can be a very efficient way to implement digital systems [27]. For this reason it has been
decided that the OBC control functions should be implemented through a microcontroller
as they are easily reprogrammed, can run complex algorithms and can be quite power
efficient. In this chapter different microcontrollers will be compared and discussed and a
fitting microcontroller will be chosen for the OBC. Using a bare-bone microprocessor has
also been considered but due to the additional implementation costs, knowledge required
and tight project timeframe it has been deemed unfit.

4.2.1 Microcontroller Requirements and Criteria

The constraints imposed upon the OBC are mainly related to reliability, computational
power and power consumption. As the satellite is getting all it’s power from it’s solar pan-
els, the power budget is limited. Arnesen & Kiær estimated the normalized charging power

21
to be 3.205 W, while the combined satellite power consumption was estimated to reach as
high as 8.791 W [12]. A maximum power consumption for the OBC module (MCU plus
memories) has been estimated to 550 mW, however the average power consumption must
be much lower if the batteries are not to be drained out. For the initial mode, when the
satellite has been released, but not yet started detumbling, the instantaneous power con-
sumption is estimated to be 3025 mW (only 180 mW less than the average charging power)
[12]. This estimate assumes an average power consumption of the OBC MCU and mem-
ories to be 330 mW. The satellite power consumption is expected to increase as normal
mode is engaged, and it is therefor imperative that a good trade/off between computation
power and power consumption is found for the OBC.

Another criteria that will be used to evaluate the microcontrollers is the practical issue
of complexity and implementation time. The NUTS project demands a fully functional
implementation, and whatever work is done by the author will be left behind for another
student to continue. It is thus essential that the work is easily comprehensible and as com-
pleted as possible. It is for this reason bare-bone microprocessor-solutions are not con-
sidered. Also, when considering different ARM Cortex-M microcontrollers, when similar
processors are employed by different vendors, the author will favor those from Atmel due
to Atmels involvement in NTNU and the students familiarity with Atmel development
tools.

Micrcontroller Memory Requirements

The internal memories of the microcontroller, as well as the possible external memory
interfaces are important features to consider when choosing a microcontroller. The NUTS
OBC will contain a sizable application that might make smaller microcontrollers unsuited.
To get a feel for the expected code size, earlier prototypes of aspects of the OBC were
inspected with concern to code size. By compiling and inspecting the program code from
Jahren’s CubeSat Space Protocol (CSP) test-application written in ”Design and Implemen-
tation of a Reliable Transport Layer Protocol for NUTS” [18], it was discovered that this
simple program uses about 115 KB of program memory. The Resilient System Protoype
proposed by Marcadella in ”Improvement in the Reliability of a Bi-Processing Unit Satel-
lite Subject to Radiation-Induced Bit-Flips” [11] was also inspected and uses around 74
KB of program memory. As these applications need to be merged and incorporated with
additional application code it is likely that the end program code will take up more than
128 KB of memory space. This may complicate program storage and loading when using
microcontrollers with 128 KB or less internal flash memory, thus microcontrollers with
larger memory will be preferred.

Microcontroller Interface Requirement

Any microcontroller with inherent support of external memory bus will have an advantage,
as it is very likely the microcontroller will have to interface external memories, more on
this in Section 4.3.

New in the latest design revision of NUTS is the switch from I2C to CAN bus as the

22
internal memory bus. There is therefor a demand that the microcontroller can interface
with the CAN bus either through an external CAN controller (e.g. via SPI) or preferable
with an internal CAN controller. Microcontrollers with inherrent support for CAN will
therefor be preferred, but are not imperative as external controllers can be used.

4.2.2 The Competitors

Texas Instruments MSP430 has been used in the satellites; Skycube, ZaCUBE-1 and
Delfi-n3Xt, all of whom can be considered successful as they all are still active [28].
Atmel ARM7 is another microcontroller that has proved popular as it is used in AAUSAT-
II, AAUSAT-3 as well as in the ADCS of the Delfi-n3Xt. Other interesting microcon-
trollers can be the atcan128, which have been extensively used in the AAUSAT-3, or
the STM32F103 (which contains a Cortex-M3 from ARM) and was used in the satellite
ECTCube-1. It should also be mentioned that GOMSpaces newest product line includes
an AT32UC3C microcontroller as the OBC. This is from the same microcontroller familiy
as the MCU currently used in the NUTS OBC.

Figure 4.2: The Delfi-n3Xt OBC containing two MSP430 [2]

For space legacy reasons, and for it’s low power consumption the MSP430 will be consid-
ered. ARM Cortex-M microcontrollers are becoming more and more popular and might
also be considered viable options. The Cortex-M family is a product line of microproces-
sors especially designed for microcontrollers and these will therefor be evaluated. A table

23
of the different Cortex-M processors can be seen in table 4.1. The performance efficiency
is measured in CoreMark per MHz, and the Cortex-M1 is not included as this is designed
specifically for implementation in FPGA. From table 4.1 one can see that if low power con-

Core Device Freq. Eff. Comment

M0 SAMD20 48 MHz 2.33 Designed for small size and cost.
M0+ SAML21 48 MHz 2.46 Designed for energy efficiency.
M3 SAM3S 100MHz 3.34 Designed for highly deterministic real-
time applications.
M4 SAM4E 120MHz 3.40 Same as M3, but additional focus on DSP.
M7 SAME70 300MHz 5 The newest and highest performance mem-
ber of the energy-efficient Cortex-M pro-
cessors.

Table 4.1: ARM Cortex-M Processors

sumption is important the M0+ might be a viable option, however if computation power
is emphasized, one could go with the higher order cortexes such as the Cortex-M4 or the
Cortex-M7.

Lastly, the current OBC microcontroller AT32UC3-family should be compared to see if the
benefits of changing the microcontroller outweighs the additional implementation costs.

4.2.3 Microcontroller Discussion

A comparison between the microcontrollers can be seen in table 4.2. All numbers have
been gathered from the respective datasheet [29][30][31][25]. It is not straight forward
to compare the power consumption of the different devices based on the values given by
the datasheets, as they all are measured with different setups. The power consumptions
that have been included should therefor be seen as to give the reader and understanding of
the magnitude differences and are not necessarily directly comparable. It should also be
mentioned that the active power consumption measurements are when running the CPU at
maximum clock frequency.

The MSP430 has proved it’s reliability through numerous space missions and has one of
the lowest power consumption as well. However its maximum CPU clock frequency is
24 MHz and it only uses a 16 bit instruction set. It has a low power consumption, but at
the expense of the computational power. This means that for computationally expensive
tasks the microcontroller will have to stay in active mode a lot longer than it’s competi-
tors in order to finish the calculations. This may in turn raise the power consumption and
although the maximum power consumption still is lower, the total power consumption
might be more, depending on the task. There is however one flavour of MSP430, nam-
ley the MSP430FR which is of special interest to space missions. The MSP430FR uses
FRAM memory instead of flash for non-volatile storage, and as FRAM is inherently more
radiation resistant than flash [32], this makes for safer storage of program code as well as

24
 Characteristics MSP430 SAML21 SAM4E SAM E70
Frequency [M Hz] 24 48 120 300
Flash [KB] 128 (FRAM) 256 1024 2048
SRAM [KB] 2 40 128 384
External memory bus no no yes yes
Power Consumption Active [mA] 2.2 3.5 44 100
Power Consumption Sleep [µA] 0.32-285 1.2-185.5 2-10000 5.8-24000

Table 4.2: MCU comparison

application data. However as the maximum available memory size is 128 KB and there
is no external memory interface [29], this might cause some serious memory constraints
on the application, as we could see from the constraint section above. In addition to this,
the MSP430s only have a 2KB SRAM, though any unused FRAM can be used as volatile
memory, it is unlikely that there will be any FRAM leftover memory for this. The fact
that none of the MSP430 support any external memory bus puts them at a disadvantage.
A solution might be to interface external flash through SPI or to implement a bit-bang
external parallel memory bus, however a microcontroller with a bigger program memory
or at least an external memory bus interface would be preferable as SPI flash suffers from
slower speed, and bit-bang parallel buss from added complexity.

The SAM L21 features an ARM Cortex-M0+ and has a power consumption compara-
ble to the MSP430. It has up to 256 KB embedded Flash and 40KB SRAM. However,
none of the Cortex-M0/Cortex-M0+ microcontrollers support external memory bus nor
have support for CAN. The power consumption restriction of maximum average of 100
mW turns out to leave quite some room for the power consumption of the microcontoller
and can be satisfied by using the higher order arm cortex-M as well.

If CAN controller and external memory bus is emphasized one can consider SAM4E
(Cortex-M4) or SAM E70 (Cortex-M7). The SAM E70 can be run at a much higher
frequency (300MHz compared to SAM4E’s 120MHz) and has support for additional fea-
tures. The downside is the added power consumption. However as SAME70 inherently
supports Error Correcting Codes (ECC) in both data and instruction chaches, as well as
memory Integrity Check Monitor (ICM), it seems the better option for space applications.
SAME70 is therefor considered the best candidate as a replacement for the currently used
UC3A3. In addition to this another member of the UC3 family with a larger non-volatile
memory and support for CAN will also be evaluated. The UC3C is quite similar to the
UC3A3, and most of the code written for either device is easily ported from one version
to the other. Since current development on the back-plane may warrant CAN support, and
the fact that the UC3C has double the non-volatile memory and support for hardware ac-
celerated fixed point calculations makes it an appealing candidate. The next section will
therefor investigate the pros and cons of these two UC3 microcontrollers to that of the
SAME70.

Comparing the SAM E70 to the UC3 currently being used in the OBC, one can see that

25
though memory checking already is implemented for the UC3 there will be no additional
implementation cost by switching to the SAM E70 as the Integrity Check Monitor can be
used for memory checking. In fact, using the ICM will be more power efficient as ICM
uses DMA, hashing functionalities and other hardware implemented functions decoupled
from the CPU. The SAME70 therefore seems a viable option as the microcontroller for
the OBC. The table below sums up the advantages and disadvantages of using the UC3s
versus the SAM E70.
Value UC3A3 UC3C SAM E70
Frequency [M Hz] 84 66 300
Flash [M Hz] 256 512 2048
SRAM [KB] 64+64 64 384
Power Consumption Active [mA] 40 40 100
Power Consumption Sleep [µA] 31-100 31-100 5.8-24000
ECC implemented in HW and SW Only SW Only HW
Mem. Integrity Check SW SW HW

Table 4.3: UC3A3, UC3C and SAM E70 comparison

From table 4.3 one can see that the SAME70 indeed is a viable option, however the fact
that the SAM E70 does not have any boot-pins means that it must boot from the same place
in memory each time. If a radiation induced bit flip incurs in this section, the microcon-
troller will be put into an eternal failure state. This means that there will be a single point
of failure in this memory. The likelihood of such a critical error to occur is hard to accu-
rately predict, yet still the next section will try to explore this in order to say something
about the risk involved.

The Probability of Catastrophic Failures due to Radiation Induced Bit flips

The typical error rate for COTS in LEO is said to be 1/100000 per bit per day [15]. This
is a rough number, but will be used for this probability calculation. If more accurate num-
bers are found later, they can easily be applied to the formula that is being deduced in this
section, in order to find more accurate estimates. If we now assume constant failure rate,
z(t) = λ, the probability of a failure will grow exponentially so that the probability of a
failure having occurred after a long time will be large [21]. The mean time to failure will
then be given by:
R∞
MTTF = 0
tf (t) dx

1
For constant failure rate of λ = 105 per bit per day, this evaluates to a MTTF for one
single bit to be:
R∞ R∞
MTTF = 0
tf (t) dx = 0
e−λt dx = 1
λ = 105 days.

If we now assume that the failures are independent of each other (correlation equal to
zero), we can estimate the mean time to failure (due to radiation induced bit flips) for a

26
program residing in memory based on it’s code size. First we can calculate the probability
of one or more bit flips in a memory section after (τ ) days:

P (Section compromised) = 1 − P (Section OK) = 1 − ((1 − κ)η )τ ,

where κ is the failure rate for one single bit per day, and η is the number of bits.

The MTTF can now be found by:

1 1 1
MTTF = λ = P (Section compromised) = 1−(1−κ)η )

Let’s now investigate the MTTF for a two stage bootloader scheme, where the first stage
is to fetch a program image from external, safer memory, while the second stage is to run
the fetched code. In this scheme only the code for the first stage is stored in internal (en-
dangered) memory, we assume the external memory is perfectly safe. However, one single
bit flip in the first stage of the bootloader will cause the complete and permanent failure of
the entire system. If we assume that the size of the first stage bootloader is the same as the
size of the ProgramLoader implemented in the current OBC. In Marcadellas master thesis,
he states that the ProgramLoader is less than 2Kbit. This gives:

1 1
MTTF = 1−(1−κ)η ) = 1
1−(1− 100000 )2000 )
= 50.5 days.

This means that a design with a two stage bootloader (with no error correction) is likely to
fail catastrophically in less than two months. A plot of the MTTF as a function of program
memory size can be seen in below.

250

200
MTTF in days

150

100

50

0
0 1,000 2,000 3,000 4,000 5,000
Code size in bits

27
As re-programing already is implemented for the UC3s [11], the UC3s do not have this
single point of failure, as a redundant microcontroller can reprogram a defect one if a bit
flip should occur in the boot section. Unfortunately the bit bang JTAG that has been im-
plemented is rather undocumented and device dependent and thus not easily ported. It is
likely that this would add greatly to the expected implementation time. This, in addition to
the Cubesat Space Protocol already being ported and tested on UC3 but not for SAME70,
results in the expected implementation time with SAME70 to be longer than that with
UC3. Also the fact that the UC3 is currently being used in commercial product lines of
GOMSpace, speaks at least somewhat to the expected radiation hardness of the device. As
Cortex-M7 microprocessor for space missions is unheard of to the author, not much can
be said for the radiation toughness.

If time to completion is emphasized, the least expected time comes from continuing with
the current OBC MCU, the UC3A3. It is uncertain whether the non-volatile memory of
256 KB will cause complications as the code size grows. As the UC3 series are so alike
and code easily can be ported from one device to another, the author recommends the
switch to the UC3C0512C microcontroller which is the biggest of the UC3C series. This
is mainly due to the added CAN and floating point support, but also in order to minimize
the chance of running out of internal program memory.

4.2.4 Microcontroller Conclusion

Although the SAME70 is an exciting and capable replacement candidate for the OBC
MCU, it is decided that the UC3 will be kept due to the code base already made, and
thus the expected shorter time-to-completion for this design. To accommodate the latest
changes in bus architecture the author does however recommend that the At32UC3A3256
MCU is swapped with the UC3C0512C MCU.

4.3 Chosing External Memories

The chosen OBC MCU must interface external memories if the requirement specification
is to be satisfied. The latest hardware revision for the OBC contained the At32UC3A3256
microcontroller with the following three external memories:
• 4 Mbit FeRAM (B85R4001)
• 16 Mbit SRAM (IS61wv102416BLL-10TLI)
• 32 GB NAND FLASH (MT29F16G08ABACAWP-ITZ:C)
The flash and SRAM memories have been present in the design since the first revision
proposed by Volstad in [26]. The flash aims to offer non-volatile storage for non-essential
data while the additional SRAM is to mitigate any memory size issues that might arise due
to large heap and stack sizes. The FRAM was incorporated into the design in 2013, and
replaced the original OTP memory (however, no justification or reason for this could be
found by the author of this paper). The FRAM is more tolerant to radiation than flash and is
most likely included to offer safer non-volatile memory storage of critical flight data, such
as program-images. Though there are quite a couple of theses evaluating different software
methods for the NUTS OBC, there has not been written any concerning the hardware of

28
the OBC since the initial thesis of Volstad [26]. A proper discussion for the choices of
types and sizes for the OBC memories has thus not been made, and an attempt will be
made in the following section.

4.3.1 Non-Volatile Memory

The OBC specification demand for a log to be kept cf. requirement OBC-002-003. The
only way for this logged data to prevail a system wide power cycle is to be stored in non-
volatile memory. Though the log is not essential for the mission success there may be
other data that might jeopardize the mission if inadvertently altered, e.g. by radiation in-
duced bit flips. An example of this, may be boot images or other flight critical data. An
attempt should therefore be made to find a non-volatile memory that is resistant to radi-
ation. The different memories compared here will be NOR-Flash, NAND-Flash, FRAM,
MRAM, and P/CRAM. A comparison of these memories can be found in figure 4.3. The

Figure 4.3: NVM Comparison by NASA

numbers are gathered from data published by NASA [33]. In this comparison MRAM
seems attractive for its unlimited endurance, unlimited retention, radiation hardness, and
low standby power. The MRAMs biggest shortcoming is its limited density, where NAND
Flash is the clear winner. And for ultra-low-power applications FRAM seems to be a good
solution.

The characteristics of the currently used FRAM can be seen in the table 4.4. It is clear
that the microcontroller must have non-volatile memory to load it’s program code from.
For reliability purposes this program image should also be stored in a memory that can be
considered to be radiation tolerant. The FRAM seems adequate for this purpose as well
as for storing flight critical data. However, with it’s limited size it might pose a problem
concerning the log that needs to be kept. It is not known how many log entries the log must
be able to contain, and for this reason a larger memory is needed for the log. As the log
is not crucial for the operation of the satellite, the previously proposed NAND flash may
be adequate for this purpose. Different flash memories for NUTS have already been dis-

29
cussed by Marcadella [11], and will therefor not be included in the discussion of external
memories in this report.

Parameter Value
Memory Type FRAM
Size 4 Mbit.
Bit configuration 524,288 words x 8
Interface Parallel 8-bit
Power Consumption standby 50 µA
Power Consumption operation 15 mA
R/W Endurance 1010 .
R/W Speed 150 ns / 150 ns

Table 4.4: FRAM Characteristics

4.3.2 Volatile Random Access Memory

Jahren reports encountering issues due to running out of internal memory of the UC3 while
testing the CSP implementation [18]. Though his test setup was not optimized for size,
it is not unlikely that a small amount of internal memory can cause issues. The size of
the internal CPU connected RAM of the MCU is only 64 KB, so the need for external
RAM may prove legitimate. One of the tasks for the OBC will be to relay images from
the camera module to the ground station via the datalink. Though the images most likely
will be partitioned before sending over the internal bus, a big RAM memory in the OBC
would be appreciated, as image resolution can be up to 6 Megapixels [34]. In addition to
this, the currently used operation system for NUTS is FreeRTOS, in which each task is
allocated it’s own heap and stack. The size of each task stack must account for the maxi-
mum needed stack size for that task. This results in big proportions of the memory being
segmented into rarely used parts that are still made unavailable to the rest of the system.
The use of external RAM is thus deemed legitimate and will be explored.

All current wildly used memory technologies (e.g. SRAM, SDRAM) are prone to radiation
effects [35]. As a straight forward solution, some OBCs were built to utilize only (non-
volatile) Magnetoresistive random-access memory (MRAM) as system memory which is
inherently immune to SEUs and therefore allows OBC engineers to bypass additional in-
tegrity assurance guarantees for RAM [32].

MRAM is a high-speed low-voltage high-density, nonvolatile memory with unlimited

read/write endurance. It is unique as a memory technology in that the information storage
mechanism is magnetic polarization as compared to electric charge used in DRAM and
flash [36]. The elements are formed from two ferromagnetic plates, each of which can
hold a magnetization, separated by a thin insulating layer. One of the two plates is a per-
manent magnet set to a particular polarity; the other plate’s magnetization can be changed
to match that of an external field to store memory. The major downside with MRAM is,
as could be seen in table 4.3 presented in the last section, that MRAM does not scale well

30
and is currently not available in sizes larger than 16 Mbit.

Ferroelectric RAM (FRAM) which is a random-access memory similar in construction to

DRAM but uses a ferroelectric layer instead of a dielectric layer to achieve non-volatility,
might be an option for volatile RAM, but due to it’s size limitation (FRAM is commercially
currently only available in sizes up to 4 Mbit (512 KB)) and it’s limited endurance (1010 ), it
is considered less than optimal for the use as non-volatile RAM. However MRAM seems
to offer resistance to radiation, is available in 16 Mbit-sizes, and has an unlimited en-
durance. It therefor might be a viable alternative as volatile memory to the microcontroller.

From the table presented in the last section, one could see that MRAM is inherently both
SEU and SEL immune. However, this might be misleading, though the memory elements
are immune, the necessary CMOS control circuitry surrounding the memory are indeed
susceptible to radiation effects[37].

Heidecker, Allen and Sheldon characterized a 1 Mbit MJT MRAM for total ionizing dose
(TID) and single event latchup (SEL). Their results indicate that these devices show no
single event latchup up to an effective LET of 84 MeV-cm2/mg and no bit failures to a
TID of 75 krad (Si)[38].

Figure 4.4: Magnetoresistive RAM from Everspin [3]

While Nguyen and Irom concluded that the Freescale MR2A16A was sensitive to SEEs,
and that SEL could be observed as low as 7 MeV-cm2/mg. The devices could however
withstand effects of TID up to 60 krad(Si) with only a few read errors [39]. Similar find-
ings was made by Elghefari and McClure, who concludes that the MR2A16A is very
sensitive to SEL with LET latchup threshold at room temperate of 10 MeV-cm2/mg [40].
Both these tests however tested the system as a whole and did not differ errors in CMOS
control logic from errors in memory blocks. The author has unfortunately not been able
to find any tests of the SRAM family used for the OBC. However both RAMs have been
used in other satellites. EstCube-1 uses the exact same SRAM as the one used for NUTS,
while the SpriteSat used the MR2A16A MRAM from Everspin (earlier Freescale).

31
 Parameter SRAM MRAM
Size 16 Mbit 16 Mbit
Bit configuration 1024K words x 16 1024K words x 16
Interface Parallel 16-bit Parallel 16-bit
Temperature range Industrial (-40 to 85) Industrial (-40 to 85)
Power Consumption standby 30 mA 9 mA
Power Consumption operation 85 mA 106 mA
R/W Endurance unlimited unlimited
R/W Speed 8ns (125 MHz) @ 3.3v 35ns (28 MHz) @ 3.3v

Table 4.5: SRAM, MRAM comparison

There is an issue with MRAM known as write soft error (WSE). WSE is a type of disturb
error, meaning the errors arise in cells neighboring the targeted cell, not the targeted cell
itself. The rate at which WSE is significant, and is the reason why MRAM chips have ECC
built in. The current generation of toggle-based MRAMs are less susceptible to write dis-
turb phenomena thanks to ”Savtchenko switching”[41]. However the soft error rate is still
not low enough to warrant removing the ECC [42]. Despite this, NASA encourages the
evaluation of MRAM for space missions by stating: ”Missions in the planning or design
phase may want to seriously consider using MRAM”[33]. The fact that the MRAM has
low-voltage inhibit circuitry to prevent writes with voltage out of specification [43] is also
considered to be a plus, as this may give some shielding against radiation induced currants.

The characteristics of the currently used SRAM and the potential replacement MRAM can
be seen in the table below (FRAM is not being considered due to it’s limited endurance
and size).
For comparison, the internal flash has a access time of 30 ns (33 Mhz). So changing to
MRAM would require one wait state when running faster than 28 MHz, this is much like
the speed of running from the internal flash.
Numbers are based on the the respective datasheets for the SRAM [44] and the MRAM
[43]. One can from this table see that the devices are comparable, and while MRAM has
a higher power consumption when in use, it has a much lower power consumption when
in standby. A simple rough estimate for the total power consumption can be obtained by
using the formula below:

consumptionavg = timeon ∗ consumptionon + timeof f ∗ consumptionof f

By the use of this formula one discovers that the MRAM uses the least power for duty
cycles smaller than 50%, while SRAM has the lowest power consumption when the de-
vice is on for more than half of the time. One must however note that since the SRAM
read and write speed is almost 5x faster than the MRAMs, it is likely that a microcontroller
using SRAM will finish faster than the MRAM and thus have a shorter duty cycle resulting
in more time kept in the low power mode for the same amount of workload. However as
the expected duty cycle of the OBC is much smaller than 50%, the MRAM will deliver
the more energy conserved performance.

32
4.3.3 Common Cause Failures and Risk Reduction
Consider a system of two components, A and B. One way of formulating dependency
stems from the idea that the components are susceptible to some common stress that causes
simultaneous failures. The event in which common stress occurs and both A and B fails,
is often referred to as a Common-Cause Failures (CCF) [45]. The more similar A and B
are, the higher will the dependency be, and thus also the likelihood that some common
stress may cause them both to fail. When using redundancy it is therefore important that
the chances of CCFs occurring is small, and thus advantageous if different components
are used in the different modules. This way, if one of the components has a weakness, it
will most likely not be in the other one, and operation can continue with the functional
component. With this in mind, the author thus suggests that the traditional SRAM is kept
in one OBC, while the MRAM is used in the other.

4.3.4 Conclusion
The memories included in the current design are sufficient to satisfy the requirements of
the OBC, however they may not be optimal. After discussing the strengths and flaws of dif-
ferent memories the author suggests that one of the SRAMs is to be replaced by MRAM,
more specifically with the 16Mbit 16-bit I/O Parallel Interface MRAM MR4A18B from
Everspin. The main arguments for this is the added protection against radiation, the low-
ered power consumption when not in use, as well as the added possibility of using parts
of the chip as non-volatile data storage. The cost of this switch is the implementation time
for the new connection routing, and the fact that wait states may have to be implemented
at high frequencies. These costs are however considered to be outweighed by the added
reliability offered by the MRAM-cells. To minimize risk the author also proposes different
memory setups for the two sister OBCs, where as one uses SD-card for logging, while the
other uses regular Flash. Likewise while one uses the conventional SRAM the other will
instead utilize the newer MRAM technology. This way redundancy is achieved also in
hardware and system failures due to common component faults are minimized.

33
Chapter 5
Software Architecture

In this chapter, the initial plans for a software architecture are presented.

5.1 The Software Frameworks

The proposed satellite architecture uses the Cubesat Space Protocol (CSP) together with
the added transport layer of NUTS Reliable Protocol (NRP) for reliable communication
both internally in the satellite, as well as over the communication link to the ground station.
The protocol supports up to 16 modules, whereas each module can have up to 64 ports.
The protocols supports next-hop routing as well as loopback mode. This facilitates a
seamless distributed system, where submodules can communicate with other submodules
in a unified manner, no matter if the other submodules are implemented inside the same
microcontroller or at the groundstation. The CSP+NRP layer abstracts the underlying
interfaces and routing, and thus eases system design, as subsystem developers only need
to define a service-contract, and the set of port-numbers her/his system will be responding
to. The downside is of course the added overhead, memory usage, and process time. If
two submodules implemented in the same host module needs to communicate it is often
not necessary to add CRC checksums and multiple queues for this to happen. However,
as NRP+CSP greatly eases system design and is a verified protocol, it is by the author
considered to be the safer alternative, compared that of shared memory, or of multiple
different self-implemented queuing interfaces. There are no hard deadline requirements
for the OBC, as E-fuses are used to rapidly cut off module power in case of any single
event latch-up (SEL), so the added response time is acceptable. Concerning the memory
usage, the microcontroller is interfaced with 16Mbit external RAM which is be much more
than the estimated requirement for the application.

34
 Figure 5.1: The software architecture of the OBC

5.2 The Software Architecture

The software architecture proposed in this project is made up of four modules, each imple-
mented as it’s own thread. The four modules are the Logger, the Timekeeper, the House-
keeper and the Event handler. They communicate though a set number of sockets and
each adhere to their own service contracts. Though much of their internals have been de-
signed, it is considered to be out of the scope of this report and will instead be included
in a later thesis. However the service contracts supported by the OBC tasks are included
in Appendix A. They have been included at this early stage to publicly make available to
other NUTS satellite application developers what service contracts the OBC will adhere to
and how the services can be requested. Hopefully this will facilitate easy integration when
the systems are more mature. All socket calls are assumed to adhere to the CubeSat Space
Protocol and the NUTS Reliable Protocol that was implemented by Jahren [18].

35
Chapter 6
Reflections

In this report the major NUTS OBC requirements have been explored and a functional as
well as a non-funtional requirement specification has been presented. The microcontroller
for the NUTS OBC has been evaluated and it’s external memories has been reviewed and
discussed. The SAM E70 was found to be a capable replacement for the currently used
OBC, though the reduced time to completion of continuing with a UC3-family controller
resulted in the author recommending future development to incorporate the UC3C0512C
microcontroller as the OBC. After discussing the alternative RAM solutions the current
memory setup was deemed sufficient, though the author recommends that the SRAM in
one OBC is replaced by MRAM.

The report has then suggested a software design that aims to satisfy the functional re-
quirements with the evaluated hardware. The blue print for the service contracts the OBC
will conform to have been included and can be seen in Appendix A.

Discussions have been made under each chapter, where relevant data has been presented
and compared. The OBC is entrusted with many tasks and is dependent on many factors.
This makes for a complex system that is not easily comprehensible and the author there-
for believed it to be necessary to structure the rapport so that individual discussions are
made for each problem, rather than one huge discussion section at the end of the report.
The focus of this report has been rather wide. This has been on demand from the NUTS
administration due to dependencies to other modules that are currently being worked on.
The most time has been spent on information gathering, planning and coordinating with
other NUTS system developers, as well as with management.

Lessons learnt:
• The importance of detailed specifications and interfaces
• Dependencies complicates system design, and circular dependencies can be espe-
cially challenging.
• Number of code lines written or hardware produced are easily conceived steps of

36
 progress, sometimes stressing the importance of taking a step back to establish spec-
ifications may not be perceived as progress from outsiders or the boss’s boss. Stress-
ing their importance is still crucial.
• Revision history can be challenging, especially for documentation.

6.1 Further Work

The design of the software should be continued and implemented. The hardware routing
needs to be redone in order to incorporate a microcontroller switch and to route the CAN
bus interface to the backplane socket. A hardware prototype should then be produced,
so that future software development can use the correct hardware setup when developing
and testing. The work presented in this report will be used as a preliminary study as
the author continues the work in his master thesis. Care must be taken to continuously
update and further specify the OBC specifications as the design process evolves through
the iterations.

37
Bibliography

[1] Daniel Siewiorek and Robert Swarz. Reliable Computer Systems: Design and Eval-
uatuion. Digital Press, 1992.
[2] Delfi Space Command and Data Handling delfi space. http://www.delfispace.nl/delfi-
n3xt/command-and-data-handling. Accessed: 2015-28-10.

[3] Could mram ultimately replace dram? http://www.pcworld.com/article/248364/

could mram ultimately replace dram.html. Accessed: 2015-28-10.
[4] The Norwegian Student Satellite Program ansat. http://andoyaspace.no/?page id=
254. Accessed: 2015-28-10.
[5] Nasjonalt studentsatellittprogram narom. https://www.narom.no/artikkel.php?aid=
2&bid=56&oid=813. Accessed: 2015-28-10.
[6] Space SkyRocket gunters space page. http://space.skyrocket.de/doc sdat/hincube.
htm. Accessed: 2015-28-10.
[7] HiNCubesat is it up there? http://hincube.cubesat.no/wp. Accessed: 2015-28-10.

[8] Wiley J Larson and James Richard Wertz. Space mission analysis and design. Tech-
nical report, Microcosm, Inc., Torrance, CA (US), 1992.
[9] B. Randell, P. Lee, and P. C. Treleaven. Reliability issues in computing system
design. ACM Comput. Surv., 10(2):123–165, June 1978.

[10] Wellings Andy Burns, Alan. Real-Time Systems and Programming Languages. Pear-
son Education Limited, 2009, 4. edition, 2009.
[11] Mayeul Marcadella. Improvement in the reliability of a bi-processing unit satellite
subject to radiation-induced bit-flips. 2014.
[12] Magnus Haglund Arnesen and Christian Elias Kiær. Mission event planning & error-
recovery for cubesat applications. 2014.

38
[13] Thursdays Mondays. International commission on radiation units and measurements.
Br. J. Radiol, 40:720, 1967.
[14] Radiation Effects and Analysis nasa. http://radhome.gsfc.nasa.gov/top.htm. Ac-
cessed: 2015-26-11.
[15] Space Radiation Effects on Electronic Components in Low-Earth Orbit nasa. http:
//llis.nasa.gov/lesson/824. Accessed: 2015-23-11.
[16] Radiation effects on space electronics uio. http://www.uio.no/studier/emner/
matnat/fys/FYS4220/h11/undervisningsmateriale/forelesninger- vhdl/Radiation%
20effects%20on%20space%20electronics.pdf. Accessed: 2015-24-11.
[17] Cosmic Rays cosmic rays. http://www.srl.caltech.edu/personnel/dick/cos encyc.
html, 1996. Accessed: 2015-16-12.
[18] Erlend Riis Jahren. Design and implementation of a reliable transport layer protocol
for nuts. 2015.
[19] Kjell Arne Odegaard. Error detection and correction for low-cost nano satellites.
2013.
[20] Steven McConnell. Code Complete. Microsoft Press, 2004, 2. edition, 2004.
[21] Tor Onshus. Instrumenteringssystemer. 2011.
[22] Dan Erik Holmstrøm. Software and software architecture for a student satellite.
Norwegian University of Science and Technology, 2012.
[23] Ralph Rowland Young. The requirements engineering handbook. Artech House,
2004.
[24] Jonathan Hong and Martin Vetterli. Simple algorithms for bch decoding. Communi-
cations, IEEE Transactions on, 43(8):2324–2333, 1995.
[25] Atmel. Atmel-11296-sam-e70. http://www.atmel.com/Images/Atmel-11296-32-bit-
Cortex- M7- Microcontroller- SAM- E70Q- SAM- E70N- SAM- E70J Datasheet.pdf,
2015. original document from Atmel Corp.
[26] Marius Lind Volstad. Internal data bus of a small student satellite. 2011.
[27] Wayne Wolf. Computers as Components. MK publications, 2012, 3. edition, 2012.
[28] Cubesat database cubesat database. https://sites.google.com/a/slu.edu/swartwout/
home/cubesat-database. Accessed: 2015-23-11.
[29] Texas Instruments. Msp430fr573x mixed-signal microcontrollers. http://www.ti.
com/lit/ds/symlink/msp430fr5730.pdf, 2012. original document from Texas Instru-
ments.
[30] Atmel Corp. Atmel-42385-sam-l21. http://www.atmel.com/Images/Atmel-42385-
SAM-L21 Datasheet.pdf, 2015. original document from Atmel Corp.

39
[31] Atmel Corp. Atmel-11157-sam4e. http://www.atmel.com/Images/Atmel-11157-32-
bit-Cortex-M4-Microcontroller-SAM4E16-SAM4E8 Datasheet.pdf, 2013. original
document from Atmel Corp.
[32] Christian Fuchs. Enabling dependable data storage for miniaturized satellites. 2015.
[33] Jason Heidecker. Mram technology status. 2013.
[34] Thomas Hanssen Nornes. Prototype design for cubesat camera. Specialization
Project, Norwegian University of Science and Technology, 2014.
[35] Leif Z Scheick, Steven M Guertin, and Gary M Swift. Analysis of radiation effects
on individual dram cells. Nuclear Science, IEEE Transactions on, 47(6):2534–2538,
2000.
[36] Mark Durlam, Peter J Naji, Asim Omair, Mark DeHerrera, John Calder, Jon M
Slaughter, Brad N Engel, Nicholas D Rizzo, Greg Grynkewich, Brian Butcher, et al.
A 1-mbit mram based on 1t1mtj bit cell integrated with copper interconnects. Solid-
State Circuits, IEEE Journal of, 38(5):769–773, 2003.
[37] Harold Hughes, Konrad Bussmann, Patrick J McMarr, Shu-Fan Cheng, Robert Shull,
Andrew P Chen, Simon Schäfer, Tim Mewes, Adrian Ong, Eugene Chen, et al. Ra-
diation studies of spin-transfer torque materials and devices. Nuclear Science, IEEE
Transactions on, 59(6):3027–3033, 2012.
[38] Jason Heidecker, Gregory Allen, and Douglas Sheldon. Single event latchup (sel)
and total ionizing dose (tid) of a 1 mbit magnetoresistive random access memory
(mram). In 2010 IEEE Radiation Effects Data Workshop, 2010.
[39] DN Nguyen and Farokh Irom. Radiation effects on mram. Radiation and Its Effects
on Components and Systems, pages 1–4, 2007.
[40] Mohamed Elghefari and Steve McClure. Radiation effects assessment of mram de-
vices. 2008.
[41] G Grynkewich, J Åkerman, P Brown, B Butcher, RW Dave, M DeHerrera,
M Durlam, BN Engel, J Janesky, S Pietambaram, et al. Nonvolatile magnetore-
sistive random-access memory based on magnetic tunnel junctions. MRS bulletin,
29(11):818–821, 2004.
[42] John K DeBrosse, Heinz Hoenigschmid, Rainer Leuschner, and Gerhard Mueller.
Error detection and correction method and apparatus in a magnetoresistive random
access memory, March 9 2004. US Patent 6,704,230.
[43] Everspin Technologies. Mr4a16b datasheet. https://www.everspin.com/supportdocs/
MR4A16BCYS35?npath=262, 2015. original document from Everspin Technolo-
gies.
[44] Integrated Silicon Solution Inc. Is61wv102416a datasheet. http://www.issi.com/
WW/pdf/61WV102416ALL.pdf, 2015. original document from Integrated Silicon
Solution Inc.

40
[45] Marvin Rausand. Common-cause failures. Risk Assessment, pages 469–495.

41
 Appendix A:
OBC Service Contracts

Interface of the Timekeeper

The Timekeeper is to be implemented with one blocking listening socket TIMEKEEPER SOCKET RX
that shall receive and react to calls concerning time and alarms. The calls it shall respond
to can be seen in the table below.
Call Parameters Reaction
PING RSVP SOCKET Send PONG to RSVP SOCKET
PONG NONE Register response
TIME GET RSVP SOCKET Send current time to the
RSVP SOCKET
TIME SET time t time Update the current time to the one
received
ALARM SET time t time, action t Add alarm to execute ”action” at
action ”time”
ALARM DEL ALL NONE Delete all alarms

Interface for the Housekeeper

The housekeeper module is responsible for managing the health of the satellite. It is to
be implemented with one blocking listening socket HOUSEKEEPER SOCKET RX that
shall receive and react to calls concerning satellite health and telemetry. The calls it shall
respond to can be seen in the table below.
Call Parameters Reaction
PING RSVP SOCKET Send PONG to RSVP SOCKET
PONG NONE Register response
RUN HEALTH TEST NONE Run a full satellite test
ERROR REPORT error t error Do necessary actions, such as log-
ging the error and saving the state,
before resetting the module
SYNC TIME time t time Synchronize all RTCs in the satel-
lite with the time given, if no time
is given synchronize using the time-
keeper time.
GET SAT STATE RSVP SOCKET Retrieve the current satellite state
and send it to RSVP SOCKET.

42
Interface for the Logger
The logger is the software service responsible for maintaining the log. It is implemented
as a single thread with one listening socket, LOGGER SOCKET RX. The logger will be
the only task that has direct access to the hardware keeping the log (i.e. flash memory) and
will act as a server, responding to logging requests of the rest of the system. The calls it
shall respond to can be seen in the table below.
Call Parameters Reaction
PING RSVP SOCKET Send PONG to RSVP SOCKET
PONG NONE Register response
LOG ADD log t log, time t time Write the log entry into the log.
LOG GET RSVP SOCKET, int Send the N last log entries to
N RSVP SOCKET.
LOG DEL N LAST NONE Delete the N last log entries.
LOG INIT NONE Initialize the LOG, any old log en-
tries will be deleted.

Interface for the Event handler

The main responsibilities of the event handler is to execute composed commands, en-
abling simple commands from the base station to result in multiple commands to be is-
sued inside the satellite. It is implemented as a single thread with one listening socket,
EVENT SOCKET RX. The Event handler will in general respond to events or commands
that entails complex or composite actions to be executed. The list is to be made.

43