Download MASTER`S THESIS

MASTER'S THESIS
Design and Qualification of On-Board
Computer for Aalto-1 CubeSat
Elyas Razzaghi
Master of Science (120 credits)
Space Engineering - Space Master
Luleå University of Technology
Department of Computer Science, Electrical and Space Engineering
Elyas Razzaghi
Design and Qualification of On-Board Computer
for Aalto-1 CubeSat
School of Electrical Engineering
Department of Automation and Systems Technology
Thesis submitted in partial fulfillment of the requirements for the degree of
Master of Science in Technology
Espoo, August 25, 2012
Instructor:
LAN Shengchang
Aalto University
School of Electrical Engineering
Supervisors:
Professor Emeritus Aarne Halme
Professor Thomas Gustafsson
Aalto University
School of Electrical Engineering
Luleå University of Technology
Acknowledgment
The author would like to thank and acknowledge the following for their contribution towards this project: Jaan Praks, LAN Shengchang, Osama Khurshid
Mirza, Adrian Yanes, Jussi Hemmo, Maria Komu, Antti Kestilä, Matti Vaaja,
and Tomi Ylikorpi.
Also, I would like to thank my wife and my family for their support and patience throughout writing this thesis.
Espoo, August 25, 2012
Elyas Razzaghi
ii
Aalto University
School of Electrical Engineering
Author:
Abstract of the Master’s Thesis
Elyas Razzaghi
Date:
Design and Qualification of On-Board Computer for Aalto-1
CubeSat
August 25, 2012
Number of pages: 66
Faculty:
School of Electrical Engineering
Department:
Automation and Systems Technology
Programme:
Master’s Degree Programme in Space Science and Technology
Professorship:
Automation Technology (AS-84)
Supervisors:
Professor Emeritus Aarne Halme (Aalto)
Title of the thesis:
Professor Thomas Gustafsson (LTU)
Instructor:
LAN Shengchang
In this thesis an electrical model of On-Board Computer (OBC) using commercial-offthe-shelf (COTS) components for the first Finnish small satellite, Aalto-1, is designed
and built for testing the on-board hardware and software. Both the theoretical and
practical aspects of designing a reliable OBC are investigated in this work. The
Aalto-1 OBC is designed to provide a platform for Command and Data Handling
System (CDHS) that interfaces with other subsystems of the satellite and controls
their operations. The Aalto-1 OBC is based on ATMEL ARM9 processors and runs
a commercial operation system that is able to boot from several devices.
When designing equipment to spacecraft, several aspects should be accounted for, and
the design must be highly reliable. The methods for increasing the reliability of OBC
are introduced, and the applicable methods are implemented in the OBC design. The
components are selected and the electrical model of OBC is built. The functionality of
the model is tested in thermal cycling chamber to qualify the design and the selected
components to be used in the engineering model of OBC.
Keywords: Aalto-1, CubeSat, OBC
iii
Contents
1 Introduction
1
1.1
Aims and Objectives . . . . . . . . . . . . . . . . . . . . . . . .
1
1.2
Aalto-1 Mission . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.3
Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
2 Development of Small Satellites
4
2.1
Overview of Small Satellites . . . . . . . . . . . . . . . . . . . .
4
2.2
Challenges in Small Satellites Design . . . . . . . . . . . . . . .
6
2.3
Overwiew of CubeSats . . . . . . . . . . . . . . . . . . . . . . .
7
3 OBC of Small Satellite
10
3.1
OBC Properties . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
3.2
OBC Architecture . . . . . . . . . . . . . . . . . . . . . . . . . .
13
3.2.1
Centralised Architecture . . . . . . . . . . . . . . . . . .
13
3.2.2
Distributed Architecture . . . . . . . . . . . . . . . . . .
13
3.2.3
Bus Architecture . . . . . . . . . . . . . . . . . . . . . .
15
OBC in Space Environment . . . . . . . . . . . . . . . . . . . .
16
3.3.1
Launch Phase Vibration . . . . . . . . . . . . . . . . . .
16
3.3.2
Thermal Conditions
. . . . . . . . . . . . . . . . . . . .
16
3.3.3
Radiation in LEO . . . . . . . . . . . . . . . . . . . . . .
18
OBC Qualification . . . . . . . . . . . . . . . . . . . . . . . . .
21
3.4.1
21
3.3
3.4
Random Vibration Test . . . . . . . . . . . . . . . . . .
iv
3.4.2
3.5
3.6
Thermal Vacuum Bakeout . . . . . . . . . . . . . . . . .
22
OBC Reliability Improvement Strategies . . . . . . . . . . . . .
22
3.5.1
Cold Redundancy . . . . . . . . . . . . . . . . . . . . . .
24
3.5.2
Hot Redundancy . . . . . . . . . . . . . . . . . . . . . .
24
3.5.3
TMR . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
3.5.4
EDAC circuitry and Memory Scrubbing . . . . . . . . .
25
OBC Processors . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
4 Aalto-1 satellite OBC
29
4.1
Aalto-1 System Description . . . . . . . . . . . . . . . . . . . .
29
4.2
OBC Requirements . . . . . . . . . . . . . . . . . . . . . . . . .
32
4.2.1
Mission Requirements . . . . . . . . . . . . . . . . . . .
32
4.2.2
System Requirements . . . . . . . . . . . . . . . . . . . .
33
4.2.3
Mission Constraints . . . . . . . . . . . . . . . . . . . . .
34
4.2.4
Software Requirements . . . . . . . . . . . . . . . . . . .
35
Top level design decisions . . . . . . . . . . . . . . . . . . . . .
35
4.3.1
Technical justification for Linux as On-Board OS . . . .
36
4.3.2
Technical justification for using ARM processors . . . . .
37
4.4
Related Works . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
4.5
Processor Selection . . . . . . . . . . . . . . . . . . . . . . . . .
38
4.6
System Configuration . . . . . . . . . . . . . . . . . . . . . . . .
41
4.6.1
OBC Architecture
. . . . . . . . . . . . . . . . . . . . .
41
4.6.2
Redundancy Strategy . . . . . . . . . . . . . . . . . . . .
42
4.6.3
Software Configuration . . . . . . . . . . . . . . . . . . .
42
Component screening and selection . . . . . . . . . . . . . . . .
44
4.7.1
Volatile Memory . . . . . . . . . . . . . . . . . . . . . .
45
4.7.2
Non-Volatile Memories . . . . . . . . . . . . . . . . . . .
46
4.7.3
LVDS . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
4.7.4
I/O Capability . . . . . . . . . . . . . . . . . . . . . . .
48
4.3
4.7
v
4.8
Power Management . . . . . . . . . . . . . . . . . . . . . . . . .
51
4.9
Supervisory Circuit . . . . . . . . . . . . . . . . . . . . . . . . .
51
4.10 Layout Design . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
4.11 Booting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
4.12 OBC Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . .
55
4.12.1 Test Software . . . . . . . . . . . . . . . . . . . . . . . .
55
4.12.2 Test Procedures . . . . . . . . . . . . . . . . . . . . . . .
56
4.12.3 Test Results . . . . . . . . . . . . . . . . . . . . . . . . .
57
5 Summary and Conclusions
5.1
59
Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
References
60
61
vi
List of Tables
4.1
4.2
OBC Specifications of CubeSat Missions with Commercial Operating Systems . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
Aalto-1 OBC Processor Candidates . . . . . . . . . . . . . . . .
40
vii
List of Figures
2.1
Satellite Mass and Cost Classification, Adopted from (Barnhart,
2008) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
3.1
Centralized Architecture . . . . . . . . . . . . . . . . . . . . . .
14
3.2
Ring Architecture . . . . . . . . . . . . . . . . . . . . . . . . . .
14
3.3
Bus Architecture . . . . . . . . . . . . . . . . . . . . . . . . . .
15
3.4
DNEPR High and Low Level Qualification Profile, Adopted from (Toorian et al., 2004) . . . . . . . . . . . . . . . . . . . . . . . . . .
22
3.5
Bakeout Profile, Adopted from (Toorian et al., 2004) . . . . . .
23
3.6
Mitigation Scheme Matrix, Adopted from (Xilinx, 2008) . . . .
25
4.1
Aalto-1 Satellite Subsystems . . . . . . . . . . . . . . . . . . . .
31
4.2
Aalto-1 System Block Diagram . . . . . . . . . . . . . . . . . .
31
4.3
Aalto-1 OBC Block Diagram . . . . . . . . . . . . . . . . . . . .
43
4.4
Aalto-1 Redundant OBC Block Diagram . . . . . . . . . . . . .
43
4.5
Physical Layer of I2 C Bus . . . . . . . . . . . . . . . . . . . . .
49
4.6
Electrical Model of Aalto-1 OBC . . . . . . . . . . . . . . . . .
53
4.7
Internal First-Stage Bootloader Flow Diagram . . . . . . . . . .
54
4.8
Weiss Thermal Cycling Profile . . . . . . . . . . . . . . . . . . .
57
4.9
HMT337 Temperature Transmitter Thermal Cycling Profile . .
58
viii
Abbreviations
ADCS Attitude Determination and Control System
BGA Ball Grid Array
CDHS Command and Data Handling System
CDH Command and Data Handling
COM Communication Subsystem
COTS commercial-off-the-shelf
DSP Digital Signal Processor
EDAC Error Detection And Correction
EEPROM Electrically Erasable Programmable Read-Only Memory
EPB Electrostatic Plasma Brake
EPS Electrical Power System
FPGA Field-Programmable Gate Array
GPS Global Positioning System
I2 C Inter-Integrated Circuit
IR Infrared
LEO Low Earth Orbit
LVDS Low-Voltage Differential Signaling
MMU Memory Management Unit
OBC On-Board Computer
ix
OBSW On-Board Software
PCB Printed Circuit Board
P-POD Poly Picosatellite Orbital Deployer
PQFP Plastic Quad Flat Pack
RADMON Radiation Monitor
RTC Real-Time Clock
SAA South Atlantic Anomaly
SCL Serial Clock
SCV Spacecraft Configuration Vector
SDA Serial Data
SDRAM Synchronous Dynamic Random-Access Memory
SEE Single-Event Effects
SEL Single-Event Latch-up
SEU Single-Event Upsets
SoC System on Chip
SPE Spectral Imager
SPI Serial Peripheral Interface
SRAM Static Random-Access Memory
TID Total Ionizing Dose
TMR Triple Modular Redundancy
UART Universal Asynchronous Receiver/Transmitter
x
Chapter 1
Introduction
In order to achieve more reliability and functionality in space, the size of satellites has been increased over time. However, the increase in size of satellites
results in a long development time and a high development cost and especially
very high launch costs. On the other hand, rapidly developing technology and
tight budgets have created the need for shorter and cheaper developments of
space missions. The need for low cost and fast developing satellites has led
to the formation of a new generation of small satellites. The small satellites
provide cheaper alternatives to bigger satellites by reducing the requirements
significantly and taking the advantages of commercial technologies. The competitive market in microelectronics industry continues to decrease the cost, size,
and power consumption of state-of-the-art COTS components, while conversely,
increases the performance of these components.
1.1
Aims and Objectives
The aims of this thesis are to design and qualify the main OBC to meet the
system and mission requirements of Aalto-1. Designing hardware for space application requires considerations that would not normally be considered while
designing hardware for other applications. This is due to the extreme environmental conditions in space such as wide temperature range and high radiation
exposure. The space equipment demands highly robust electronic components
and higher level of redundancy to survive in such environment. The objectives
1.2 Aalto-1 Mission
2
in designing a computer system for space applications are to optimize the availability, capability, flexibility, and reliability of system while optimizing cost and
risk (Wertz and Larson, 1999).
1.2
Aalto-1 Mission
Aalto-1 is a student satellite mission initiated and coordinated by Aalto University, Department of Radio Science and Engineering. The mission is to build,
launch and operate a functional remote sensing satellite, mainly with student
workforce. The satellite mission should promote space technology education,
domestic and international networking in space sciences and latest advances in
space technology (Praks et al., 2011).
The mission concept and main configuration was developed by students during the Aalto-1 preliminary study in 2010. The Aalto-1 mission is built around
three innovative payloads, and the main goal of the mission is to demonstrate the
functionality of these payloads in orbit and measure their performance parameters. All three payloads are built by different institutions in order to facilitate
cooperation inside space R&D segment in Finland (Praks et al., 2011).
The Aalto-1 satellite will be built as a three unit (3U) CubeSat according to
the CubeSat design specifications (CalPoly, 2009). The CubeSat design has
been widely used in many university satellite projects, and currently there are
several CubeSats orbiting the Earth. CubeSat design was chosen for Aalto-1
because the concept has been proven in space, off-the-shelf subsystems can be
procured if necessary, and commercial launches for CubeSats are available. In
addition to this, using CubeSat standard also makes it possible that the new
systems designed for Aalto-1 to be easily available for others in the CubeSat
community (Näsilä et al., 2011a).
1.3
Outline
The thesis is organized as follows:
Chapter 1 defines the aims for the thesis work and it introduces the Aalto-1
1.3 Outline
3
mission.
Chapter 2 explores existing and emerging very small satellite technologies. It
gives an overview of small satellites for carrying out various scientific and technological research activities, and it focuses on a short survey of the challenges in
the development of small satellites. It also presents a short summary of current
CubeSat technology status as an important category of small satellites.
Chapter 3 investigates the theoretical background considerations for designing
an OBC for CubeSat in Low Earth Orbit (LEO). This chapter introduces the
typical of satellite OBC and architecture. It investigates the space environment that Aalto-1 CubeSat will experience during the mission and explains the
effects of space environment on OBC. According to CubeSat standards and mission scenario, the qualification requirements of Aalto-1 are then inferred. This
chapter investigates the methods for increasing the reliability of OBC when using COTS components. Finally, it proposes different options in selecting the
processor for OBC.
Chapter 4 presents the work done for the development of an electrical model
of OBC. It discusses the design and development process in terms of the techniques and the methodologies incorporated for the whole process. This chapter
describes the system specifications of Aalto-1. Based on the OBC system requirements, it proposes the hardware and software schemes. This chapter also
derives the detailed system configuration and components of OBC and their
interfaces. It explains the booting sequence of the on-board software. Then, it
presents the test software and testing procedures for the preliminary thermal
qualification of OBC. Consequently, it explores the potential weaknesses of the
design based on the test results.
Chapter 5 concludes and summarizes the work done in development of OBC.
Eventually, it proposes the considerations for development of an engineering
model of OBC.
Chapter 2
Development of Small Satellites
2.1
Overview of Small Satellites
The mission requirements were increasing from the beginning of space age in
1957 in order to have more capable and more reliable spacecraft in the hostile
space environment. These requirements have increased the mass of spacecraft
from 84 kg Sputnik to over 6,000 kg for some missions today. When, the mass
increases, the cost and complexity and developing time of the mission also increase significantly. Conversely to this trend, the emergence of small satellites,
originated mostly in universities, has provided many low cost and capable space
missions to the space community. The capabilities of small satellites are continuously increasing and the main reason is based on reducing the qualification
requirements significantly and taking the advantages of commercial technologies (Barnhart, 2008). Satellites below 500 kg are known as small satellites and
they are classified usually according to their mass. These classifications can be
seen in Figure 2.1.
The launch cost makes up a big portion of any satellite project, and the small
size of satellite leads to the much lower launch cost. Some Nano-satellites have
been launched as secondary payloads of Dnepr and Eurocket launch vehicles
for around $40K per kilogram (Flagg et al., 2004). Since the end of the cold
war, former Soviet InterContinental Ballistic Missile (ICBM)s have been refurbished by the Russians for use as launch vehicles. These launch vehicles provide
dedicated launches to small satellites as primary payloads. The small size of
2.1 Overview of Small Satellites
5
Figure 2.1: Satellite Mass and Cost Classification, Adopted from (Barnhart,
2008)
the satellite using commercial technology is achievable because of the advances
in microelectronics. The new microelectronic components consume less power
while they are more powerful and more efficient. The short development time
of the small satellites is because they are less complicated and demand simpler
qualification requirements. The low cost introduces new concepts in the space.
A system where two or more satellites function collectively to perform a task
is defined as a distributed satellite system. Because of the low cost a distributed satellite system, with a reasonable price, could be built and launched.
A distributed satellite system like GPS satellites is beneficial since we can have
distributed sensors which provide real-time observations and coverage around
the world. Space sensor networks could provide an unprecedented capability
to investigate widespread phenomena. Distributed sensors will provide more
information about the space as well as the Earth environment. There will be
more samples at an instant of time, so a better simulation and evaluation of the
environment could be performed.
The distributed satellite system also increases the reliability of the overall system. For a single, conventional satellite, if there is a failure in one module then
the entire mission might be lost. Whereas for a collection of smaller satellites,
there would still be other operative satellites that could continue the mission
even if one fails. Higher quantity mitigates the risk of failure and this also
2.2 Challenges in Small Satellites Design
6
brings the higher reliability to the whole system.
There is always a need for real-time coverage of the Earth for weather forecasting, military applications, natural phenomena studies, disaster avoidance
and treatment, civilian applications, navigation, and hobbyists. One interesting vision for small satellites is that, they can be used as service spot for bigger
satellites, e.g., had there been a full coverage system of small satellites around
the earth, the recently lost Envisat (ESA, 2012) could be inspected for maintenance and recovery purposes.
The risky and not fully proven scientific experiments usually do not get the
chance to go to the space with conventional satellites because of high costs and
high level of risks involved. Due the low cost of small satellites, such experiments could be performed. The high cost of conventional satellites puts up the
requirement for higher quality control practices to ensure the satellite will work
for the aimed lifetime. These quality assurance procedures are usually very
costly, time consuming, and need a lot of facilities. In the development of low
cost small satellites there are less stringent qualification and quality assurance
requirements, and a compromise in project management and quality assurance
roles is acceptable.
The development of small satellite technology is often open source. Thus, having an easy access to the space technology, the hobbyists and researchers can
make more contributions to this area. Consequently, small companies and individuals can have the access to the space.
Through the CubeSat standard, many universities have got the chance to develop a real satellite at their own laboratories or workshops. CubeSats can be
developed in, comparatively, short time that is suitable for universities where
the main workforce comprises of students.
2.2
Challenges in Small Satellites Design
The small dimensions of a satellite bring forward a lot of restrictions and challenges. The first limitation is in small solar panels that produce only a couple of
watts of electrical energy. In fact, 15 to 20 years ago, it was almost impossible
to have any reasonable mission with such a small power generation because the
electronic components were not that efficient as today. Thus, they could not be
used for on-board processing in such a small satellite. The advances in mobile
2.3 Overwiew of CubeSats
7
technology made it possible to have very efficient radios and processors that
could operate with a very little power. The area available for antenna is also
a challenge where there is not enough gain available for radio communication.
The frequency range is also restricted for small antennas.
Future on-board processing will allow even greater data collection, but the overall downlink rate is still somewhat limited (Flagg et al., 2004). Communication
is by far the bottle neck for Nano-satellites.
Using COTS components which are much cheaper compared to space qualified components is one approach commonly used in small satellites. The other
benefits of using COTS may include: higher gate densities, increased speed/performance, little or no need for spacial software, easier system development path
using COTS development and test equipment, and decreased lead times in comparison to rad hard (RH) devices. Microelectronic manufacturers are being
driven by a commercial market of which the space community is a very small
portion (LaBel et al., 2011). However, most of COTS components have never
been used in any of the satellite missions; and the systems using these components require going through the qualification procedures to be tested for their
tolerance to destructive effects of radiation. During these procedures, the COTS
components might not pass the tests and they must be discarded and the whole
subsystem might need to be redesigned. The COTS components are not radiation hardened, and they are usually available only in plastic packages which are
vulnerable to outgassing. The lack of radiation protection and high outgassing
rate limit the lifetime of small satellites using COTS components.
The orbit selection is another challenge for small satellites at the moment. Currently, the very small satellites are launched together with the conventional
satellites on piggyback launches. Since, the conventional satellite holds the major share of the launch cost, it determines the orbit. So, the very small satellite
mission designers are not free in orbit selection.
2.3
Overwiew of CubeSats
Two major categories of very small satellites are the Nano-satellites with the
mass between 1kg to 10kg, and Pico-satellites in the range of 0.1kg to 1kg.
CubeSat is a popular open standard in Nano and Pico-satellites. The CubeSat
2.3 Overwiew of CubeSats
8
standard defines the dimensions of satellites. It also defines some test procedures and interfaces with launchers. The size of one unit (1U) CubeSat is 10cm
x 10cm x 10cm, and the weight is about 1kg. CubeSat standard was developed
mainly for simplification of satellite infrastructure in order to reduce build and
launch costs for space science so more universities and organizations worldwide
could participate in space exploration. There is already a big CubeSat community that provides conferences, workshops, and launcher arrangements for
CubeSat developers. The subsystems of CubeSats could be designed as modules, and the modules are integrated in a stacked architecture. Standard launch
adapter like Poly Picosatellite Orbital Deployer (P-POD) greatly simplifies getting launch opportunities as opposed to a traditional satellite that has to be
designed from the ground up to fit to the launch vehicle.
Throughout years of designing for various missions, developers have realized
that maximizing potential payload volume is crucial as missions become more
complex (Fitzsimmons, 2012). There are some core hardware platform or the
avionics systems like Pumpkin’s “CubeSat Kit” or Tyvak’s “Intrepid” provided
by different suppliers to support various missions. This allows developers to
reuse previously designed systems, and focus more on innovative payloads development. CubeSat mission goals are: Technology Demonstration (56%), Communication (32%). Within a decade more than 50 missions were flown. Currently 250 missions (at least) are in operation/planning (Bridges, 2012). After
February 2012, 6 CubeSats were launched to space, by then 74 CubeSats project
had been designed, and 55 had been launched, and 36 are still orbiting, 19 naturally deorbited, 14 not operative, and in next 10 years at least 100 CubeSats
will be launched.
Some interesting derivations of CubeSats are:
• PhoneSat is an example of rapid development which uses mobile phone
as a platform for CubeSat, this platform reduces the costs significantly,
this platform already has most of satellite subsystems, it needs low power,
and it has accelerometers, GPS, radios, etc.
• CubeFlow developed by Operationally Responsive Space (ORS) and Air
Force Research Laboratory (AFRL) is a kind of plug and play modular Nano-satellite approach where hardware and software ’Black-box’ elements can be combined very quickly (possibly less than an hour) to form
simple, but functional spacecraft (Kief et al., 2010).
2.3 Overwiew of CubeSats
9
• Tyvak which is a spin-off company is leading in producing very thin modules which fully conform to the CubeSat specification, and solves many of
the design challenges developers face by including the Electrical Power
System (EPS), CDHS, a custom Embedded Linux OS with device drivers
already in place, and post-deployment power-up interfaces. Tyvak provides a module for CubeSats which is only 1cm thick, and does the vital
functions of satellite and the rest of CubeSat volume is left for the developers, and they can put whatever payloads they like to this satellite (Tyvak,
2012).
• KickSat satellites are a swarm of PCBs fitted in a CubeSat which have
radio and communicate with each other and also to a main satellite, and
the main satellite has the link down to the Earth (Manchester, 2011).
Chapter 3
OBC of Small Satellite
The OBC is a computer or a system of computers that processes various information transmitted to the satellite or from other on-board subsystems. The
purpose of main OBC is to provide a platform for CDHS that interfaces with
other subsystems of satellite and controls their operations. The other standard
subsystems of a satellite are EPS, Communication Subsystem (COM), Attitude
Determination and Control System (ADCS) and the payloads.
There are several interactions that can adversely affect the performance of OBC.
Percentage of failure in OBCs are, design 24.8 %, not fully understood environment 21.4 %, operations (bad commands) 4.7 %, Random (parts 16.3 %,
quality 7.7 %, other 6.3%, unknown 18.9 %), based on about 2500 failures between 1962-1988) (Bridges, 2012). In order to reduce the failures, the common
techniques for increasing the reliability of OBC in space environment will be
presented in this chapter.
3.1
OBC Properties
The OBC compared to standard industry embedded controllers or automotive
controllers have to provide the following characteristics (Eickhoff, 2012):
• mechanical robustness to withstand launcher induced loads with respect
to sinusoidal vibration and release shock(Subsection 3.3.1).
3.1 OBC Properties
11
• resistance to extreme thermal change (Subsection 3.3.2).
• radiation robustness against high energetic particles (Subsection 3.3.3).
• significant failure robustness (Section 3.5).
• low power consumption (Section 3.6).
All of the above items are explained in their referred sections.
OBC main elements are processor, boot memory, safeguard memory, work memory, mass memory for science and housekeeping data, data buses and bus controllers, debug and service interface, power supplies, and clock (Eickhoff, 2012).
Processors will be discussed in more detail in section 3.6.
Boot memory is a non-volatile memory which is persistent even after a power
reset. It holds bootloader for On-Board Software (OBSW) and the reference
image of OBSW.
Safeguard Memory holds the OBC configuration and satellite status information when OBC is being power cycled. The bootloader has a memory area
where it can find the latest satellite status and health information. This memory area is called (Spacecraft Configuration Vector (SCV)). SCV has two part
of information (Eickhoff, 2012):
1. Actual satellite configuration with its subsystems: Nominal settings, Safe
mode settings, Health status parameters.
2. Actual satellite status with its subsystems: Powered subsystems, Subsystems telemetry acquisition, Subsystems operational status.
The status part of SCV is continuously updated during operations and the
configuration part is directly affected in case a payload was identified to have
failure.
Work memory (RAM) is used for runtime storage of the executed OBSW which
includes both OS and the control software. The OBSW is copied by the bootloader from boot memory into RAM and then OBC is started up. Also, all configuration parameters are loaded into RAM. Two types of RAM are available:
“Static RAM” (SRAM) and “Dynamic RAM” (DRAM), usually “Synchronous
DRAM” (SDRAM). The difference is that DRAM needs to be periodically refreshed which requires extra circuitry, but it offers higher memory density (Eickhoff, 2012).
3.1 OBC Properties
12
Mass memory is a storage area for housekeeping and payload science data acquired during flight phases without ground contact.
Data buses and bus controllers are for connecting different subsystems to OBC.
Missions are becoming more diverse and complex, thus satellites should be
able to accommodate various payloads. Consequently, the OBC should demonstrate high flexibility in term of available peripherals. There are two connection
types (Eickhoff, 2012):
1. Point-to-point connection; it needs separate pair of wires for each subsystem, and the data rate is usually higher: UART/USART, MIL-STD1553B, SpaceWire, HotLink, GigaLink.
2. Data bus; the OBC hosts a bus controller which connects to the bus lines
shared by other subsystems, and the data rate is usually slower: I2 C,
CAN, SPI.
Debug interface is an interface that allows debugging of OBSW code on the
OBC. Service interface makes it possible to monitor OBSW execution via debugger and in most cases also can be used for fast OBSW upload to RAM while
the OBC is not booted.
Power supplies needed by OBC are usually 1.8, 3.3V, or 5V. EPS sometimes
does not provide these supplies and voltage regulators must be employed to
provide these voltages.
Clock and synchronization concerns the on-board time generation and the coherent synchronization of all OBSW processes and the on-board subsystems which
require timing information or time progress information. Availability of time
information is an essential function for OBSW task control and for time stamping of telemetry packets. The main elements for time producing are (Eickhoff,
2012):
• internal Real-Time Clock (RTC) of the processor.
• the physical quartz based oscillator clock modules.
• a GPS atomic clock time reference which provides more exact time and
better stability concerning clock drifts compared to the quartz based clock
modules.
3.2 OBC Architecture
3.2
13
OBC Architecture
Architecture is a framework for developing a computer system. The architecture
shows the system’s parts and how they interact through a block diagram. Data
architecture addresses the physical structure of the data network or bus, as well
as the protocol or logical interaction across the bus (Wertz and Larson, 1999).
The OBC architecture has to be flexible and general-purpose to increase its
reusability (Yashiro and Fujiwara, 2002). Three different data architectures are
used to connect the board computer with external components or subsystems:
3.2.1
Centralised Architecture
A Centralized Architecture has Point-to-Point interfaces between OBC and
other satellite subsystems. It is also refered as Star Architecture (Wertz and
Larson, 1999) as seen in Figure 3.1.
Advantages:
• Failure of a component or line does not cause system loss.
• Individual interfaces are possible for secure data.
Disadvantages:
• High wiring effort is necessary which may also cause electromagnetic compatibility (EMC) problems.
• Adding a new node requires both hardware and software changes in the
central node.
3.2.2
Distributed Architecture
Often called ring architecture, it establishes a way to arbitrate information flow
control as the data are passed in a circular pattern (Wertz and Larson, 1999).
See Figure 3.2.
Advantages:
3.2 OBC Architecture
Figure 3.1: Centralized Architecture
Figure 3.2: Ring Architecture
14
3.2 OBC Architecture
15
• Low cabling effort is needed and can be distributed throughout the satellite structure.
• Components can be tested independently.
• Adding new nodes will have limited impact on OBC.
Disadvantages:
• It is less reliable, since each node is in-line and thus required to achieve
transmission to the next node (e.g. short circuit can cause loss of system).
• Adress decoder in each node is required.
3.2.3
Bus Architecture
This architecture utilizes a common data bus with all subsystems sharing the
bus. It uses standard protocols and communication schemes for all nodes (Wertz
and Larson, 1999). See Figure 3.3.
Advantages:
• The system realization is simple.
• Data transmissions are deterministic which reduces test and troubleshooting time while increases reliability.
Disadvantages:
Figure 3.3: Bus Architecture
3.3 OBC in Space Environment
16
• All components must be developed with a specific interface - physically
as well as electrically.
• Failure (e.g. short-circuit) of a component or line may cause loss of system.
3.3
OBC in Space Environment
Space is a hazardous environment for electronic equipment and it poses a risk
to all Earth-orbiting satellites. The following subsections will highlight the
major challenges when designing electronic equipment, such as OBC, for space
applications.
3.3.1
Launch Phase Vibration
The launch environment that spans from ground to the altitude of about 80km,
known as Karman Line, is one of the most hostile environments that a satellite
experience during its mission. There are a lot of vibrations in launch phase.
The launch vehicle reaches to an acceleration of about 20g in 90 second in order
to gain the escape velocity needed to break free from the Earth gravitational
field (Tribble, 1995). During this time, the payloads must withstand multi-axial
forces and pressures exerted by launch vehicle. In the presence of air pressure,
these forces are produced from violent behavior of air molecules at high speeds.
Rocket motors are not designed for the comfort and safety of the equipment
they are transporting to space; they are designed to achieve the escape velocity.
The energy required to achieve this velocity is violent, and the satellites must
be built in such a way that they do not crush under the pressure or rattle apart
during the launch. Vibration requirements are dictated by the launch vehicle
and given usually in launch vehicle manual.
3.3.2
Thermal Conditions
There are different thermal contributors i.e. sources of heating and cooling
in the space environment that cause the wide changes in the temperature of
3.3 OBC in Space Environment
17
satellites. The main contributors are direct solar radiation, heat radiation from
earth and heat from internal components of the satellite. These contributors
are briefly described here.
Direct solar radiation
Solar radiation is the main source of heat on LEO. Due to Earth’s elliptic orbit
around the sun, the intensity of sunlight at Earth’s distance varies from the
minimum of 1322 W/m2 to 1414 W/m2 . Earth’s mean distance from the sun is
149,597,870 km, at which the sunlight intensity is 1367 W/m2 (Gilmore, 2002).
Radiation Reflected from Earth
The reflected radiation from earth is defined by Albedo which is the fraction of
sunlight reflected off Earth. Generally clouds, snow and ice increase reflectivity
as does a lower solar-elevation angle, which leads to higher albedo factor when
latitude increases. Usually oceanic regions have lower reflectivity, than continental ones. The local incident solar energy per unit area at Earth’s surface
decreases with cosine law when moving away from the subsolar point, which
leads to decreasing satellite albedo heat flux although albedo fraction increases
with latitude. Albedo is highly variable because of the multiple factors affecting
it (Gilmore, 2002).
Earth Infrared
Earth itself emits Infrared (IR) radiation as a thermal body with average temperature around −18 ◦C (Gilmore, 2002) E.g. local temperature at Earth’s
surface and clouds affect the amount of Earth IR received by the satellite. Generally Earth-emitted IR decreases with latitude. The variability of Earth IR is
smaller than that of albedo loads. Since satellite’s temperature is closer to that
of the Earth than that of the sun, i.e. IR wavelengths are closer, there is no
way of selecting thermal coatings that would effectively reflect Earth-emitted
IR, but still dissipate heat as IR radiation with high emissivity.
3.3 OBC in Space Environment
18
Internal contributors
The main satellite internal heat contributor is waste heat from electrical components. For approximate worst case calculations it is often assumed that 100%
of electrical power used by the satellite subsystems and payloads is converted
to heat.
3.3.3
Radiation in LEO
During the fusion process, the stars emanate a lot of radiations that contain
various forms of charged particles. The Sun dominates the sources of radiation
in space near the Earth. Encircling the Earth, the Van Allen belt radiation that
forms the Earth’s magnetic field can divert most of the radiations from space,
and shields the Earth. The satellites in LEO are also protected by the magnetic
field most of the times, except in South Atlantic Anomaly (SAA) region where
the trapped charged particles in Van Allen belt and the radiation from Van Allen
belts enter the atmosphere. These radiations cause in the electronic equipment,
especially semiconductor devices undesired effects (Botma, 2011).
The main sources of energetic particles that contribute to undesired radiation
effects to electronic components are:
1. protons and electrons trapped in the Van Allen belts,
2. cosmic ray protons and heavy ions,
3. protons and heavy ions from solar flares.
Ionizing radiation has enough energy to remove tightly bound electrons from
their orbits while interacting with an atom, and causes the atom to become
charged or ionized. The effects of space radiation on the microscopic IC world
are not benign. The effects are caused by protons, heavy ions & galactic or solar
cosmic rays (GCR/SCRs) > 10 MeV. The effects of radiation in brief are damage
of crystal structure, bit flips, and latch up (always on). These effects can be
generally classified into two fundamental mechanisms: lattice displacement and
ionizing effects.
When high energy particles collide with electronics, the arrangement of atoms
3.3 OBC in Space Environment
19
changes in the crystal lattice, as a result, lasting damage occurs and the number
of recombination centers increases, the minority carriers deplete and the analog
properties of the affected semiconductor junctions become worse. This type of
problem is particularly significant in bipolar transistors, which are dependent on
minority carriers in their base regions; increased losses caused by recombination
cause loss of the transistor gain (Wikipedia, 2012).
Ionizing radiation effects in space vehicle electronics can be separated into two
areas:
1. Total Ionizing Dose (TID)
2. Single-Event Effects (SEE)
The two effects are distinct, as are the requirements and mitigation techniques.
TID
TID is long-term degradation of electronics due to the cumulative energy deposited in a material. TID effects include functional failures and parametric
failures (variations in device parameters such as leakage current, threshold voltage, etc.). Accumulation of charge on transistors used in semiconductor circuits
affects their current-voltage characteristics. In order to operate correctly, as
the gate voltage passes through a threshold, a transistor must be able to switch
from a low conductance (off) state to a high conductance (on) state. When being exposed to radiation for long time, the threshold voltage is shifted and this
causes an easier or harder switching of the transistors. The leakage current may
also increase and it causes the on and off states of the transistors to become less
distinguishable. Any of these effects can ultimately cause circuit failure. The
dominant sources of TID exposure in the space environment include trapped
electrons, trapped protons, and solar flare protons. Possible countermeasures
are qualification by tests (Cobalt 60), shielding, and redundancy. The TID
tolerance can be seen as a measure for determining the life expectancy of an
electronic device. Some electronic devices have a radiation-hardened version
which has a greater TID tolerance, but they are considerably more expensive.
COTS components usually have a TID tolerance large enough to justify their
use on a satellite with a short mission in LEO.
3.3 OBC in Space Environment
20
SEE
SEEs on the other hand are nearly instantaneous effects. They are induced by
the impact of a single energetic particle at a sensitive point in a device. SEEs
occur when a single ion strikes the material, depositing sufficient energy in the
device to leave an ionized track behind. The many types of SEE may be divided
into two main categories: Soft Errors and Hard Errors.
In general, a soft error occurs when a transient pulse or bitflip in the device
causes an error detectable at the device output. Therefore, soft errors are entirely device specific, and are best categorized by their impact on the device.
The most common soft error is Single-Event Upsets (SEU). SEU is generally
a transient pulse or bitflip. In combinatorial logic or an analog-to-digital converter, a transient or spike on the device output would be a potential SEU; in a
memory cell or latch, a bitflip would be an SEU. SEUs occurring in the device’s
control circuitry may also cause other effects. In general, SEUs are corrected by
resetting the device or rewriting the data. These upsets usually do not damage
a device, but it could cause undesired effects within the operation of a device or
system. Possible countermeasures are Error Detection And Correction (EDAC)
for memory and busses, redundancy of software or data, and reset (LaBel et al.,
2011).
Hard errors may be, but are not necessarily, physically destructive to the device,
and cause permanent functional effects and change to the operation of the device. A common example would be a stuck bit in a memory device. Like SEUs,
this is also device dependent. The most common hard error is Single-Event
Latch-up (SEL). SEL is a potentially destructive condition involving parasitic
circuit elements. During a traditional or destructive SEL, the device current exceeds the maximum specified for the device. Unless power is removed, the device
will eventually be destroyed. Latch up is the most common source of problem in
90nm technology, depending on their power and technology used and materials,
they can cause permanent damages. Particle hit causes a power-to-ground short
within device. This excessive current flow may damage the device, due to the
heat generated locally, if the latchup is not removed by means of power cycling
(switching power on and off to device). A combination of hardware and software
error detection methods serve as effective mitigation. Possible countermeasures
are current limiters, power cycling, and cold redundancy (LaBel et al., 2011).
3.4 OBC Qualification
3.4
21
OBC Qualification
Many factors including launch vehicle vibrations, extreme temperatures, radiation and the vacuum environment contribute to the harsh environment that any
satellite will experience during its mission. Satellite hardware must be designed
and tested to resist each of the above environmental factors so that a satellite
will be able to operate nominally with a little or ideally no faults. Qualification
testing shall be performed to meet all launch provider requirements as well as
any additional testing requirements deemed necessary to ensure the safety of
CubeSats and P-POD. If launch vehicle environment is unknown, GSFC-STD7000 shall be used to derive testing requirements. All flight hardware shall
undergo protoflight and acceptance testing. If a part does not have test results
to prove that it met this requirement, then it needs to have flight history onboard a satellite in a similar low-earth orbit. Finally, if a part could not be
justified using either of the above mentioned methods, then at the very least,
it needed to be in the same “family” as a known radiation tolerance levels.
At the very minimum, all CubeSats shall undergo the following test (CalPoly,
2009):
• Random Vibration
• Thermal Vacuum Bakeout
3.4.1
Random Vibration Test
Vibration test is done to qualify the robustness of satellite systems in launch
phase. The displacement of the components could happen due to weak solders
joint or loose contacts when there are high internal and external forces to the
satellite structure. The vibration test is performed by inserting sine and random forces to the satellite using a shaker machine.
The following vibration testing requirements will ensure that the hardware will
not damage any satellites under the worst-case environmental conditions expected during launch. As an example, the test procedures for DNEPR are the
following: Setup Test Pod so that the X axis is the test axis of the shake table.
Then run the High Level DNEPR qualification test for 35 seconds, then the
3.5 OBC Reliability Improvement Strategies
22
Low Level DNEPR qualification test for 831 seconds, see Figure 3.4. Repeat
the test for Y and Z axis (Toorian et al., 2004).
3.4.2
Thermal Vacuum Bakeout
Thermal vacuum bakeout is a simple procedure that secondary payload like
CubeSat is required to perform in order to remove excess contaminations that
may be harmful to the launch vehicle or primary payload. Thermal vacuum
bakeout shall be performed to ensure proper outgassing of components. A minimum vacuum level of 5 x 10−4 Torr must be attained to observe the outgassing
of components, Figure 3.5 (Toorian et al., 2004).
3.5
OBC Reliability Improvement Strategies
Protection from radiation is mostly not achievable in CubeSat because of its
fundamental limitations in size and budget, but it is possible to mitigate the
radiation effects to some degree. The common countermeasures for radiation
effects are avoiding, shielding, redundancy, error correction, reset, scrubbing
memories (used more in Field-Programmable Gate Array (FPGA)).
The are different strategies to improve the reliability. Fault avoidance strategies
Figure 3.4:
DNEPR High and Low Level Qualification Profile, Adopted
from (Toorian et al., 2004)
3.5 OBC Reliability Improvement Strategies
23
Figure 3.5: Bakeout Profile, Adopted from (Toorian et al., 2004)
are usually used in conventional satellites:
• Using more reliable hardware and proven solutions (heritage).
• Applying radiation hardened solutions (rad-hard).
The fault avoidance strategies are not very common in CubeSat community,
since the CubeSat project nature is to use state-of-the-art COTS components
that have never been to space.
Fault tolerance strategies enables the OBC to continue operation when some
part of OBC fails. These strategies include:
• module redundancy
• mitigation of radiation effects
– Triple Modular Redundancy (TMR)
– EDAC circuitry
– Memory Scrubbing
The module redundancy and mitigation of radiation effects could be implemented both by hardware and software methods. Only the hardware methods
will be explained here.
3.5 OBC Reliability Improvement Strategies
3.5.1
24
Cold Redundancy
Cold redundancy between circuits, boxes, systems, etc. provides a potential
means of recovery from a SEE on a system. Autonomous or ground controlled
switching from a prime system to a redundant spare may provide system designers an option, depending on satellite size and weight restrictions. An advantage
of this method is that the power consumption will not increase very much.
Switching control is very important in this method since it causes a single point
failure, and in case the switching is autonomous, it should be highly reliable.
3.5.2
Hot Redundancy
Alternately, hot redundancy known also as lockstep operation uses two identical
circuits performing identical operations with synchronized clocking, a technique
often used with microprocessors. Errors are detected when the processor outputs do not agree, implying that a potential SEU has occurred. The system
then has the option of reinitializing, etc. However, for longer satellite mission
time frames, lockstep circuits using commercial devices may cause TID-induced
problems; clock skew with increasing dosage may cause false triggers when the
lockstep devices respond to the dosage differently.
3.5.3
TMR
Triple modular redundancy, better known as TMR, is a widely used method
of protecting a system from both hard and soft failures. Voting takes lockstep systems one step further; the implementation involves using three identical
subsystems that are each carrying out the same functions simultaneously. The
output from each subsystem is then processed by a voter circuit which outputs
the majority of the three inputs. As long as two of the subsystems are functioning properly, the output will be valid (Moore and Pisacane, 1994).
TMR results in more than tripling the amount of logic required to implement
the design large overhead. TMR approach is mostly used in FPGA based systems. FPGAs provide higher gate counts and device logic densities than other
large-scale integration circuits. While high gate count reduces the IC count
3.6 OBC Processors
25
for satellite electrical designs, with the TMR scheme essentially over two thirds
of the available FPGAs gates are lost. There is a scheme by Xilinx for SEU
mitigation selection in Figure 3.6.
As long as the high energy flux is not sufficient to cause SEUs to two of the
three modules simultaneously (multiple bit errors), the mitigation of SEUs are
effectively done by TMR.
3.5.4
EDAC circuitry and Memory Scrubbing
EDAC codes are usually implemented in hardware using extra memory bits and
encoding/decoding circuitry. EDAC codes can only correct one bit error and to
avoid the accumulation of errors, the contents of memory are read periodically
and all the correctable errors are corrected. This operation is called “periodic
scrubbing” and thereby reducing the probability of multiple errors that might
not be correctable.
3.6
OBC Processors
There are many options for the selection of a processor for OBC. Selecting the
appropriate processor is important for the design, because it directly and indirectly affects the whole OBC and satellite design. Commonly used processors
are: Microprocessors, Microcontrollers, SoCs, FPGAs.
Microprocessors are much simpler processing units than processors, mainly
Figure 3.6: Mitigation Scheme Matrix, Adopted from (Xilinx, 2008)
3.6 OBC Processors
26
meant for computing. They require companion chips. They address huge memory banks, and they have cache memory because RAM and external memories
are slow.
Microcontrollers are meant for controlling. They have interrupt controller, so
they can perform real-time tasks. They can be used stand alone. They can drive
current. They do not have a cache memory. Real-time is critical in an embedded system. Modern microcontrollers have internal RAM which is surprisingly
fast, some of them have internal ROM, and mostly have external memory interface. Some microcontrollers have a floating point co-processor which can do
for example sine calculation. However, single chip microprocessors still offer
greater processing power compare to microcontrollers.
System on Chip (SoC)s emerged due to take the advantage of both microcontrollers and microprocessors. SoC can do the same amount of floating point
operation as core i7 but with much less power (1w).
Generic processors can be used in everything but also inefficient at what they
do. Digital Signal Processor (DSP), which is a specialized processor, is very fast
at a select type of operations like signal processing, but some other operations
like conditional computing is extremely slow. Graphics processing unit (GPU)s
are really fast at matrix computations which can be used in space applications
like Kalman filter for smoothing the noise or attitude determination, but they
miss basic features for normal applications.
FPGA is universally programmable logic chip and it allows near-instantaneous
execution of complex state-machine operations, and it can do conditional branching. Because it is programmable, it is fully custom-made chip; it is always optimized for the task. For a really lousy programmer in FPGAs, there might be
a better solution with the microcontroller, but essentially FPGA always offers
the best scenario. It is always the fastest in execution of a fixed algorithm for
given clock speed, FPGAs have speed limit. FPGA is quickly reprogrammable,
and it can be reprogrammed even every 10 ms.
There are several reasons for not using FPGA by everyone. First of all designing with a FPGA is difficult, when making a tradeoff between Microprocessor,
Microcontroller, DSP, etc., and a FPGA, designer stuck with the problem of
power consumption calculation, the only thing designer can do is to go through
the whole design process and measure or simulate its power usage, but in a
microcontroller the worst case is known which is always low, designer can get
an estimation and the design will always finish faster in terms of power con-
3.6 OBC Processors
27
sumption data.
Power consumption of FPGA in its own is always higher because FPGA has a
layer on top of logic gates themselves which do the configuration, even though
the configuration maybe fixed forever, those layers will always consume power,
because they have to remain in the same state. One cannot just program and
dump the layer because the layer will stop doing what it was supposed to do.
FPGA is parallel by nature like our brain, but for some reason human can only
think in straight line. Parallelism is one way for higher process rate, but it
works only for applications which are naturally parallel, not sequential.
Soft-core processors are always outcompeted by discrete processors because they
are optimized with no overhead. There is hybrid solution by Xilinx, the Extensible Processing Platform, which is essentially a microcontroller connecting
to an ocean of FPGA space through bus, so one can program software in the
microcontroller to feed data to a specific function that has been programmed
in FPGA; it is built in 28nm technology and very efficient.
The power trend is the limit for processors, the faster processor, the higher
power density; power density is the amount of watt per cm2 , and P4 was the
last processor to follow the power trend because Intel could not cool the processor anymore, a power density close to nuclear reactor.
There is another trend which says, the faster process, the lower power supply
voltage; but it is not possible to lower the voltage less than 1V because then
there will not be a state machine (Engelen, 2012).
In processor selection for space application, the following factors must be considered: throughput, on-chip memory size, physical size, pinout, power, supported interfaces, temperature range, and the package. Processor throughput
is a function of the instruction set and the clock speed; it can be calculated by
equation 3.1.
T hroughput(M IP S) = P
Clock(M Hz)
× instruction set clock cycle
(3.1)
instruction set
total instructions
A good rule of thumb is to set the processor throughput at four times the
estimate of minimum system throughput requirement (Wertz and Larson, 1999).
The on-chip memory decreases the processing time by providing single-cycleaccess memory for CPU. On-chip memory often connects by multiple busses
to CPU that could be accessed by different functional units in one clock-cycle.
The size and pinout directly affect the required space and weight of design
which eventually affect the system cost. Power consumption is so critical, as
3.6 OBC Processors
28
the generated power in solar cells is very limited. The processor must provide
interfaces with all the components on board and other subsystem of satellite.
In case an interface is missing, an additional chip is required which adds to the
size, weight, and power consumption of system. The processor must withstand
wide temperature change in space. The surface mount packages are preferred
for space application since these packages are more resistant to vibrations and
have smaller footprint.
Chapter 4
Aalto-1 satellite OBC
This chapter describes the main considerations and solutions chosen during
the Aalto-1 main OBC design and implementation. It discusses the techniques
followed during the hardware design of Aalto-1 OBC. The OBC functional requirements are presented, which served as the standard by which the entire
system was designed. The next section covers the procedure of selecting the
processor. This is important for the design, because selecting the appropriate
processor directly and indirectly affects the whole design. Following that, an
overview of the OBC will be provided, looking at the different subsystems: why
they are there and what they will do. A lower-level overview will then follow
which will briefly describe how all the subsystems were implemented and which
components were used.
4.1
Aalto-1 System Description
The payloads of Aalto-1 are:
• Spectral Imager (SPE) which is the main payload of Aalto-1, is based
on a tunable, piezoactuated Fabry-Perot interferometer that is able to
record 2D spatial images at one to 60 selected wavelength bands simultaneously (Blomberg et al., 2010).
4.1 Aalto-1 System Description
30
• Radiation Monitor (RADMON) to observe the fluxes of radiation belt
electrons and protons for the duration of the mission to provide mapping
of the inner-belt proton and electron spectra as a function of geographic
coordinates, especially in the SAA region.
• Electrostatic Plasma Brake (EPB) to de-orbit the satellite based on the
electric solar wind sail idea, where a charged tether, in plasma, will experience Coulomb drag from the plasma whenever the plasma is moving
with respect to the tether (Janhunen, 2010).
A Global Positioning System (GPS) receiver is also planned to be used to provide orbit determination capability for EPB experiment. The GPS will also
be used for precise time synchronization and satellite tracking from the ground
station.
The size of Aalto-1 will be 34 cm x 10 cm x 10 cm with a mass less than 4
kg. The satellite will also follow a modified PC/104 standard stackable configuration, with a stack-through bus connecting the satellite subsystems. The
subsystems are divided into the long stack and the short stack, and the short
stack is rotated 90 degrees in order to achieve the best orientation for radiation measurements as seen in Figure 4.1. The platform will have a VHF/UHF
data link for telemetry and command, a high bandwidth S-band downlink, a
complete ADCS and a high performance OBC with a Linux-based operating
system. In addition to these, the satellite will also house the three aforementioned payloads (Näsilä et al., 2011b).
The satellite will have a polar low-Earth orbit, preferably a Sun-synchronous
one. The sun-synchronous midday-midnight orbit provides optimal lighting
conditions for the Earth Observation payload and favorable night conditions
for the radiation detector. This orbit also provides sufficient solar cell-based
power generation. This is important as the average power available will be 5.8
W, and 8 W at maximum which limits cost, schedule, and implementation techniques available to the system designer (Nikkanen, 2010).
The satellite system block diagram with all interfaces and subsystems is shwon
in Figure 4.2.
4.1 Aalto-1 System Description
Figure 4.1: Aalto-1 Satellite Subsystems
Figure 4.2: Aalto-1 System Block Diagram
31
4.2 OBC Requirements
4.2
32
OBC Requirements
It is important to clearly define the requirements before starting any design.
The following requirements are defined while taking into account the aspects
discussed in the previous chapters, such as the limitations of a CubeSat and the
space environment.
4.2.1
Mission Requirements
The first step in analyzing and designing a space mission is to define mission
objectives: the broad goals which system must achieve to be productive (Wertz
and Larson, 1999). Mission requirements are top level requirements (lifetime,
launcher, payloads, scientific outcome, etc.), which determine the characteristics of mission. The Aalto-1 mission lifetime is expected to be two years, and
during this time, the OBC has to survive and work in the space environment,
so it has to be designed in such a way that it is highly reliable and robust.
The launcher is not decided before OBC design process, so the qualification
requirement regarding the launch vehicle will be according to the worst-case
scenario (Näsilä et al., 2011b).
All payloads except EPB have their own processors, but they are instrumentspecific and commanded by the main computer; so OBC takes care of high-level
controlling of payloads. The OBC is responsible for all on-board activities except attitude determination and control. The OBC collects the scientific data
in a predefined format from each payload and stores the data on non-volatile
memories (Näsilä et al., 2011b).
In Aalto-1, the telemetry consists of housekeeping data collected from different
subsystems including ADCS, EPS, and the science data from payloads which
will be stored in a non-volatile memory. When there is a pass over the main
ground station, the telemetry data will be transmitted and the contents of memory will be dumped to the ground; at the same time, the telecommand will be
received; the instructions will be loaded to OBSW and will get executed (Näsilä
et al., 2011b).
4.2 OBC Requirements
4.2.2
33
System Requirements
System requirements are derived from mission requirements and are defined at
system level. OBC System requirements can be subdivided into three different
groups:
• Functional Requirements (tasks, subsystem control, task scheduling, data
processing, communication subsystem and component level, data storage,
etc.)
• Operational Requirements (Operations modes (states), power modes, autonomy, failure detection isolation and recovery (FDIR), etc.)
• Interface Requirements and protocols (Compatibility with hardware and
software interfaces, standards and protocols)
Functional Requirements
Functional requirements define how well the system must perform to meet its
objectives. The mission objectives and requirements determine the functional
requirements for any satellite subsystem. For each subsystem there are different
requirements. In Aalto-1, the OBC is the command and data handling system
which receives, validates, decodes, and distributes commands to other subsystem of satellite and collects, processes, formats, and delivers telemetry. The
OBC shall (Modrzewski, 2011):
• be able to provide high processing power.
• receive the telecommands, store and execute them.
• collect, frame, and store the telemetry at least for 24 hours.
• be able to adjust the housekeeping collection rate by telecommand.
• provide variable telemetry data rates. These rates shall be selectable by
telecommand.
• provide precise local timing and time synchronization.
4.2 OBC Requirements
34
Operational Requirements
Operational requirements determine how the system operate and how users
interact with it to achieve its broad objectives (Wertz and Larson, 1999). In
Aalto-1, the OBC shall (Yanes, 2011):
• have autonomous operation.
• monitor battery charge level. In case of an out of limit condition, OBC
will initiate satellite safe mode.
• keep a list of commands which will be executed automatically in case of
an emergency.
• give conditional predefined high-level commands to the payloads.
• establish a communication link with the ground station.
Interface Requirements and protocols
• The OBC shall communicate with payload mostly through I2 C bus.
• Manage the data bus (always master).
• For high data rate transmission from SPE to OBC and from OBC to COM
subsystem, SPI is preferred.
• One UART is needed to interface with RADMON and one is needed for
GPS receiver.
• A serial connection is required for debugging.
4.2.3
Mission Constraints
The mission constraints are (Näsilä et al., 2011b):
• CubeSat standard, which requires Aalto-1 OBC to have low power consumption, less than 1W, compact size, 10cm x 10cm, and low weight,
100g.
4.3 Top level design decisions
35
• It has to handle commands and data during 2 year mission.
• No accurate thermal simulation is available for satellite at the moment,
so worst case (−65 ◦C to 90 ◦C) is concerned which at least industrial
components (−40 ◦C to 85 ◦C) are needed to almost cover this range.
• No vibration information is available due to undecided launcher, so the
worst-case scenario is concerned. It is preferred to use surface mount
components, and avoid Ball Grid Array (BGA) packages since the BGA
packages could not be easily qualified.
• The workforce are mostly students who have limited experience.
• limited budgets, 100k Euro, and short development, time 4 years.
4.2.4
Software Requirements
Developing software is as important as hardware; HW and SW design must go in
parallel. The principal requirement on the OBC software is that, it has to carry
out the mission tasks. Additionally, inflight software update techniques and
corresponding boot loader capabilities are desirable. This approach will make
the OBC architecture capable to recover from software bugs by software inflight
reloading. Utilization of a Real-Time Operating System (RTOS) provides several priority levels for tasks execution (Duma et al., 2007). The availability of
emulator, development tool support, and reusable reliable software module are
the design parameters for software developers to be considered when designing
the OBC (Wertz and Larson, 1999).
Each of the above requirements needs to be considered. In the following sections, the methods to fulfill these requirements are described.
4.3
Top level design decisions
It has been decided to use ARM processor running Linux operating system
in Aalto-1 OBC (Modrzewski, 2011), (Yanes, 2011). In this section, the ideas
behind these decisions are explained.
4.3 Top level design decisions
4.3.1
36
Technical justification for Linux as On-Board OS
Due to the nature of Aalto-1 and its custom development, Linux is the only
operating system available that full-fill the following requirements:
• Real-time capabilities
• Full availability of the source code
• Functional development environment
• Cross-platform support
• Community support
• POSIX compliant
• Support different processor families
Linux is a flexible Unix-like operating system that can run on a host of platforms from small embedded computers (1-2 MB) with no Memory Management
Unit (MMU) to super computers. While using OS limits the processor selection,
the software development will benefit a lot. A higher level of success is achieved
if there is already a development board with OS using a similar processor. This
was the case with Aalt-1 OBC processor. This means that no time was wasted
finding or developing I/O drivers, and a little time was spent for porting the
same OS on Aalto-1 OBC.
Linux has a proven track in embedded systems; including environments in which
the operating system must react to real-time inputs. Furthermore, its portability, documentation, testing and license, third party software, and the compatibility with the ground station and satellite contact software make Linux a
solid and robust environment in which the software development can be tested
and verified completely due to the availability of all the source code involved.
In addition, Linux can be adapted to any purpose without licensing constrains,
providing the possibility to develop custom solutions for any purpose. The
use of the Linux operating system allows developers to write powerful applications in short time, thanks to the great open source database. It also gives
the developers a common set of development tools including modern languages
like Python and a vast working, documented, and tested code base that could
4.3 Top level design decisions
37
be harvested over the Internet for free. Providing modern language support increases the number of developers able to contribute to the project and decreases
the amount of retraining that is necessary.
Linux also provides a host of tools that could be utilized in the operational
satellite without burdening the software development team with coding, testing, and maintenance overhead. These include free utilities that report memory
use, disk space utilization, software status, and date/time manipulation.
Another benefit of any commercial operating system like Linux that supports
an IP protocol stack is the existence of a ready-made communication path that
exists below the application level software. Utilities like PING, SSH, and SCP
provide an out of the box communication mechanism that supports an effective
backup resource to the primary communication software. In QuakeSat (Bleier
et al., 2004), a CubeSat mission which also utilized Linux OS, the operators used
the PING and SSH utilities to communicate with the satellite when the payload
software temporarily failed. This helped the ground team validate modem and
radio hardware health when normal satellite operations were impaired.
4.3.2
Technical justification for using ARM processors
ARM processors are widely used in mobile devices due to their low power consumption and high performance architecture. Many major processor vendors
like ATMEL and Texas Instruments have produced their processors based this
architecture. Each of these vendors offers different peripherals and features for
different applications. For any application it is possible to find an ARM processor with most of needed peripherals and processing power. Due to widespread
use of the ARM processors, there are many software supports from user’s community providing design ideas and solutions for different tasks. There have
already been several families of ARM processor produced, newer design offer
more features and performance. The nice property of the new designs is that
they are compatible with older designs, so developers can easily migrate to the
newer processors without much effort. In space, the total energy consumption is
very important due to the limited power in battery. ARM processors consume
low power because they integrate more functionality on a single die than other
processors and they usually function at slower clock speed. Another reason is
that ARM does more aggressive power gating, effectively shutting down parts
4.4 Related Works
38
of the processor that are not currently in use.
4.4
Related Works
In Aalto-1, the main characteristic of OBC is utilizing a commercial operating
system. The technical justification of using Linux OS is explained in 4.3. The
general trend is to use custom OS on-board or no OS at all, and there have
been a few CubeSats which had a commercial OS on-board. The OBC specifications of these CubeSats are listed in Table 4.1. This table demonstrates the
wide range of options for processors, memories, and operating systems. Among
these CubeSats, QuakeSat was the only one used full featured Linux. QuakeSat
utilized a Diamond Systems Prometheus PC/104 single board computers. Although, this computer could be down clocked to reduce power consumption of
processor, its power consumption still would be significantly higher than Aalto1 available power on-board. To achieve a low power and high performance
OBC design a new design using an ARM processor on-board is needed. As seen
from the previous missions, the ARM processors provide the most power saving
designs.
4.5
Processor Selection
From the Linux perspective, there are 2 very different kinds of ARM chips:
• ARM processors that include a MMU, and can run standard Linux
• ARM processors without MMU. These can run a modified version of Linux
called uClinux, enabling Linux to run on MMU-less platforms or embedded processors with Memory Protection Unit (MPU).
Because of security considerations for MMU-less processors, it is unwise to use
them when 3rd-party or untrusted code will be running on the device. For
locked-down, single function devices, MMU-less processors may be appropriate.
They are usually less expensive than processors with MMU (eLinux, 2011).
MMU provides independent virtual memory for each process, and systems that
4.5 Processor Selection
Satellite
Organization
AAUSAT-
Aalborg Uni-
II
versity
39
Main Proces-
Clock Fre-
sor
quency
AT91SAM7A1 8/40MHz
Memory
Power
Operating
System
RAM:
<300mW
eCos/
2MB,
@ 40MHz
RedBoot
ROM:
and
4MB,
<80mW @
Flash:
8MHz
4MB
DTU Sat-1
University of
AT91M40800
16MHz
Denmark
RAM:
155.1mW
eCos
Linux
1MB,
Flash:
2MB
QuakeSat
CUTE-1.7
Stanford Uni-
ZFMicro De-
100MHz
RAM:
5W at 100
versity
vices ZFx86
down
32MB,
MHz
clocked to
Flash:
66MHz
128MB
400MHz
RAM:
Tokyo
In-
stitute
of
ARMV4I
5V
32MB,
Technology
Windows
CE.NET
Flash:
128MB
STUDSAT
India- 7 Aca-
UC3A0512
66MHz
RAM:
demic Institu-
64KB,
tions
Flash:
3.3V
VxWorks
100mW
Salvo 4
512KB
ITUpSAT
Istanbul
(Pumpkin
Technical
Design)
7.4MHz
RAM:
10KB,
Unversity
MSP430F1611
Flash:
50KB
Table 4.1: OBC Specifications of CubeSat Missions with Commercial Operating
Systems
4.5 Processor Selection
40
uses a processor with MMU is much more reliable because the erroneous operation of one application is not able to hang the whole system.
There were few processors which could fulfill the Aalto-1 OBC requirements.
The processor must have:
• an ARM architecture
• a MMU
• I2 C,SPI,UART, interfaces
• non-BGA package
• industrial temperature range −40 ◦C to 85 ◦C
In ARM architecture series, only the following series were available to have a
MMU and not having a BGA package:
ARM720T, ARM920T, ARM922T, ARM926EJ-S.
The newer ARM families were all in BGA. ARM9 family is preferred because of
higher performance and more features than ARM7 family. A list of candidates
processors are presented in Table 4.2.
Processor
Vendor
Seri
Frequency Package
(MHz)
AT91RM9200
ATMEL
ARM920T
180
208PQFP*
SAM9260
ATMEL
ARM926EJ-S
180/210
208PQFP
SAM9XE
ATMEL
ARM926EJ-S
180
208PQFP
AM1705
TI
ARM926EJ-S
375/456
176HLQFP
MCIMX233
Freescale
ARM926EJ-S
454
128LQFP
CNS2131
Cavium
ARM922
200/250
128PQFP
EP9302
Cirrus
ARM920T
200
208PQFP
128/256/512
CAG4C
Logic
Table 4.2: Aalto-1 OBC Processor Candidates
* Plastic Quad Flat Pack (PQFP)
4.6 System Configuration
41
Among the above processor, those from ATMEL had better documentations and
support, bigger community, and more development kits available. AT91RM9200
was the most mature product of ATMEL ARM9 series and, consequently, all
aspect of it has already been studied and revealed by the community. So, after a long selection process AT91RM9200 has been chosen (Modrzewski, 2011).
Although, ARM processors from ATMEL have been used in several CubeSat
projects (DTU, 2003), (Aalborg, 2008), (Kanpur, 2008), (STUDSAT, 2010), the
AT91RM9200 processor has never been used before, and it requires to be tested
and qualified before it gets into the flight model.
A great advantage of AT91RM9200 was having some fairly cheap development
kits like BF220 (BoFF, 2009) and Centipad (Hasenstab, 2012), providing the
most interfaces and hardware needed in OBC but in a different form factor.
Computer BF220 has been designed for use in industrial automation. This
computer comes with a Linux OS adapted for its hardware which made the developing applications and porting the kernel to Aalto-1 OBC easier. Based on
BF220 computer, the OBC has been designed. Since this board is a proven operational product, it provides some initial values and solutions for the selection
of other components of OBC. Centipad was another development board which
was concerned in the later stages of the design both in hardware and software
development due to its more advanced features. Other development kits for
AT91RM9200 processor were: RM9200-EK (ATMEL, 2010), RM9200-DK (ATMEL, 2005), Open ARM9 SBC (Ribeiro, 2005), HiCO.ARM9-Core (emtrion,
2012), Linuxstamp (OpenCircuits, 2011).
4.6
4.6.1
System Configuration
OBC Architecture
The Aalto-1 OBC is based on AT91RM9200 processor, utilizing 32MB of external RAMs. The OBC is equipped with an 8MB DataFlash and a microSD
memory for data storage. The processor can use either of these memories for
booting up, enabling the use of a fail-safe mode. This lowers the chances of
faults during boot-up and enables the possibility of uploading new software after launch of satellite. The OBC system block diagram with all interfaces and
4.6 System Configuration
42
subsystems/components is shown in Figure 4.3.
4.6.2
Redundancy Strategy
Considering the requirements discussed in the section 4.2, a long lifespan is more
probable to be achieved with redundant design. Therefore a redundant OBC
is required. The redundancy between circuits can provide a potential means
of recovery from a failure. Cold-redundant design consumes less power than a
hot-redundant design. Aalto-1 OBC is designed to be fully “Cold Redundant”,
meaning that, the OBC will have two duplicate computers that only one of
them is powered and active. The other computer is switched off, and the power
switching between two systems is decided by a third party (an arbiter) automatically. A hard coded signal is produced by active processor and the arbiter
observes the hard coded signal. In case there is failure in signal for a certain
time, the arbiter reset the active computer. After few iteration, if there is still
a failure, the arbiter cuts the power from the current computer and activate the
other computer. Switching also could be controlled by the ground station. Both
units will be physically placed on a single Printed Circuit Board (PCB). Each
unit will be equipped with a dedicated processor, RAM, and flash memories,
etc. Figure 4.4.
4.6.3
Software Configuration
The software is designed to boot-up and afterwards serve the command and data
handling task. The Aalto-1 OBC is responsible for managing all of the satellite
subsystems including EPS, payloads, ADCS, and the radios. The AT91RM9200
has a throughput of 200 MIPS at 180 MHz clock frequency. The application
programs run in 32MB SDRAM. For data storage there are two non-volatile
memories: 8MB DataFlash and up to 32GB microSD memory. The Atmel
Dataflash device is a specific technology name dedicated to external NOR flash
devices included with the AT91 family of hardware (ATMEL, 2002). These
memories are also used for storing satellite bootloader in order to increase the
reliability of booting procedure. The number of external non-volatile memory
devices available on OBC allows for up to two primary methodologies for storing
4.6 System Configuration
Figure 4.3: Aalto-1 OBC Block Diagram
Figure 4.4: Aalto-1 Redundant OBC Block Diagram
43
4.7 Component screening and selection
44
and booting Linux, as well as storing other desired data. The processor can use
either of these memories for booting up, enabling the use of a fail safe mode.
This lowers the chances of faults during boot-up.
In Aalto-1 OBC, every external memory device has different capacities and
interfaces: 8MB Dataflash with a serial peripheral interface (SPI), up to 32GB
microSD (non-SDHC required to utilize as a boot device), and 32MB volatile
SDRAM with a standard parallel interface. Typically, one of these non-volatile
external memory devices is utilized as the primary boot device, which allows for
two boot device options. This boot device contains primary dependencies for
Linux, as well as other startup dependencies. The other non-volatile memory
devices can be used for secondary data storage.
The primary components that make up Linux are commonly known as a system
images, which are compressed files containing specific elements of the Linux OS.
These main images include the kernel and the root file system. The kernel, which
is the core of the OS, is a separate program that executes in volatile memory,
and it is responsible for hardware control, system scheduling, and system I/O
after full system startup. The root file system is the primary directory and file
tree hierarchy that contains all the dependencies the system needs to properly
run such as other programs, libraries, and modules. In addition to these critical
elements, bootloader program is so vital which exists as a multi-stage program.
More specifically, two of these stages are the AT91 boot program and U-Boot.
These stages are all primary components necessary for startup and full system
boot up.
4.7
Component screening and selection
The command and data handling bus requires one I2 C bus to interface with
ADCS, EPS, EPB, SPE, and COM. Three Serial Peripheral Interface (SPI) interfaces are needed, one for DataFlash, another for image capture from SPE
and the last one for communication with S-BAND part of COM.
Screening means choosing the best component from a batch of similar components. There is many ways to do this; one way is temperature cycling which
could be done for example for processors.
The components are chosen with industrial specifications, small packages, and
low power consumption enabling the OBC to operate in an extended tempera-
4.7 Component screening and selection
45
ture range using minimal resources. In selecting the components, the following
consideration has been taken into account (Näsilä et al., 2011b):
• Materials need to withstand high and low temperatures (worst case−65 ◦C
to 90 ◦C)
• No hazardous materials shall be used.
• Materials shall satisfy the following low out-gassing criterion to prevent
contamination of other spacecraft during integration, testing, and launch.
– Total Mass Loss (TML) shall be < 1.0%
– Collected Volatile Condensable Material (CVCM) shall be < 0.1%
• For electronics:
– Prefer ceramic/metal casings (not plastic)
– Restriction of Hazardous Substances (RoHS) Compliance components need to be pretinned/solder dipped so try to avoid them.
4.7.1
Volatile Memory
The Aalto-1 OBC needs at least 32 Mbytes of RAM to be able to temporary
keep and process images from SPE, measurements, and payload data simultaneously. Because of the fact that is has been decided to run an operating
system, an increased amount of RAM is necessary. Taking into consideration
also the amount of data that has to be processed, fast Synchronous Dynamic
Random-Access Memory (SDRAM) seems to be indispensable. This type of
memory is supported by the AT91RM9200 processor through External Bus Interface (EBI). The AT91RM9200 SDRAM controller has self-refresh mode and
energy-saving capabilities by supporting low-power mode. It also supports error
detection by refresh error interrupt (ATMEL, 2009b).
The IS42S16160D is 268,435,456 bits synchronous high speed Dynamic RAM
organized as 4 x 4,196,304 words by 16bits, fabricated with ISSI high performance CMOS technology. Synchronous design allows precise cycle control with
the use of system clock I/O transactions is possible on every clock cycle. Range
4.7 Component screening and selection
46
of operating frequencies, programmable burst length and programmable latencies allow the same device to be useful for a variety of high bandwidth, high
performance memory system applications. It supports industrial temperature
from −40 ◦C to 85 ◦C (ISSI, 2011).
4.7.2
Non-Volatile Memories
Non-volatile high-capacitive memory storage is needed to keep the telemetry and
payload data until sending it to the ground station. High-capacitive microSD
Flash memory is usually utilized for this purpose. DataFlash could also be
used for data storage. Flash memory is a non-volatile memory unit, in other
words it retains its value even when not powered. It has very fast access speeds,
but writing to flash memory is considerably slower than reading from it. Flash
memory is also very resistant to radiation effects when being accessed, but it is
susceptible to SEEs, such as SEU and SEL, when being programmed. Taking
the above into consideration, flash memory is a very good storage candidate for
OBC software. The OBC software is updated very seldom when the satellite is
in orbit, therefore negating its weakness of slow programming time and SEEs.
When continuously accessed during program execution it is very resistant to
SEEs.
DataFlash
A serial data flash is chosen as the primary bootloader memory. The AT45DB642D
is a 2.7-3.6 volt only, serial interface Flash memory ideally suited for a wide variety of digital voice, image, program code and data-storage applications. It
supports RapidS serial interface which is SPI compatible for frequencies up
to 66 MHz. Its 69,206,016bits of memory are organized as 8,192 pages of
1,024 bytes each. In addition to the main memory, the AT45DB642D also contains one Static Random-Access Memory (SRAM) data buffer of 1,024 bytes.
The buffer allows receiving of data while a page in the main memory is being reprogrammed. Electrically Erasable Programmable Read-Only Memory
(EEPROM) emulation (bit or byte alterability) is easily handled with a selfcontained three step Read-Modify-Write operation. Unlike conventional Flash
4.7 Component screening and selection
47
memories that are accessed randomly with multiple address lines and a parallel interface, the DataFlash uses an SPI serial interface to sequentially access
its data. SPI mode 0 and mode 3 are supported. Also this chip has a wide
temperature under bias from −55 ◦C to 125 ◦C (ATMEL, 2009a).
MicroSD
The memory subsystem further includes up to 32 GB microSD storage card.
The microSD memory is a non-volatile memory based on NAND flash technology and has exceptionally high capacity. The processor uses the MultiMedia
Card Interface (MCI) interface to communicate with the microSD card. The
microSD offers another form of long-term storage that could be used to log various telemetry data to be requested by the ground station at a later time. This
memory is necessary if main computer is supposed to store bigger amount of
data. Main processing unit supports almost all microSD memory types available
in the market.
4.7.3
LVDS
Low-Voltage Differential Signaling (LVDS) is a high-speed digital interface that
has become the solution for many applications that demand low power consumption and high noise immunity for high data rates. The use of LVDS on
board of satellites has become more and more popular. For example SpaceWire
links are based on LVDS but it is also used for the distribution of many other
signal types within a PCB, units and between boxes (National-Instruments,
2012).
The LVDS standard defines the electrical characteristics of the transmitter and
receiver of an LVDS interface. LVDS uses differential signals with low voltage
swings to transmit data at high rates. Differential signals contrast to traditional
single-ended signals in that two complementary lines are used to transmit a signal instead of one line. That is, two signals are generated of opposite polarity,
and then the data transmission references the two signals to one another. This
transmission scheme provides the kind of large common-mode rejection and
noise immunity to a data transmission system that a single-ended system referenced only to ground cannot provide. The ability to reject common-mode noise
4.7 Component screening and selection
48
in this manner makes LVDS less sensitive to environmental noise and reduces
the risk of noise related problems, such as crosstalk from neighboring lines. It
also results in a reduced amount of noise emission. Another major benefit of
LVDS is the low power consumption of LVDS devices (National-Instruments,
2012).
In order to take the advantages of LVDS interfacing, the high data rate transmission on-board are done through LVDS transceivers.
4.7.4
I/O Capability
The idea of having a generic bus capable of supporting a wide variety of payloads makes the system simpler to implement. This idea needs all the payloads
to be custom-made providing similar interfaces. But having only a generic bus
could not interface all the subsystems to OBC in Aalto-1, since, the payloads
are provided from different institutions. Each payload has its own specific interface requirements, so OBC has to be adapted to the interfaces required by
the payloads providers.
I2 C
The Inter-Integrated Circuit (I2 C) is an effective method of communication
based on bus architecture. It has become a recognized standard throughout
industry and is used by all major IC manufacturers. In I2 C there is a master, and
there could be many slave modules. The master can access any of slaves by using
their unique address for data transmission. If needed, it is also possible to have
multiple bus masters by using arbitration, clock synchronization and stretching.
The multi-master bus must include collision detection and arbitration to prevent
data corruption if two or more masters simultaneously initiate data transfer. If
a bus master fails, the clock line will stall propagating through the bus to all
subsystems. In order to solve this problem Dallas 1-wire interface could be used
to reset all nodes or change bus master (Semiconductors, 2000).
In Aalto-1 OBC, a standard I2 C bus communication protocol is implemented
physically. Two wires, called Serial Clock (SCL) and Serial Data (SDA) are
required according to the I2 C protocol. SCL is used to synchronize all data
transfers over the I2 C bus. Both of the lines are connected to all devices on
4.7 Component screening and selection
49
the I2 C bus. Besides, one set of pull-up resistors is needed on the two lines,
SCL & SDA, in order to make sure that they are capable of driving high. The
pull-up resistors and their connections are shown in Figure 4.5. Only one set
of pull up resistors is required for the whole I2 C bus. It is recommended on the
board of OBC with value of 1.8k - 4.7k experimentally (depending upon the
number of components connected to the line) (Semiconductors, 2000). It has
been decided that OBC, alone, will have the right to be a master on I2 C bus.
This is, primarily, because it will reduce the complications of communication
initiation and data transfer processes. This will also eliminate any of possible
issues regarding bus arbitration. The OBC will poll all the nodes sequentially
and systematically in a pre-defined sequence.
Figure 4.5: Physical Layer of I2 C Bus
UART
The Universal Asynchronous Receiver/Transmitter (UART) is a simple pointto-point communication interface. Data is serially transmitted on one channel
and received on another. Transmission is asynchronous in the sense that it can
start at any time, but both transmitter and receiver should be set up with the
same speed for operation.
In Aalto-1 OBC, the UART interface is used for different purposes. There are at
least four UART controllers in AT91RM9200. One UART has been dedicated
to the GPS module. Another UART is assigned to RADMON through LVDS
transceiver. One UART is the processor’s default unit for debugging the Linux
kernel using a RS-232 transceiver.
4.7 Component screening and selection
50
SPI
The serial peripheral interface (SPI) is a high-speed synchronous serial input/
output (I/O) port that allows a serial bit stream of programmed length (one
to sixteen bits) to be shifted into and out of the device at a programmed bittransfer rate (Texas, 2009). The SPI system consists of two data lines and two
control lines (ATMEL, 2009b):
• Master Out Slave In (MOSI): This data line supplies the output data from
the master shifted into the input(s) of the slave(s).
• Master In Slave Out (MISO): This data line supplies the output data from
a slave to the input of the master. There may be no more than one slave
transmitting data during any particular transfer.
• Serial Clock (SPCK): This control line is driven by the master and regulates the flow of the data bits. The master may transmit data at a variety
of baud rates; the SPCK line cycles once for each bit that is transmitted.
• Slave Select (NSS): This control line allows slaves to be turned on and off
by hardware.
There is one SPI interface in the AT91RM920 having four chip-selects. It means
that it supports at least four modules. In Aalto-1 OBC, one SPI channel is used
to communicate with DataFlash. When OBC receives an image file which is
taken by a camera onboard SPE for telemetry, transmitting this large file over
the communal shared bus (I2 C in the case of most CubeSats) would unnecessarily occupy the bus for a long period of time and possibly prevent important
communication to take place between the other satellite subsystems. To prevent
this, another SPI is used for point-to-point access to SPE through LVDS where
large amounts of data transfer needs to take place. The third SPI is dedicated
to S-BAND module which is used for sending the satellite’s scientific data in
high data rate when it has a pass over Aalto University. This module is also
using LVDS transceiver between the OBC and itself. SPI has rather higher data
rate transmission compare to UART and I2 C interfaces, and the data rate is
limited by the slave module.
4.8 Power Management
4.8
51
Power Management
AT91RM9200 has a Power Management Controller (PMC) that optimizes power
consumption of the whole system and supports the Normal, Idle, Slow Clock and
Standby operating modes. In power-save modes, PMC programmably reduces
operating frequency while sustaining the normal operation. It keeps system
power consumption to a minimum by selectively enabling/disabling the colck
of processor and various peripherals under software control. The AT91RM9200
requires two voltage level for operation (ATMEL, 2009b):
• 3.3V for interface and peripheral I/O lines (VDDIOM, VDDIOP)
• 1.8V for core, PLL, and oscillators (VDDCORE, VDDPLL, VDDOSC)
The 3.3V is provided directly from EPS, and the 1.8V is regulated by a switching step-down regulator. The switching regulators have higher efficiency (up
to 96%) than linear regulators (<40%). The selected regulator was LTC34061.8 from LINEAR TECHNOLOGY. Its switching frequency is internally set at
1.5MHz, allowing the use of small surface mount inductors and capacitors. It
can have 2.5V to 5.5V input voltage range and provides 600 mA (Linear, 2002)
which is sufficient for operation of AT91RM9200.
The AT91RM9200 consumes about 500 µA of static current on VDDCORE at
25 ◦C. For dynamic power consumption, the AT91RM9200 consumes a maximum of 25 mA on VDDCORE at maximum speed in typical conditions (1.8V,
25 ◦C), processor running full-performance algorithm (ATMEL, 2009b).
4.9
Supervisory Circuit
In order to monitor the power-fail of supply voltages required by OBC, a supervisory circuit is needed. In OBC it is not only important to supervise the supply
voltage, it is also important to ensure correct program execution. The task of a
watchdog is to ensure that the program is not stalled in an indefinite loop. For
these purposes TPS3306-18 was selected. This chip monitors two independent
supply voltages of 3.3V and 1.8V. In addition, this device integrates a watchdog
4.10 Layout Design
52
timer that is periodically triggered by a positive or negative transition of watchdog input. When the processor fails to retrigger the watchdog circuit within
the time-out interval, a reset becomes active for a time period (Texas, 2006).
By resetting the processor, it is reinitialized and if the power-fail was transient
the OBC will boot successfully.
4.10
Layout Design
The schematic and layout design of the electrical model of OBC were done in
EAGLE software package. This model is only for single computer. The main
idea was to see the feasibility of placing one computer with all required components in half of a CubeSat board area. The PCB was decided to have only
two layers stackup, to reduce the manufacturing cost and also provide access to
all signals on-board. By accessing all the signals, the study of high frequency
signals characteristics along the traces by oscilloscope becomes possible, and
the debugging of soldering becomes simpler. In engineering model of OBC, the
PCB will be multilayer (4 to 8 layers). The two layers stackup limits the density of the components placements thus some of components were placed on the
bottom side of the board. Having a double sided board also provided shorter
traces between the processor and SDRAM which contained high frequency signals. Since this OBC was occupying half of available board area, the feasibility
of having a redundant computer in addition to the primary computer was approved, see Figure 4.6.
4.11
Booting
The Aalto-1 on-board computer runs GNU/Linux, a Unix-like operating system,
using a monolithic architecture for its kernel (Linux). The on-board computer
has been adapted and customized to operate under GNU/Linux, with an emphasis on its devices drivers, together with the modifications required to adapt
it to an embedded environment to be used in a Nano-satellite.
One of the most vital functions of the OBC is the Boot-up sequence. The
4.11 Booting
53
(a) PCB Layout
(b) Board
Figure 4.6: Electrical Model of Aalto-1 OBC
purpose of the Boot-up sequence is to configure the processor and activate the
Command and Data Handling (CDH). The boot sequence is to be carried out
autonomously, because during boot-up there would be no intelligent control and
no communication between the Earth and the satellite. If the boot sequence
failed and the OBC is not prepared to deal with the fault by itself, the satellite
would be lost.
Bootloaders are typically required with hardware that uses an operating system. They will execute as the hardware is initially powered and usually reside
on a processor-internal ROM or similar device. Their primary responsibility
is to perform low-level hardware initialization for devices such as memory or
oscillators, which are necessary prior to loading an actual OS. In the case of
the AT91RM9200, it contains an internal boot program on its 128KB ROM,
that is capable of downloading and running an application from external storage media into internal SRAM. It integrates a Bootloader and a boot Uploader
to assure correct information download. This internal boot program only acts
as a first-stage program, which results in a very limited hardware configuration
when done executing. This internal boot program can support multiple primary
boot devices dynamically, and it will attempt to search and detect a suitable
second-stage boot program that can be loaded from other external memory
devices. After the first-stage completes scanning, if a valid second-stage boot
program has not been detected or perhaps no external memory devices exist,
an in-system programming utility also contained within the internal ROM is
loaded. It initializes the Debug Unit serial port (DBGU). It then waits for any
4.11 Booting
54
transaction and downloads a piece of code into the internal SRAM via a Device Firmware Upgrade (DFU) protocol for XMODEM protocol for the DBGU.
This allows the system to be reprogrammed or perhaps troubleshooted in the
event that the user may not want to fully boot the system. A flow diagram depicting the overall behavior of the first-stage internal boot program is show in
Figure 4.7. When the first-stage completes execution, control is handed to the
Figure 4.7: Internal First-Stage Bootloader Flow Diagram
second-stage boot program, which is ultimately responsible for loading the OS.
The second-stage boot program is Das U-Boot (Universal Bootloader) (Denk,
2011) an open source bootloader used in embedded devices. It looks for a kernel image and root file system image in the DataFlash connected to the SPI
or microSD memory connected to the external bus interface. Then Linux OS
is loaded and OBC continues with full system setup for CDH. Aside from the
first and second stages, other stages are loaded into external SDRAM before
executing.
OBC is designed so that after launch of satellite, new software could be up-
4.12 OBC Testing
55
loaded to DataFlash or microSD memory and after a reset the OBC would run
with the new software. This would be desirable if the software onboard did not
work properly. Another reason could be e.g. trying to optimize the performance
of satellite.
4.12
OBC Testing
The main purpose of testing performed for the Aalto-1 OBC was the verification of well-functioning of hardware components, together with their resistance
under critical conditions in a thermal cycling process.
4.12.1
Test Software
The testing procedure has been designed to subject the on-board computer
to a high load of activity, involving all the main hardware components. The
stressing activity that the testing software generates, targets the following main
components:
• On-board computer processor
• RAM Memory
• Mass storage device (MMC)
• System BUS
The software utilized is named “stress” (version 1.0.4) (Oklahoma, 2009). This
software provides the capability to stress different hardware resources through
POSIX compliant system calls. The Stress internal organization is in essence
a loop that forks worker processes and then waits for them to either complete
normally or exit with an error. The following list enumerates the system calls
utilized in the testing:
• void *malloc(size_t size); (OpenGroup, 2004c)
• void free(void *ptr); (OpenGroup, 2004b)
4.12 OBC Testing
56
• int mkstemp(char *template); (OpenGroup, 2004d)
• ssize_t write(int fildes, const void *buf, size_t nbyte); (OpenGroup, 2004e)
• pid_t fork(void); (OpenGroup, 2004a)
The logic that follows the testing procedure is based on the execution of the
test cases in a defined amount of time N. The software proceeds to the execution of CPU using through the creation of multiple process child, continuing
with memory allocation in blocks of 2 megabytes (MB), and finalizing with the
writing of multiple small files of 5 kilobytes of size(kB). The results of the test
cases are saved in the mass-storage device for previous analysis and processing.
All of the mentioned process is handled through a shell-script that is placed
in the root file-system of the Aalto-1 on board computer. This shell-script requires the user interaction, in order to be executed / paused. This procedure
guarantees us that the on-board computer is stressed during the amount of time
configured, making use of all of its main hardware components.
4.12.2
Test Procedures
Temperature cycling was performed in climate test station at Finnish Meteorological Institute (FMI)’s space instrument calibration laboratory. The cycling
consisted of 50 cycles from −65 ◦C to 90 ◦C. The dwell time in both extreme
temperatures was 1 hour. 3 boards were powered and running the test program
during the cycling and 2 boards were not powered.
Test Equipment
• Weiss DU 40/70 Temperature test station
• Vaisala HMT337 Humidity and Temperature Transmitter (The transmitter provides more accurate measurement for temperature of inside chamber)
Test Flow
1. Functional test at laboratory, log “before” OBC test data for 24 hours.
4.12 OBC Testing
57
2. Temperature cycling, log “while” OBC test data for 50 cycles.
3. Functional test at laboratory, log “after” OBC test data for 24 hours.
4. Compare the amount of Errors from “before”, “while”& “after” test data
5. Determine results.
Temperature Cycling
The DU40-70 station was programmed to do the following tasks:
It raises the temperature to 90 ◦C, and stays on the program line until the chamber reaches the set point temperature. It stays for 1 hour at 90 ◦C then lowers
the temperature to −65 ◦C. It stays on the program line until the chamber
reaches the set point and stays for 1 hour at −65 ◦C. It does the above loop for
50 cycles and ends the program by returning the chamber temperature to about
20 ◦C. The profiles for two thermal cycles of DU40-70 station and HMT337 temperature transmitter are shown in Figures 4.8 and 4.9, respectively.
4.12.3
Test Results
All the boards had 100% success in “before” log means that all of them were
functioning and healthy before test. In “while” log, all the three powered boards
experienced at least one reset. The plastic cover of one microSD memory was
Figure 4.8: Weiss Thermal Cycling Profile
4.12 OBC Testing
58
Figure 4.9: HMT337 Temperature Transmitter Thermal Cycling Profile
deformed but it was still working fine. Writing data to one of microSD memories
was not possible, even after cycling, which could explain the reason for resetting
of boards. In “after” log again all the boards had 100% success which means
that no component except the microSD memory was affected by thermal cycling
and the reason for resetting of all the boards were the microSD memory. This
will be verified in the engineering model by using a NAND flash memory on
board.
Chapter 5
Summary and Conclusions
In this thesis an electrical model of OBC for Aalto-1 CubeSat was designed
and implemented.
The system requirements and constraints were defined,
and accordingly, the suitable components were selected. The ARM processor, AT91RM9200, provides all the functionality and requirements for Aalto-1
OBC. To achieve a higher reliability, the feasibility of having a redundant computer hardware on a single CubeSat board was investigated and confirmed. To
add fail safe mode for boot-up two independent flash memories were used for
bootloader storage. A supervisory circuit was also used to monitor the power
supplies; in addition it acts as watchdog to ensure that the OBSW is not stalled
in an indefinite loop. It was shown that using Linux as an OS for OBSW is
beneficial for CubeSat projects. The OBC boots-up in less than 20 seconds and
runs smoothly the Linux OS adapted to its hardware. This design based on the
ARM architecture running a Linux OS fulfills the very low power consumption;
the overall power consumption of OBC in idle mode is about 200 mW, and under stress, it consumes about 400 mW. The functionality of all subsystems and
interfaces of OBC was tested and a thermal cycling was performed to validate
the survivability of the design in extreme temperatures.
5.1 Future Work
5.1
60
Future Work
There are some considerations and developments which will be included in the
engineering model of OBC. It will mostly focus on qualification of the processor
and other components:
• For processors screening a socket will be added to the board since the
soldering and unsoldering of processor due to high pin count is so difficult.
The dimensions of the board will be bigger because of the bulky socket.
• An EEPROM will be added to contains the bootloader configuration data.
• Since the microSD memories have not withstood the extreme thermal
cycling test, a NAND memory will be added in to increase the reliability.
• An external real-time clock IC and a battery will be added to provide the
operating system with the real time at startup. This will also provide a
wake up system for an sleeping OBC via the INT line of RTC IC.
The design of OBC for Aalto-1 CubeSat will be continued, and its capabilities
and reliability will be further improved.
References
Aalborg, U. (2008). AAUSAT-II.
URL: http: // www. space. aau. dk/ aausatii/ homepage/ index. php?
language= en&page= obc/ obc
ATMEL (2002). Using Atmel’s DataFlash.
URL: http: // www. atmel. com/ Images/ doc0842. pdf
ATMEL (2005). RM9200-DK.
URL:
http: // armlinux. simtec. co. uk/ kautobuild/ 2. 6.
24-git13/ at91rm9200dk_ defconfig. html
ATMEL (2009a). AT45DB642D Complete.
URL: http: // www. atmel. com/ Images/ doc3542. pdf
ATMEL (2009b). AT91RM9200.
URL: http: // www. atmel. com/ Images/ doc1768. pdf
ATMEL (2010). RM9200-EK.
URL:
http: // www. at91. com/ component/ resource/ article/
products/ 9-sam9/ 581-rm9200-ek. html
Barnhart, D.J. (2008). Very Small Satellite Design for Space Sensor
Networks. Ph.D. thesis, Faculty of Engineering and Physical Sciences,
University of Surrey, United Kingdom.
Bleier, T., Clarke, P., Cutler, J., DeMartini, L., Dunson, C.,
Flagg, S., Lorenz, A., and Tapio, E. (2004). QuakeSat Lessons
Learned: Notes from the Development of a Triple CubeSat.
Blomberg, M., Kattelus, H., and Miranto, A. (2010). Electrically
tunable surface micromachined Fabry-Perot interferometer for visible light.
Sensors and Actuators A : Physical, 162:184–188.
REFERENCES
62
BoFF (2009). BF220.
URL: http: // www. boff. pl/
Botma, P.J. (2011). The Design and Development of an ADCS OBC for
a CubeSat. Master’s thesis, Faculty of Engineering, Stellenbosch University.
Bridges, C. (2012). CubeSat course presentation on On-Board Computing
Challenges on in LEO.
URL: http: // www. youtube. com/ watch? v= 6qlue8-O5i4
CalPoly (2009). CubeSatDesign Specification Rev. 12.
URL: www. cubesat. org/ images/ developers/ cds_ rev12. pdf
Denk, W. (2011). U-boot.
URL: http: // www. denx. de/ wiki/ U-Boot/ Documentation
DTU (2003). DTUsat-1.
URL: http: // dtusat1. dtusat. dtu. dk
Duma, M., Urhan, H., Turhan, O., Kozal, O., , and Gurun,
M. (2007). A new generation On-Board Computer and Solid State Data
Recorder suitable for SpaceWire Platforms. In The 3rd International Conference on Recent Advances in Space Technologies, pages 429–432.
Eickhoff, J., editor (2012). Onboard Computers, Onboard Software and
Satellite Operations: An Introduction. Springer Aerospace Technology.
eLinux (2011). Embedded Linux Wiki.
URL: http: // elinux. org/ Processors
emtrion (2012). HiCO.ARM9-Core.
URL: http: // www. emtrion. de/ hicoarm9_ core_ en. php
Engelen, S. (2012). CubeSat course presentation on Spacecraft Mechatronics.
URL: http: // www. youtube. com/ watch? v= mKZ4TFmXf3M
ESA (2012). ESA declares end of mission for Envisat.
URL:
html
http: // www. esa. int/ SPECIALS/ Envisat/ SEM1SXSWT1H_ 0.
REFERENCES
63
Fitzsimmons, S. (2012). Reliable Software Updates for On-orbit CubeSat
Satellites. Master’s thesis, California Polytechnic State University, San
Luis Obispo.
Flagg, S., Bleier, T., Dunson, C., Doering, J., DeMartini, L.,
Clarke, P., Franklin, L., Seelbach, D.J., Flagg, J., Klenk, M.,
and Safradin, V. (2004). Using Nanosats as a Proof of Concept for
Space Science Missions: QuakeSat as an Operational Example. In 18th
AIAA/USU Conference on Small Satellites. SCC04-XI-4. August 2004.
Gilmore, D.G. (2002). Spacecraft Thermal Control Handbook - Volume
I: Fundamental Technologies.
Hasenstab, M. (2012). Centipad.
URL: http: // www. harerod. de/ centipad/ index_ english. html
ISSI (2011). IS42S16160D.
URL: www. issi. com/ pdf/ 42-45S83200D-16160D. pdf
Janhunen, P. (2010). Electrostatic Plasma Brake for Deorbiting a Satellite. Propulsion and Power 2010, 26:370–372.
Kanpur, I. (2008). Jugnu.
URL: http: // www. iitk. ac. in/ me/ jugnu/ index. htm
Kief, C.J., Christensen, J., Hansen, B., and Mee, J. (2010). CubeFlow: Training for a New Space Community. In AIAA/Infotech@Aerospace
Conference.
LaBel, K.A., Gates, M.M., and Moran, A.K. (2011). Commercial
Microelectronics Technologies for Applications in the Satellite Radiation
Environment.
URL:
http: // radhome. gsfc. nasa. gov/ radhome/ papers/ aspen.
htm
Linear, T. (2002). LTC3406-1.8.
URL: http: // cds. linear. com/ docs/ Datasheet/ 3406fa. pdf
Manchester, Z. (2011). KickSat.
URL:
http: // www. kickstarter. com/ projects/ 251588730/
kicksat-your-personal-spacecraft-in-space
REFERENCES
64
Modrzewski, R. (2011). A1-OBH-DD-01-v2 Preliminary Design of On
Board Computer Hardware.
Moore, R.C. and Pisacane, V.L., editors (1994). Fundamentals of
Space Systems. Oxford University.
Näsilä, A., Hakkarainen, A., Praks, J., Kestilä, A., Nordling,
K., Modrzewski, R., Saari, H., Antila, J., Mannila, R., Janhunen, P., Vainio, R., and Hallikainen, M., editors (2011a). Aalto-1
- A Hyperspectral Earth Observing Nanosatellite.
Näsilä, A., Kestilä, A., Hakkarainen, A., , and Komu, M.
(2011b). A1-SYS-EID-01-v4 Experiment Interface Document.
National-Instruments (2012). Understanding LVDS for Digital Test
Systems.
URL: http: // www. ni. com/ white-paper/ 4441/ en
Nikkanen, T. (2010). Nanosatelliitin Energiajärjestelmä. Master’s thesis,
School of Science and Technology, Aalto University.
Oklahoma, U. (2009). Stress.
URL: http: // weather. ou. edu/ ~apw/ projects/ stress/
OpenCircuits (2011). Linuxstamp.
URL: http: // www. thelinuxstamp. com/
OpenGroup (2004a). Fork.
URL:
http: // pubs. opengroup. org/ onlinepubs/ 009604599/
functions/ fork. html
OpenGroup (2004b). Free.
URL:
http: // pubs. opengroup. org/ onlinepubs/ 009695399/
functions/ free. html
OpenGroup (2004c). Malloc.
URL:
http: // pubs. opengroup. org/ onlinepubs/ 009695399/
functions/ malloc. html
OpenGroup (2004d). Mkstemp.
URL:
http: // pubs. opengroup. org/ onlinepubs/ 009695399/
functions/ mkstemp. html
REFERENCES
65
OpenGroup (2004e). Pwrite.
URL:
http: // pubs. opengroup. org/ onlinepubs/ 007904975/
functions/ write. html
Praks, J., Kestilä, A., Hallikainen, M., Saari, H., Antila, J.,
Janhunen, P., and Vainio, R. (2011).
Aalto-1 - An experimental
nanosatellite for hyperspectral remote sensing. In Geoscience and Remote
Sensing Symposium (IGARSS), 2011 IEEE International.
Ribeiro, F. (2005). Open ARM9 SBC.
URL: http: // www. lps. usp. br/ ~fr/ sbc/
Semiconductors, P. (2000). The I2C-bus specification.
URL: http: // www. cs. unc. edu/ Research/ stc/ FAQs/ Interfaces/
I2C-BusSpec-V2. 1. pdf
STUDSAT, T. (2010). STUDSAT.
URL: http: // www. teamstudsat. com/ index-2. html
Texas, I. (2006). TPS3306-18.
URL: http: // www. ti. com/ product/ tps3306-18
Texas, I. (2009). TMS320x281x Serial Peripheral Interface.
URL: http: // www. ti. com/ lit/ ug/ spru059e/ spru059e. pdf
Toorian, A., Coelho, R., Lee, S., and Coelho, R. (2004). DNEPR
Safety Compliance Requirements (DSCR)Version 1.0.
URL:
http: // edge. rit. edu/ content/ P07102/ public/ Testing%
20Requirements% 20from% 20Cubesat% 20Community
Tribble, A.C., editor (1995). The Space Environment: Implications for
Spacecraft Design. Princeton, NJ: Princeton UP.
Tyvak (2012). Tyvak.
URL: http: // www. tyvak. com/ products/ products. html
Wertz, J.R. and Larson, W.J., editors (1999). Space Mission Analysis
and Design. Space Technology Library, 3rd edition.
Wikipedia (2012). Radiation hardening. [Online; accessed 19-August2012].
URL: http: // en. wikipedia. org/ wiki/ Radiation_ hardening
REFERENCES
66
Xilinx (2008). Xilinx Single-Event Upset Mitigation Selection Guide.
URL:
http: // www. xilinx. com/ support/ documentation/
application_ notes/ xapp987. pdf
Yanes, A. (2011). A1-OBS-DD-01-v2 Preliminary Design of On-board
Computer Software.
Yashiro, H. and Fujiwara, T. (2002). A high assurance on-line recovery technology for a Space On-board Computer. In The 5th International
Symposium on Autonomous Decentralized Systems, pages 47–56.