A Comparative Analysis of Project Management

and Systems Engineering Techniques in CubeSat

Projects

Joost Elstak

July 5, 2007
ii
Preface

With the arrival of the CubeSat standard in the year 2000 the skies opened up for university satellite projects. This
standard allowed fast and affordable development of space systems. Both Delft University of Technology (DUT)
and Aalborg University (AAU) use this standards to develop university satellites. Working in one of these uni-
versity CubeSat projects is a challenging and enriching experience that gives students the skills and experience
needed during the rest of their professional career. I have had the pleasure of working in these two widely different
CubeSat projects during my thesis year. This report gives an overview of this work that was performed from April
2006 to July 2007. Since I have been involved in two different projects and many different activities within these
projects this thesis has been a real challenge to write.

The complete thesis work comprises of three elements that are bundled in the documents handed in: First of
all there is the body of this report that contains an elaborate introduction to both projects and a journal containing
the analysis of the Project Management and Systems Engineering (PMSE) activities within each project (Chapters
1 through 3). This part of the report can be seen as the cover letter of the work that has been done in the past
year on both projects. The second part of the work done can be found in the appendices. This appendix contains
the documentation related to the verification process of the InterConnect Boards (ICBs) and the Modular Antenna
Boxes (MABs) and represents the technical work done on the Delfi-C3 project. The final part of the thesis work
is the work done in Denmark on AAUSAT-II. Since this has been summarized in a separate report and examined
in Denmark this work is not an explicit part of this report. For the sake of completeness, however, the report is
handed in separately with this report.

It is often said that for each kilogram of actual satellite 100 kg of documentation is needed. Since this report
weighs in at around 0.5 kg that would mean it represents 5 grams of satellite. Be that as it may, this report rep-
resents much more to me. It represents more than a year of work in the Netherlands, France and Denmark. It
represents work done in two different teams and project environments. But most of all it is the milestone that I
have reached at the end of my education in Delft.

Throughout the year I have been supported by several persons that I would like to thank for their efforts. For
supervising me and entrusting me with the freedom and responsibility to perform part of my thesis abroad I would
like to thank Rob Hamann and Jens Nielsen. For their objective reviews of my work and support during my project
work I would like to thank Abe Bonnema and Rouzbeh Amini. Furthermore I would like to thank Geert Brouwer
and Dirk Fruijtier for all the invaluable things I learned about practical space systems engineering that are impos-
sible to put down on paper. A final word of thanks goes to the student teams of Delfi-C3 and AAUSAT-II. What
happens in the workshops of these project teams is in many ways not short of magic.

Joost Elstak
Delft, July 5, 2007
iv
Summary

Since the start of CubeSat development different universities and organisations have succeeded in launching and
operating their own satellites. Each of these institutes has their own way in which these projects are organised.
Furthermore each project has its own design philosophy and heritage that influence the project. What all these
projects do share is a common set of standard CubeSat requirements and similar handbooks on PMSE. Further-
more the general development time and workforce behind the project are also similar for all institutes. With this
in mind it is interesting to see that the resulting projects and CubeSats differ greatly.

The objective of this thesis is to evaluate the PMSE techniques and methods within CubeSat projects. Further-
more the driving factors that influence the projects, for better or for worse, will be identified. The subjects of the
analysis will be two CubeSat projects: Delfi-C3 and AAUSAT-II. Both of these projects are in the final stages of
their Assembly, Integration and Verification (AIV) and will be launched in the second half of 2007 or early 2008.
The satellite projects of DUT and AAU will use as reference points for this evaluation. These widely different
projects make for interesting references of such an analysis. AAU has a strong pragmatic approach, while DUT
uses a structured industrial standard approach.

Student CubeSat projects are a challenge in many ways. These projects are characterised by short development
time and complexity of both the project and the satellite. Multidisciplinary teams are of key importance in getting
the job done. Complexity is the key variable in defining the PMSE approach within the structure. With increas-
ing interactions and interfaces between the different (sub)systems the complexity increases exponentially. With
increasing complexity the need for PMSE increases. The Delfi-C3 project is a more complex and hence there is
more need for PMSE. Furthermore the educational background of the students is filled with PMSE courses and
projects. Within the AAUSAT-II project PMSE is used, but in a more implicit way.

The great challenge in PMSE control is that some subjects that are dealt with are unpredictable by nature. Things
like schedules and project teams can not be modeled and are subject to change. The ideal case scenario can always
be put on paper, but does not incorporate the troubleshooting and ’educational’ errors that are so characteristic for
student satellite projects.

In the end good PMSE has two functions within the project. In the early phases it helps to develop the best
satellite that matches the functions desired for the system. Later on it helps structure the design and build of the
satellite. So in the end good PMSE contributes to the best satellite and the best way to build it. Good PMSE
structures and coordinates the project but also needs a good structure in its own setup in order to be successful.
vi
Contents

Preface iii

Summary v

Acronyms xiii

1 Introduction 1
1.1 Thesis Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Delfi-C3 Project Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3 AAUSAT-II project Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4 Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Project Background Information 3

2.1 AAUSAT-II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1.1 The AAUSAT-II Satellite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Delfi-C3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.1 The Delfi-C3 satellite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3 Launch and Orbit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3 PMSE in CubeSat projects 13

Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2.1 The CubeSat Standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2.2 Project Management and Systems Engineering in CubeSat projects . . . . . . . . . . . . 15
3.2.3 The AAUSAT-II and Delfi-C3 satellite . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2.4 Comparing CubeSat Technical Complexities . . . . . . . . . . . . . . . . . . . . . . . . 16
3.3 CubeSat Project Teams and Organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.3.1 CubeSat Team Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.4 CubeSat Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.4.1 Conclusions on CubeSat Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.5 CubeSat Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.5.1 Model Philosophy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.5.2 Conclusions on CubeSat Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.6 Managing CubeSat Complexity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.6.1 Phasing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.6.2 Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
 3.6.3 Information Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.6.4 Requirements Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.6.5 Interface Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.7 Conclusions and Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

A Thesis Plan 33

B PMSE Setup in Delfi-C3 and AAUSAT-II 37

B.1 PMSE in the Delfi-C3 Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
B.2 PMSE in the AAUSAT-II project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

C MAIV Lessons Learned 43

C.1 MAIV Lessons Learned from the Delfi-C3 Project . . . . . . . . . . . . . . . . . . . . . . . . . . 44
C.1.1 Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
C.1.2 MAIV Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
C.1.3 Information Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
C.1.4 The MAIV playing field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
C.2 Lessons Learned from the AAUSAT-II Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
C.2.1 Project Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
C.2.2 Assembly and Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
C.2.3 Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

D SPFC2006 Conclusions Report Summary 51

E Delfi-C3 Verification Activities 53

E.1 InterConnect Board Testplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
E.2 InterConnect Board Test Result Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
E.3 Deployment system verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
E.4 Overview of Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
E.4.1 Verification Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
E.4.2 ICB Troubleshooting Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
E.5 Deploy Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

viii
List of Figures

2.1 The AAUSAT-II satellite and its subsystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.2 AAUSAT-II Engineering Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3 Satellite modes of AAUSAT-II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4 Delfi-C3 external and internal configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.5 Delfi-C3 in the assembly jig at Dutch Space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.6 Overview of the different modes of the Delfi-C3 satellite . . . . . . . . . . . . . . . . . . . . . . 10
2.7 The PSLV Launch Vehicle and the X-POD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.1 CubeSat lifecycle used in this paper compared to ESA lifecycle . . . . . . . . . . . . . . . . . . . 14

3.2 The gray area between project management and systems engineering [5] . . . . . . . . . . . . . . 15
3.3 The AAUSAT-II satellite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.4 Delfi-C3 external and internal configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.5 The project organisation within the AAU CubeSat education . . . . . . . . . . . . . . . . . . . . 19
3.6 Proposed CubeSat phasing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.7 Project schedules of AAUSAT-II (top) and Delfi-C3 (bottom) at three point in the lifecycle . . . . 28
3.8 Wiki structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

B.1 The Vee-model together with the systems engineer definition for Delfi-C3 [5] . . . . . . . . . . . 39
B.2 The project organisation within the CubeSat projects of AAU . . . . . . . . . . . . . . . . . . . . 41
x
List of Tables

3.1 AAUSAT-II and Delfi-C3 Technical Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.2 AAUSAT-II and Delfi-C3 Project Teams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.3 AAUSAT-II and Delfi-C3 Project Organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.4 AAUSAT-II and Delfi-C3 Design Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.5 AAUSAT-II and Delfi-C3 Integration Characteristics . . . . . . . . . . . . . . . . . . . . . . . . 24
3.6 CubeSat Model Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.7 AAUSAT-II and Delfi-C3 Information Management Characteristics . . . . . . . . . . . . . . . . . 29

B.1 Systems Engineer Definition for Delfi-C3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

E.1 Verification Activities Performed on Delfi-C3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

E.2 Verification Activities on ICBZ-001 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
E.3 Verification Activities on ICBZ-002 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
E.4 Verification Activities on ICBZ-003 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
E.5 Verification Activities on ICBZ+001 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
E.6 Verification Activities on ICBZ+002 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
xii
Acronyms
AAU Aalborg University
ADCS Attitude Determination and Control System
AE Aerospace Engineering
AIV Assembly, Integration and Verification
AWSS Autonomous Wireless Sun Sensor
CAD Computer Aided Design
CAN Controller Area Network
CDH Command and Data Handling subsystem
CDHS Command and Data Handling Subsystem
COM Communication subsystem
ComBo Combination Board
COTS Commercial Of The Shelf
CVS Concurrent Versions System
DNSC Danish National Space Center
DoD Department of Defence
DUT Delft University of Technology
EEMCS Electrical Engineering, Mathematics and OBM OnBoard Moron
Computer Science
EM Engineering Model
EPS Electrical Power Supply subsystem
ESA European Space Agency
FM Flight Model
FSM Flight Spare Model
GND GrouND Station
HSN Hardcore Satellite Network
HW hardware
IAC International Astronautical Congress
ICB InterConnect Board
ICBs InterConnect Boards
ISR Interrupt Service Routine
KISS Keep It Simple Stupid
MAB Modular Antenna Box
MABs Modular Antenna Boxes
MAIV Manufacturing, Assembly, Integration and Ver-
ification
MCC Mission Control Center
MeBo Measurement Board
MECH MECHanical subsystem
NASA National Aeronautics and Space Administration
OBC OnBoard Computer subsystem
P/L PayLoad subsystem
PBL Problem Based Learning
PCB Printed Circuit Board
PCBs Printed Circuit Boards
PIC Peripheral Interrupt Controller
PICs Peripheral Interrupt Controllers
PMSE Project Management and Systems Engineering SSETI Student Space Exploration and Technology Ini-
tiative
P-POD Poly Picosatellite Orbital Deployer
PSLV Polar Satellite Launch vehicle TFSC Thin Film Solar Cells

RAP Radio Amateur Platform TNO ’Nederlandse Organisatie voor toegepast-

natuurwetenschappelijk onderzoek’
RoBo Rod Board
TPM Technical Performance Measure
SPFC2006 Student Parabolic Flight Campaign 2006
SW software TPMs Technical Performance Measures

SOWs Statements Of Work XPOD eXperimental Picosatellite Orbital Deployer

xiv
Chapter 1
Introduction

Since the start of CubeSat development different universities and organisations have succeeded in launching and
operating their own satellites. Each of these institutes has their own ways in which these projects are organised.
Furthermore each project has its own design philosophy and heritage that influence the project. What all these
projects do share is a common set of standard CubeSat requirements [25] and similar handbooks on Project Man-
agement and Systems Engineering (PMSE). Furthermore the general development time and workforce behind the
project are also similar for all institutes. With this in mind it is interesting to see that the resulting projects and
CubeSats differ greatly.

1.1 Thesis Objectives

The objective of this thesis is to evaluate the PMSE techniques and methods within CubeSat projects. Further-
more the driving factors that influence the projects, for better or for worse, will be identified. The subjects of
the analysis will be two CubeSat projects: Delfi-C3 and AAUSAT-II. Both of these projects are in the final stages
of their Assembly, Integration and Verification (AIV) and will be launched in the second half of 2007 or early 2008.

The reason why these projects have been chosen is the fact that the author has been involved in both projects
for a semester. The comparison is therefore more than a ’paper’ comparison and will look at the actual imple-
mentation of PMSE in both the projects. Since analysis of other projects would be restricted to a purely ’paper’
analysis they are omitted from this analysis. The fact that most CubeSat documents and theses deal with project
design and development makes this document, that reflects on the work done, unique.

1.2 Delfi-C3 Project Activities

During the thesis year the author has been involved in both projects for a semester. For the Delfi-C3 project the
author has been involved in two different activities: the Student Parabolic Flight Campaign 2006 (SPFC2006) and
the verification of the InterConnect Boards (ICBs).

From April to July 2006 the author has been team leader of the Delfi-C3 SPFC2006 team. During the SPFC2006
the antenna deployment system of the Delfi-C3 was tested in zero-g. The objective of the flight was to verify
the functionality of the Modular Antenna Boxes (MABs) that were to be used on the Delfi-C3 . These MABs
are small modular antenna deployment systems that are used to contain and deploy the flexible antennas of the
Delfi-C3 satellite. In the course of developing the experiment and during the flight itself several critical items were
identified that reduced the deployment performance of the system. These items led to a redesign of the MABs.
Details on the SPFC2006 can be found in [8], an abstract of the report can be found in appendix D.
From February 2007 to June 2007 the author has been responsible for the verification process of the ICBs of
the Delfi-C3 . During this period the author was responsible for the timely delivery of these subsystems for stack
integration and integrated testing. This has been a challenging assignment since the ICBs were the first board to
undergo full verification. This meant that the tests and their documentation still had to be defined at the start of the
project. The documentation on the verification process can be found in Appendix E.1. Also the test results report
is added in Appendix E.2. It must however be noted that both of these files are templates. The documents that
were used on a daily base for the verification of the ICBs are the logbooks of each board and the corresponding
archiver (ICBZ+: [9]; ICBZ-: [10]). For an up to date status on the ICBs these documents should be consulted.

1.3 AAUSAT-II project Activities

From September 2006 to January 2007 the author worked at the Aalborg University on AAUSAT-II. For the
AAUSAT-II project there was a need for baseline planning and AIV definition and supervision. All of this had
to be done in the flexible framework of a CubeSat project. These objectives were fulfilled in the course of this
project:
• Defining and supervising AAUSAT-II baseline until launch
• Defining and supervising a tailor-made AIV process for AAUSAT-II
• Ensuring AIV up to date status availability
Furthermore mechanical redesign and rework was done on the satellite. The semester in Aalborg was finished
with a project report and defense. This report has been handed in as reference together with this thesis report.

1.4 Structure
This document is structured around the paper that is the core of this thesis. In this paper the different PMSE tech-
niques and methods used in CubeSat projects are evaluated. Extra information is added around this core and in
the appendices in order to present a complete independent document for readers with basic knowledge of CubeSat
projects. Basic project information is taken from existing documents and adapted to the current satellite status,
thus presenting an up to date picture of the satellites without having to reinvent the wheel.

The structure of the document is as follows: Chapter 2 gives a basic overview of the projects and project teams
of Delfi-C3 and AAUSAT-II. In combination with this introduction they are the general introduction to the paper.
Subsequently chapter 3 contains the paper in which the PMSE analysis of the two projects is presented. The
Appendices provide extra information and are split up. Appendix B contains an overview of the way in which the
PMSE is organised within both projects. Appendix C presents the ‘Lessons Learned’ from both projects. These
lessons learned are used in the PMSE analysis. Appendix D contains the abstract of the SPFC2006 result report.
Appendix E contains the different documents created for the verification of the ICBs for the Delfi-C3 project. For
a complete overview of the verification activities the logbooks should be consulted. The final report for Aalborg
University (AAU) has been handed in as a stand-alone report for the exam committee together with this report. It
must be noted that this document is already a summary of the activities in Denmark.

2
Chapter 2
Project Background Information

This chapter gives a short overview of the AAUSAT-II and Delfi-C3 projects and satellites. This is done to ensure
that all readers start reading the paper with basic knowledge of both projects.

2.1 AAUSAT-II
The AAUSAT-II project was initiated in the summer of 2003 at the AAU. The departments that were involved in
the development were:
• The Department of Control Engineering
• The Institute of Electronic Systems
• The Institute of Mechanical Engineering
• The Institute of Computer Science
Next to AAU also Copenhagen University College of Engineering was involved in the development. AAUSAT-II
is the follow-up of the first CubeSat developed at AAU: AAU CubeSat 1 . Furthermore AAU has been heav-
ily involved in the Student Space Exploration and Technology Initiative (SSETI) Express mission 2 during the
AAUSAT-II project.

AAUSAT-II’s primary goal is education. The primary mission of the project is the education of students in the
complicated process of building a complex system like a satellite. Next to this AAUSAT-II also has technical
goals:
• Establish one-way communication
• Establish two-way communication
• Perform science experiment 1: Attitude Determination and Control System (ADCS) system
• Perform science experiment 2: Gamma ray detector

2.1.1 The AAUSAT-II Satellite

AAUSAT-II is based on a single cube. It’s mass lies well below 1 kg (650 grams). Every part of the satellite has
been designed at the university, even complicated parts like the structure and the OnBoard Computer subsystem
(OBC). The satellite uses up to 2 Watts of power, depending on which subsystem is switched on. The primary
1 http://www.cubesat.auc.dk/
2 http://www.express.space.aau.dk/
goal for the ADCS system is to detumble the satellite, but it can also actively control of the satellites attitude in
space, utilizing coils and momentum wheels. The gamma ray detector is made by the Danish National Space
Center (DNSC) and it will detect gamma ray bursts from outer space. Figure 2.1 shows the AAUSAT-II and its
subsystems. Figure 2.2 show the Engineering Model (EM) of the satellite.

Figure 2.1: The AAUSAT-II satellite and its subsystems

Figure 2.2: AAUSAT-II Engineering Model

Subsystem Overview
Mission Control Center Mission Control Center (MCC) is responsible for handling and storing all transmission
data from the satellite and sending flight plans etc. to the satellite. The MCC provides a user interface and a
database to store housekeeping data from the satellite. The mission control center is furthermore able to control
multiple ground stations, both the ground station located in Aalborg and a ground station placed at Svalbard in
Norway which is currently in the final stages of development.

Ground Station The GrouND Station (GND) is responsible for the communication between the MCC and the
satellite. The task of the ground station is to track the satellite throughout each pass and adjust the radio frequency,
so data between the satellite and the MCC can be sent and received correctly. Furthermore, the ground station is
designed to be autonomously controlled by the MCC, for communicating with the AAUSAT-II satellite.

COMmunication system The Communication subsystem (COM) is designed to function as a pipeline for the
communication between the ground station and the Command and Data Handling subsystem (CDH). COM mod-
ulates and sends data from CDH to the ground station. Data received from the ground station is demodulated and
sent via the Controller Area Network (CAN) bus to the CDH subsystem.

4
Electrical Power Supply The Electrical Power Supply subsystem (EPS) is responsible for generating power
from the solar cells and storing it in the batteries in order to be able to deliver continuous power during eclipse
and peak demands. The EPS subsystem also conditions and distributes the power to other satellite subsystems.

Attitude Determination and Control System The ADCS is responsible for determining and controlling the
attitude of the satellite. This primarily implies detumbling and stabilization of the satellite.

Payload PayLoad subsystem (P/L) consists of a gamma ray burst detector. The gamma ray burst detector is a
newly developed detector crystal supplied by DNSC.

On-Board Computer OBC is the main computer on the satellite. The CDH subsystem software is executed on
the OBC. The OBC subsystem also provides processing facilities for other satellite subsystems.

Command and Data Handling CDH is the subsystem that controls the operation of the satellite. CDH steers
the information flow within the satellite and is located in the OBC. CDH is the only subsystem that is purely
software.

MECHanical subsystem The mechanical subsystem was design build and tested at the mechanical department
of AAU. MECHanical subsystem (MECH) forms the load carrying structure of the satellite and comprises of the
satellite structure, sidepanels, and mounts for the stack and momentum wheels.

AAUSAT-II Modes
Four different modes of operation have been defined for the satellite. Each subsystem has different tasks to perform
within each mode. The four different modes each defines which subsystems are to be powered up and individual
actions for the subsystems. The modes are as follows:

Initialization mode
Systems powered up: EPS.
Actions: EPS checks if the antennas have been deployed and deploys them if they have not. Afterwards the satel-
lite changes to safe mode.

Safe mode
Systems powered up: EPS.
Actions: EPS charges the batteries in case of low battery voltage or conditions the batteries in case of extreme
temperatures etc.

Recovery mode
Systems powered up: EPS and COM.
Actions: COM sends a basic beacon including the current battery voltage to Earth and EPS checks if the battery
voltage is sufficient to advance to nominal mode.

Nominal mode
Systems powered up: EPS, COM, OBC/CDH, ADCS and P/L.
Actions: CDH is responsible for transmitting a nominal beacon through COM to Earth. Besides that CDH controls
the flight plan and instructs EPS to turn on or off ADCS and P/L.

Figure 2.3 shows diagrams that illustrate the relations between the different modes.

5
Figure 2.3: Satellite modes of AAUSAT-II

6
2.2 Delfi-C3
In November 2004 the Delfi-C3 project officially kicked off. Delfi-C3 would be the first Dutch student satellite
and the fourth Dutch satellite ever to be made. At that time the Delft University of Technology (DUT) and the
industrials Dutch Space and TNO Science & Industry agreed on the development of a nanosatellite that would fly
a payload for each of them. The internal and external configuration of the Delfi-C3 satellite can be seen in figure
2.4(a) and figure 2.4(b).

(a) (b)

Figure 2.4: Delfi-C3 external and internal configuration

The objectives of the Delfi-C3 mission are twofold. Firstly, the project serves an educational objective meaning
that it provides students with an opportunity to gain interdisciplinary hands-on engineering experience. Secondly,
the Delfi-C3 satellite serves as a technology demonstration platform which will demonstrate a number of new
techniques in-orbit:
• In-orbit performance test of a new type of Thin Film Solar Cells (TFSC) for Dutch Space by measuring
their IV-curves, temperature range and Sun incidence angles
• In-orbit functional and performance test of the autonomy of an analog Sun sensor which includes testing an
independent power supply and a wireless RF-interface
• First in-orbit demonstration of a Radio Amateur Platform (RAP) that uses a worldwide distributed ground
station network for collecting Delfi-C3 flight data. The platform can furthermore be used as transponder for
relaying radio messages from radio amateurs around the world.

2.2.1 The Delfi-C3 satellite

The body of the Delfi-C3 satellite is based on three CubeSats stacked on top of eachother. The general dimensions
are 34 x 10 x 10 cm and the weight is around 2.5 kg. Furthermore the satellite uses up to 3 Watts of power,
depending on the active subsystems. Delfi-C3 does not have any batteries on-board and there is no active attitude
control. Figure 2.5 shows the actual satellite body after assembly of the solar panels.

Subsystem Overview
This section presents an overview of the different subsystems of the Delfi-C3 satellite. The satellite roughly
consists of a stack of electrical subsystems, a body and the deployable solar panels and antennas.

7
 Figure 2.5: Delfi-C3 in the assembly jig at Dutch Space

InterConnect Boards The ICBs are the interface boards that are present at the top and bottom of the stack.
All external connectors (except the TFSC measurement wires) pass through this board into the satellite. By
implementing this board the stack remains modular and can easily be separated from the body. This can be done
with the stack intact and by only disconnecting the connectors on the ICB.

Measurement Boards The top and bottom side of the stack contains a Measurement Board (MeBo) right un-
derneath the InterConnect Board (ICB). This board is responsible for handling the measurement data of the TFSC
payload.

Combination Board Next to the OnBoard Computer the Combination Board (ComBo) board is located. The
ComBo has 2 functions within the satellite. First of all it is the interface between the OBC and the rest of the stack
and relays messages. Secondly it contains the reciever for the Autonomous Wireless Sun Sensor (AWSS) payload
and handles the data that is received from this payload.

OnBoard Computer FM430 The fourth board from the top is the OnBoard Computer. The OBC is the brain
of the satellite stack. It is responsible for the Command and Data Handling Subsystem (CDHS) activities of the
satellite.

Radio Amateur Platforms The satellite contains two Radio Amateur Platform (RAP) subsystems in the central
part of the stack. These subsystems function as communication systems between the Earth and the satellite. After
three months of science operations the RAPs will be switched to a radio amateur transponder mode in which they
will relay radio amateur data.

Rod Board In the middle of the stack the Rod Board (RoBo) is placed. The RoBo houses the passive attitude
control subsystem of the satellite. This subsystem consists of a permanent magnet and hysteresis rods that are
positioned in such a way that they keep the rotation of the satellite within the required specifications.

Electrical Power Subsystem In the stack the he Electrical Power Subsystem (EPS) is the third board from the
bottom. It is almost literally the heart of the satellite. The EPS is responsible for conditioning the power from the
solar panels so it can be used to power the satellite.

8
Solar Panels The satellite contains four deployable solar panels that contain, next to the conventional solar cells,
the TFSC payload cells at the end of each panel. Each panel will be stowed during launch and deployed using
a hinge with a spring. The panels will be deployed at a nominal angle of 35 degrees with respect to the satellite
body.

Body The body is an aluminium tube that has been modified to incorporate components for the release and
deploy mechanisms of the solar panels. On the top and bottom of the tube there are top and bottom panels that
connect the stack to the body, house the AWSS and the MABs. The body will be covered in thermal foil to get the
desired thermal properties.

Antennas The Delfi-C3 satellite has four uplink and four downlink antennas that are made of spring steel. The
antennas are rolled up and stowed inside MABs during launch. The downlink antennas are 45 cm and the uplink
are 13 cm. Once in orbit the antennas are deployed by burning the wire that holds the lid of the MAB closed,
hence opening the lid and releasing the antennas.

Delfi-C3 Modes
Delfi-C3 has different modes of operation. Each modes is tailored to optimize a certain operation of the satellite
and safety in case of a malfunction. There are two top level modes: OnBoard Computer Mode (OBC Mode) and
OnBoard Moron (OBM) Mode. The first mode is the nominal mode of operation in which the OBC controlls the
satellite. the OBM Mode is the backup mode used in case there is a computer failure. In this mode still basic
measurement data can be transmitted. This section will be focussed on the OBC Mode.

Boot Mode The boot mode performs a health check on the Peripheral Interrupt Controllers (PICs), loads the
function parameters from flash and writes to the boot counter. The satellite is started up in this mode.

Idle Mode In idle mode, the satellite does not perform any deployment or transmitting. This mode may be
necessary to comply to launch regulations. It can be used in case of a solar eclipse or can be set when the satellite
is disfunctional.

Science Mode In the science mode, the data of the payloads (TFSC and AWSS) is collected and sent down to
Earth. After a certain amount of payload frames, a housekeeping frame is sent down to monitor the satellite.

Basic Mode The basic mode functions as a troubleshooting/safe mode. It is called basic mode because only
housekeeping frames are sent down. The content of those frames can be altered by telecommand to eliminate
problems or isolate one.

Transponder Mode In the transponder mode, one of the RAP’s functions as a transponder for radio amateurs.
The rest of the satellite performs no tasks, so the OBC only sends housekeeping data.

Test (slave) Mode The test mode is not part of the main loop, but the OBC can be put in slave mode to do
specific measurements, memory dumps or parameter changes [6]. This mode is used for verification only.

Deployment Mode This is the mode in which all deployables, solar panels and antennas are deployed. The
OBC controls the burn sequence and detect which deployables have to be deployed.

Figure 2.6 shows the interaction between the different modes.

9
Figure 2.6: Overview of the different modes of the Delfi-C3 satellite

10
2.3 Launch and Orbit
Both Delfi-C3 and AAUSAT-II will be launched with an Indian Polar Satellite Launch vehicle (PSLV). This
rocket can be seen in figure 2.7(a). In orbit, an eXperimental Picosatellite Orbital Deployer (XPOD) will deploy
the satellite. This deployer has been developed by the university of Toronto and figure 2.7(b) shows the XPOD for
the Delfi-C3 satellite. The satellite will be deployed into a sunsynchronous orbit of around 630 km altitude with
98 degrees of inclination [18].

(a) (b)

Figure 2.7: The PSLV Launch Vehicle and the X-POD

11
12
Chapter 3
A Comparative Analysis of Project
Management and Systems Engineering
Techniques in CubeSat Projects

Joost Elstak (J.Elstak@DelfiC3.nl)

Faculty of Aerospace Engineering, Delft University of Technology

Abstract
In the year 2000 California Polytechnic State University and Stanford University issued a new standard
for small satellites: The CubeSat standard. This standard allowed universities to design, build, test and
operate affordable, small, satellites within a timespan of two to three years. Both Delft University of
Technology (DUT) and Aalborg University (AAU) have used the CubeSat standard to develop a student
satellite. In Delft the Delfi-C3 satellite was developed. In Aalborg AAUSAT-II was developed. This pa-
per evaluates the different techniques that are used in the Project Management and Systems Engineering
of CubeSats. The satellite projects of DUT and AAU, that are highly different in setup, will be used as
reference points for this evaluation. AAU has a strong pragmatic approach, while DUT uses a structured
industrial standard approach.

3.1 Introduction
In the year 2000 California Polytechnic State University and Stanford University issued a new standard for small
satellites: The CubeSat standard. This standard allowed universities to design, build, test and operate affordable,
small, satellites within a timespan of two to three years.

Both DUT and AAU have used the CubeSat standard to develop a student satellite. DUT has developed the
Delfi-C3 satellite and at AAU the AAU CubeSat and its successor, AAUSAT-II, were developed. Both Delfi-C3
and AAUSAT-II satellites are scheduled to launch with an Indian Polar Satellite Launch vehicle (PSLV) in late
2007 or early 2008. Besides the fact that both projects use the CubeSat standard they also operate in an educational
environment. Next to these similarities there are also differences between the two projects. Since each satellite has
its own specific mission objectives the size, configuration and complexity of each CubeSat differs. Furthermore
the ways in which the project has implemented Project Management and Systems Engineering (PMSE) differs as
each project tailors the different standards available to fit its own needs.

Project management is the discipline that deals with the technical and non-technical management of an entire
project. Systems engineering is the discipline that specializes in the technical management of the product itself,
in this case the satellite. An easy metaphor is used to compare the two: Project Management ensures that the
train runs in time. Systems engineering makes sure that the train runs at all. This paper will evaluate the PMSE
activities within these CubeSat projects and will identify the key drivers behind CubeSat successes and failures.
The Delfi-C3 and AAUSAT-II projects will function as reference projects for this evaluation. What is unique is
the fact that this paper will not focus on the theoretical design process of a satellite but rather will look back on
two projects and draw lessons learned from practice.

In space systems engineering the lifecycle of a satellite is often modeled according to the standards defined by
European Space Agency (ESA), National Aeronautics and Space Administration (NASA) or the Department of
Defence (DoD). These lifecycles are defined for ’conventional’ satellite projects. This paper uses a tailored ver-
sion of the ESA lifecycle [26] that is more representative for the phases in CubeSat projects. This version can be
seen in figure 3.1. The Kick-off phase is the start-up phase in which the project is set up and preliminary design is
started. The design phase is the phase in which the first full team of students start working on the satellite. After
the preliminary and detailed design the project makes a transition into the Manufacturing, Assembly, Integration
and Verification (MAIV) phase in which the satellite is produced and tested. After this the satellite is launched
and operated in the utilization phase. This paper will focus on treating the design and MAIV phases of the project
since these are the phases in which most student activities take place. Since the author has been involved in the
MAIV phase of both projects the biggest focus will lie on this phase.

Figure 3.1: CubeSat lifecycle used in this paper compared to ESA lifecycle

The next section will give some additional background information on the projects, some PMSE basics and present
a complexity comparison between the two projects. Section 3.3 will treat the CubeSat teams and project structures.
Section 3.4 will discuss the design phase of a CubeSat, followed by the integration phase treated in 3.5. Finally
section 3.6 will analyze some complexity issues surrounding CubeSat projects. In this section phasing, scheduling,
information management, requirement management, change control and interface control will be discussed.

3.2 Background
3.2.1 The CubeSat Standard
A standard CubeSat is a nanosatellite with dimensions of 10 × 10 × 10 centimeters, weighing no more than one
kilogram. Also a double (10 × 10 × 20 cm) and a triple (10 × 10 × 30 cm) version of the CubeSat exists. This new
standard literally opened the heavens for universities. It allowed them to build affordable student satellites that
perform scientific experiments within its framework. Because of the standardisation of the satellites, CubeSats
have a relatively short development time of around two to three years. This makes them suitable for projects

14
within university curricula. Hence universities use the satellite projects as learning environment for their students
who use the CubeSat as project environment. Furthermore, the standardisation allows the universities to design
their satellite project to their wishes. Where some universities choose to develop the entire satellite, others choose
to acquire a standard mechanical frame and OnBoard Computer subsystem (OBC) and focus on the development
of the rest of the electronics, shifting the focus of the project.

3.2.2 Project Management and Systems Engineering in CubeSat projects

Project Management and Systems Engineering are two disciplines used to control satellite projects. With the use
of these disciplines the CubeSat project is controlled and technically managed in order to come to a best designed,
best buildable, best operatable and most cost effective satellite with the optimal educational value. PMSE differs
from the conventional areas of spacecraft engineering in the fact that they are a ’horizontal’ disciplines that deals
with all the ’vertical’ disciplines like electrical design and structural design.

For both disciplines various definitions can be found. The definition of Project Management used in this pa-
per is:
"An individual with a diverse set of knowledge tools and skills, like management, leadership, technical, conflict
management and customer relationship, who is responsible for initiating, planning, executing and closing down a
project such that the customer needs and project requirements are satisfied.’ [14]

For systems engineering the following definition is used:

"Systems Engineering is an engineering discipline whose responsibility is creating and executing an interdisci-
plinary process to ensure that the customer and stakeholder’s needs are satisfied in a high quality, trustworthy,
cost efficient and schedule compliant manner throughout a system’s entire life cycle." [15]

Figure 3.2: The gray area between project management and systems engineering [5]

Even with this distinction there still is a ’gray’ area between the two disciplines. Figure 3.2 shows this area. This

15
figure shows that there is overlap between the two disciplines. Both disciplines are interrelated and that on a day-
to-day base the project manager and systems engineer keep in close contact with each other. Within each CubeSat
projects PMSE standards designed for ’regular’ space engineering projects are taken and tailored to the project
needs. In this way an attempt is made to optimize the PMSE utilization within the project. The philosophy behind
this tailoring is that these PMSE techniques are present to support the project and are not means by themselves.

3.2.3 The AAUSAT-II and Delfi-C3 satellite

This section gives a brief overview of the AAUSAT-II and Delfi-C3 satellite. Table 3.1 shows an overview of the
characteristics of the satellites. The next section deals with the complexities and characteristics of the two projects.

3.2.4 Comparing CubeSat Technical Complexities

Complexity is an abstract term that is hard to define exactly. There is no standard by which satellite projects can
be compared when it comes to complexity. Table 3.1 shows a comparison between the two projects. On the basis
of this table some things can be said about the complexity of both projects. Each project is complex its own ways.
AAU develops most things inhouse and builds a technically relatively simple satellite that focuses on electrical
challenges. DUT uses a variety of self developed and Commercial Of The Shelf (COTS) products and combines
these to a complex satellite. The fact that the COTS products are implemented also adds complexity since the
rest of the satellite needs to interface with these COTS products. The design is furthermore very robust, failure
proof and up to industry standards, which adds a lot of complexity to the system. For these reasons and the fact
that the Delfi-C3 project has more stakeholders that are actively taking part in the project the Delfi-C3 satellite is
considered to be more complex than the AAUSAT-II satellite.

Delfi-C3 and AAUSAT-II Characteristics

Mass
Dimensions
Power
Subsystems
Subsystem complexity
Complexity locations
Mechanical aspects
Electrical aspects
Thermal control
Attitude control
Robustness
Stakeholders
Development standards
AAUSAT-II Delfi-C3
650 grams 2500 grams
10x10x10 cm 10x10x34 cm
2 Watts 3 Watts
4 PCBs + MECH 9 PCBs + MECH
Student developed OBC COTS OBC
Large amounts of interfaces on PCBs Some interfaces on PCBs
Mostly electronical Spread throughout satellite design
Standard CubeSat design Triple CubeSat body
Mechanical design done at AAU Modified COTS body
Deployable antennas (2x) Deployable panels (4x) and antennas (8x)
CAN bus architecture I2C architecture
Batteries Battery free design
Passive thermal control Passive thermal control
Active ADCS: Passive ADCS:
Momentum wheels and coils Permanent magnet and hysteresis rods
Satellite modes Satellite modes
Single point failure free design
Mostly internally in AAU DUT, industry and government
Custom/university Industrial

Table 3.1: AAUSAT-II and Delfi-C3 Technical Comparison

AAUSAT-II

In the summer of 2003 the AAUSAT-II project was started at AAU. Figure 3.3 shows the layout of the satel-
lite. AAUSAT-II is the second CubeSat developed at AAU. As with most CubeSat projects the primary goal

16
of the AAUSAT-II project is education. The primary mission of the project is the education of students in the
complicated process of building a complex system like a satellite. Next to this AAUSAT-II also has technical
goals:

• Establish one-way communication

• Establish two-way communication
• Perform science experiment 1: Attitude Determination and Control System (ADCS) system
• Perform science experiment 2: Gamma ray detector

Figure 3.3: The AAUSAT-II satellite

So, next to obtaining contact with the satellite also two scientific experiments will be performed. The primary goal
for the ADCS system is to detumble the satellite, but it can also actively control the satellites attitude in space,
utilizing coils and momentum wheels. The system is developed at AAU. The gamma ray detector is made by the
Danish National Space Center (DNSC) and it will detect gamma ray bursts from outer space.

Delfi-C3

In November 2004 the Delfi-C3 project was started at DUT and the development of the satellite was started.
Figure 3.4(a) and 3.4(b) shows the satellite configuration and stack with the Printed Circuit Boards (PCBs). The
objectives of the Delfi-C3 mission are twofold. Firstly, the project serves an educational objective meaning that
it provides students with an opportunity to gain interdisciplinary hands-on engineering experience. Second, the
Delfi-C3 satellite serves as a technology demonstration platform which will demonstrate a number of new tech-
niques in-orbit [23]:

• In-orbit performance test of a new type of Thin Film Solar cells for Dutch Space by measuring their IV-
curves, temperature range and Sun incidence angles
• In-orbit functional and performance test of a Autonomous Wireless Sun Sensor (AWSS) developed by ’Ned-
erlandse Organisatie voor toegepast-natuurwetenschappelijk onderzoek’ (TNO). The tests include testing
the independent power supply and the wireless RF-interface.
• First in-orbit demonstration of a Radio Amateur Platform (RAP) that uses a worldwide distributed ground
station network of radio amateurs for collecting Delfi-C3 flight data. The platform can furthermore be used
as transponder for relaying radio messages from radio amateurs around the world.

Furthermore the design of the Electrical Power Supply subsystem (EPS) system , that has been developed by
SystematIC Design, will be tested in orbit. Delfi-C3 is the first satellite developed at DUT that will be launched
and operated. There is, however, heritage from previous studies into satellite mission that never flew like the
Delfi-1 project [4].

17
 (a) (b)

Figure 3.4: Delfi-C3 external and internal configuration

3.3 CubeSat Project Teams and Organisation

Project teams are the cornerstone of any project. It is this team that eventually makes the magic happen and there-
fore it is important to find out what competences a team of student satellite engineers should posses. Furthermore
the way in which the CubeSat projects are positioned in the curriculum, the university and the industry is key to
understanding why things are done in certain ways. Where the CubeSat standard forms the technical boundary
for the satellite itself the CubeSat project team and their organisation form the boundary for the CubeSat project.
Due to the different setup of the projects the project teams differ as size, experience, qualities, availability and
involvement of the teams varies greatly.

CubeSat project teams have to deal with a great many different disciplines that are present in every project. There-
fore the team should have a good mix of a variety of competences. Crudely said the group should be dividable in
three subgroups: Mechanical, Electrical and PMSE. The mechanical group is responsible for the correct design of
the physical satellite and its mechanisms. The electrical group is responsible for the functionality of the satellite,
they are responsible for the PCBs. The PMSE group is responsible for the project overhead and interfaces. They
define what the satellite should do and ensure that the requirements are met throughout the development. The
division presented here is obviously not a very strict one and overlap between the disciplines is present. This
division does however shed some light on the way in which the AAUSAT-II and Delfi-C3 project are organised.
Tables 3.2 and 3.3 show the characteristics of the project teams and the project organisation respectively.

AAUSAT-II Team and Organisation

The AAUSAT-II project is a collaboration between four departments of the AAU and one department of the
Copenhagen University College of Engineering. The department of control engineering houses most of the satel-
lite activities.

The project is coordinated by a steering committee (figure 3.5) that consists of staff, AAU CubeSat veterans
and a student from every subsystem group [3]. This committee oversees the development of AAUSAT-II during
weekly meetings in which the progress of the project is discussed with representatives from all subsystem groups.
This has as advantage that all students are involved and up to date about the progress of the entire satellite. The
form in which the CubeSat education is given is Problem Based Learning (PBL). This is the way in which all
work is done at AAU. Students work in small groups on a single assignment for a semester. AAUSAT-II is also

18
 Delfi-C3 and AAUSAT-II Project Teams
Item AAUSAT-II Delfi-C3
Students >80 students from semester 3 to 10 >30 MSc students, >35 BEng students
Students in project groups Student have individual assignments for
their thesis or internship
Staff tasks Project leaders (financial) Project leaders (financial)
Project Manager Internship and thesis supervisors
Systems Engineers Actively involved in project PMSE
Project group supervisors Actively involved in HW/SW development
Project Advisors
Not active project members
Workforce flowthrough Small core team of students partici- Dedicated teams for design and integration
pate every semester phase
Large group of students participates Handover in mid-project
during 1 semester
Stable amount of student available Fluctuating amount of students involved
during design
Workforce availability Design: Fulltime Fulltime
MAIV: Voluntary base
Workforce competences Strong teamworking skills Strong PMSE skills
Strong electrical engineering skills Strong mechanical engineering skills
Practical space engineering knowledge and
skills through staff

Table 3.2: AAUSAT-II and Delfi-C3 Project Teams

split up into assignments that fit the curricula of the different departments. Student groups work on the project for
a semester. The education at AAU is very pragmatic in nature and the assignments reflect this as well, since they
often deal with real hardware. Students can be involved in the satellite project from the third semester, although
the bulk of the work is done in the 5th to 10th semesters.

Figure 3.5: The project organisation within the AAU CubeSat education

One staff member functions as project leader and manager and coordinates the project, other staff members func-
tion as group supervisors and advisers. The staff however does not participate in the project and remains in the role
of advisers. The project is ran purely by students and the role of project manager is not uniquely defined within
the project. Each group appoints a team leader that is responsible for the internal communication with the other
teams. As a result of the PBL students are very good at teamwork. Furthermore the fact that the projects are very
pragmatic in combination with the theoretical contents of the courses makes the students highly multidisciplinary

19
 Delfi-C3 and AAUSAT-II Project Organisation
Item AAUSAT-II Delfi-C3
PMSE Implicit part of project Explicit part of project
No top level definition Top level defined and flowdown
No philosophy Defined by students in collaboration with
staff
Electrical Engineering Project focal point, done purely by students Done by students with staff assistance
Mechanical Engineering All HW designed and build by students Done by students with staff assistance
Facilities Clean Room Clean Room
Workshop Workshop
Project rooms Project rooms
PCB population facility PCB population facility
Ground station Ground station
Management Part of steering group Dedicated project manager
No dedicated project hours Dedicated hours
Partners One partner: Multiple partners:
- Supplied payload - Usage of facilities
- Assisted in solar panel laydown - Supplied payloads
- Supplied expertice
- Dedicated workforce hours
Non-student activities Solar panel laydown Solar panel laydown
PCB production PCB design, production and population
HW production HW production

Table 3.3: AAUSAT-II and Delfi-C3 Project Organisation

and independent. Students take it upon themselves to learn certain skills, like designing and populating PCBs or
computing orbital mechanics, for the project.

The AAUSAT-II project is almost completely developed at AAU itself. Only the payload, a gamma-ray burst
detector for the DNSC, and the EPS design were delivered by an external source. This means that AAU has most
of the knowledge it needs in-house and that they are almost independent of others. However they are missing
knowledge when it comes to the use of standards and PMSE in space engineering. The cause of this is that the
education more focused on the electronics students are educated to be control engineers.

A major difference between the two projects is the fact that the AAUSAT-II project is the second CubeSat de-
veloped at AAU. It’s predecessor, AAU CubeSat [2], flew on the first CubeSat mission in 2003. Next to AAU
CubeSat the university was also one of the driving forces behind the Student Space Exploration and Technology
Initiative (SSETI) Express project [1]. Each of these projects has contributed to the knowledge and ’know-how’ in
space engineering. Furthermore from both projects important recommendations were done for successors [2] [22].

Delfi-C3 Team and Organisation

The Delfi-C3 project is ran by the faculties of Aerospace Engineering (AE) and Electrical Engineering, Math-
ematics and Computer Science (EEMCS) of the DUT. The project is done in close collaboration with Dutch Space
and the TNO, who both fly a payload on the satellite.

The Delfi-C3 project is set up as graduate project. Students are involved in the project for their MSc thesis for
about a year. The assignment is defined in by the student, his supervisor and the Delfi-C3 team. Next to these stu-
dents the team also consists of BEng and international students from technical colleges who perform an internship
or find a thesis assignment on the project. This means that there is a great diversity within the team. Within the

20
project there is a split up between different disciplines. Specific people are responsible for the software, hardware,
systems engineering, project management, verification etc. There obviously is an overlap between these areas but
there is more distinction between the different engineering disciplines used to design the satellite than is present in
the AAUSAT-II project. This does not mean that the students are not multidisciplinary, but illustrates the fact that
they are used in a less broad field than is the case within AAUSAT-II. This results from the fact that the Delfi-C3
project is more complex than the AAUSAT-II project.

Next to their role as advisers and tutors both the staff members and the industry partners actively take part in
the project and have dedicated hours on the project. There is a clear structure in the project in which the role of
project manager and systems engineer are given to specific persons. The whole project is structured and ran as
an industry standard space project. This is a result of the fact that the industry has stakes in the project. This
professionalism makes the project a very good preparation to working in the space industry. Furthermore the staff
members, who are mostly veteran space engineers, have a large amount of practical knowledge about satellite en-
gineering that is invaluable in deciding how to design the satellite right and tackle problems during the integration
and testing.

3.3.1 CubeSat Team Conclusions

Every CubeSat project has its own focus during the development time and this is exactly what the CubeSat stan-
dard is developed for. It is, however, important to remember that a satellite can not be build without people
skilled in PMSE, electrical engineering and hardware engineering. With increasing project size and complexity
the number of people in each group will grow. This results in more subsystems, interfaces etc. in the system. This
will than lead to an even bigger need for PMSE. So a project team should have all three groups represented, of
these groups the representation of the PMSE group should represent the complexity of the project and the division
between the mechanical and electrical work indicates where the remainder of the focus of the project lies. Having
experienced satellite engineers adds a practical and valuable learning dimension to the project. Furthermore it is
very important to maintain continuity in the project by keeping the amount of students working on the project
more or less constant. Manpower is the most scarce resource in a CubeSat project.

AAUSAT-II has focused most effort on the electrical part of the project. The mechanical work was done by
two students of the mechanical department and was delivered according to schedule. The PMSE part was done,
but a top level PMSE definition and space engineering standards were lacking. The main focus within the project
was on getting a working stack inside of the satellite.

The Delfi-C3 project has a strong focus on the PMSE. This is done since the education is focused on this and
the fact that the complexity of the satellite forces more PMSE into the project in order to keep the overview within
the project. Practical electronical knowledge is lacking in the project since relatively few students from Electrical
Engineering, Mathematics and Computer Science (EEMCS) actually take part in the project. This means that he
Aerospace Engineering (AE) students do a lot of the electrical work under supervision of EEMCS staff.

3.4 CubeSat Design

During the design phase the satellite project is defined to a component level after which production, integration
and verification starts. A solid definition of the design and the PMSE procedures is the base of every properly
defined project. However it must be accepted that certain errors can only be found in integration and not all prob-
lems can be mitigated in paper design. Table 3.5 shows an overview of the characteristics for the design process
of both projects.

Designing AAUSAT-II

21
 Delfi-C3 and AAUSAT-II Design Characteristics
Item AAUSAT-II Delfi-C3
Assignments Project groups Individual assignments
Design approach Integrated, each assignment: HW/SW Specific assignments: HW or SW
Design characteristics Practical satellite engineering The process of building a satellite
Focus on working HW Focus on ’paper’ design
Early prototypes Detailed definition of functions, require-
ments, trade-offs and procedures
KISS design KISS design
Modular design Modular design
Inhouse development COTS/SHOTS approach
PM Parttime PM Dedicated Fulltime PM
Scheduling Phasing/Scheduling
Semester Project Definition Organisation and Work Breakdown
Design Data and Documentation Manage-
ment
SE Implicitly done in project Explicit workpackages
Requirements definition Functional analysis
Budgets (mass, power, data, link) Requirements definition
Configuration/hardware items
Interface control
Budgets (mass, power, data, link)
Maturity growth OBC developed earlier, other subsystems Differential, some subsystems mature
have equal maturity growth faster than others
Student involvement +/- 60 +/- 40

Table 3.4: AAUSAT-II and Delfi-C3 Design Characteristics

The design of AAUSAT-II started in the summer of 2003. Different groups started working on the subsystems of
the satellite supported by the staff. After several months the design process was disturbed by the start of the ESA’s
SSETI Express project. AAU playing a major role in this project and several students working on AAUSAT-II
started working on this project as well. This caused a major delay in the development of AAUSAT-II. The effect of
this can be seen when the development of the mechanical subsystem is compared to that of the rest of the satellite
subsystems. The mechanical subsystem group was not involved in SSETI Express and delivered their hardware,
ready for integration, at the end of the first semester of 2005. Most other subsystems would require over a year
extra to obtain the same level of maturity as the mechanical subsystem. During the development of AAUSAT-II
the focus was already strongly on the complete design and the implementation, both hardware and software. The
groups working in the detailed design phase deliver a report that concerns hardware, software and often a proto-
type of the board and simulations of operations in for instance SIMULINK. This highly integrated approach is
good for the project and ensures gradual maturity growth.

After the detailed design was finished a small group of students proceeded to make the actual first Engineer-
ing Model (EM) PCBs during the summer. This was done on a voluntary basis. The result of this was that there
was hardware in an early stage of the project. The fact that both hardware and software design are done simulta-
neously means that there is a evenly spread in maturity growth throughout the project. It furthermore allows early
prototyping since basic software and hardware are available in an early stage.

During the design of AAUSAT-II there was a lack of top level hierarchy when it came to PMSE. The subsys-
tems were build according to the requirements that were stated and all worked well on subsystem level. The
project, however, used little standards when it came to risk management, cleanliness, interface control and doc-
umentation control. The main reason for this was the lack of real system level project management and systems

22
engineering functions in the project. This was caused by the fact that the departments in which the project is per-
formed lack PMSE in their curriculum. Furthermore the staff members functioned as advisers and project leaders
that performed some of the PMSE tasks, but had limited time on the project. The students were doing PMSE on
subsystem level and since they did not get any PMSE education they often did this as an integrated task within
their project in stead of separating it and giving it a real place in the project. Since no top philosophy is present
each group used its own vision on PMSE and these are not always compatible.

Designing Delfi-C3

Delfi-C3 was designed by the first group of students that worked on the project in November 2004. Each of
these students was responsible for part of the project. As the first group finished their work was gradually handed
over to their successors who finished the design and started with the production, integration and testing. Most of
the design work was done at the AE faculty with assistance of the EEMCS staff. The EEMCS faculty was primar-
ily responsible for the development of the Radio Amateur Platform (RAP) subsystem and SystematIC Design wa
responsible for the EPS.

During the preliminary and detailed design PMSE techniques were used. The down side was that actual hard-
ware and prototyping started late in the project life cycle. Especially the development of the PCBs started late in
the lifecycle. The first boards arrived less than six months before the initial delivery of the satellite was planned.
A focus more on hardware and less on paperwork should be adopted.

In later stages it was felt that some of the PMSE work was not very useful for later phases. One of the rea-
sons for this was that most documents were not seen as living documents and new students wrote new documents
on existing items in stead of updating the old documents. During the integration a more flexible attitude towards
documentation and procedures should be adopted in order to make the rapidly changing integration process more
efficient. If more living documents were maintained this could have been achieved.

3.4.1 Conclusions on CubeSat Design

During the design phase the foundation of the project is laid. It is important to define how the project will be
organised in an early stage. Using an integrated design approach in which hardware, software and electronics
mature at equal rate is highly desirable in the design and later also the verification process. Using a Keep It Simple
Stupid (KISS) design philosophy is highly important as it is very common for students and tutors to desire to
develop complicated, fancy, systems.

3.5 CubeSat Integration

During the integration phase the satellite is lifted from the paper design, produced and assembled. This process is
often called the MAIV phase. Special attention will be given to the MAIV of the satellite projects. This is done
because the author has been involved in this phase of the lifecycle in both the projects.

When a commitment is made to build a CubeSat all phases should have equal academic potential to ensure that
the overall satellite quality is maintained. The manufacturing and verification process of a complex subsystem de-
sign requires similar academic accreditation as the system design, although the academic skills used in both parts
of the lifecycle might be different. Table 3.5 shows a comparison of the integration characteristics of both projects.

Integrating AAUSAT-II

For AAUSAT-II the MAIV phase is left outside of the curriculum. The project ends with detailed designs of
the subsystems and often several prototypes. The project is than dependent on students finishing the satellite in
their own time. This causes a major unbalance in the project. Because of the dependency on students that work in

23
 Delfi-C3 and AAUSAT-II Integration Characteristics
Item AAUSAT-II Delfi-C3
Team availability <10 persons >20 persons
Team composition Staff, PhD and MSc students Staff and MSc students
Project commitment Voluntary base/PhD hours Contract based/thesis work
Academic accreditation No Mostly
Design approach EM/FM Protoflight
PM Scheduling Phasing/Scheduling
Organisation and Work Breakdown
Design Data and Documentation Manage-
ment
SE Interface control MAIV management
Operations planning
Interface control
Configuration management
Integration issues CDHS SW architecture (CAN problems) SW development
Ill structured SW development Rework on flight PCBs
Bad software protocol version control Late production of PCBs
Late integrated testing Late integrated testing

Table 3.5: AAUSAT-II and Delfi-C3 Integration Characteristics

their own time there is a structural shortage of manhours. After the official semester is done students have other
educational obligations and are hardly available for the satellite project. This causes the project to be delayed.
PhD students that have graduated on AAUSAT-II or AAU CubeSat are often asked to dedicate part of their time
to the project and helping the verification process. Also compromises need to be made in order to deliver on time.
This results in a loss of satellite quality. Initially the design incorporated a deployable solar panel that had to be
canceled due to lack of development and integration time.

A big advantage was gained by the fact that the EM stack was ready well before the launch. This allowed
debugging of the software and proper integrated functional testing. Unfortunately, the software formed a ma-
jor bottleneck in the MAIV phase. When the stack was integrated there were severe interface problems between
the software on the subsystems. One of the reasons for this was the fact that the satellite uses a Controller Area
Network (CAN) driver for communication. The implmentation of this system took muchlonger than was an-
ticipated. This system, although now common in for instance the car industry, is new in satellite and CubeSat
engineering. Furthermore the software development was ill structured. Only the programmer involved knew what
the software functionality was and should be. These problems delayed integrated testing and were eventually
solved by standardizing the procedures and making functional diagrams of the software.

The most important recommendation for AAU is to try to incorporate the integration phase in the curriculum
or to create an environment in which students are hired to finish the project. This would drastically reduce the
integration time. In the future a more standardized approach, using PMSE standards for interface control would
benefit the CubeSat projects at AAU. Also new, mission critical items should be tested as early in the integration
phase as possible to allow for proper troubleshooting and enough time for integrated testing. A good thing is the
fact that there is both an EM and an Flight Model (FM). This forces the project to get integrated hardware early
on in the integration phase.

Integrating Delfi-C3

The Delfi-C3 project has encountered similar problems in the MAIV phase. However, the curriculum is more
tolerant with respect to the demands on thesis work. Even though the workforce on the project is available full-

24
 CubeSat Model Approach
Prototypes Basic Model Protoflight Model
Purpose Proof of subsystem func- Achieve an integrated and func- Fully functional satellite
tions tional architecture
Functionality Subsystem subfunctions Comparable to EM boards Flight Model
Subsystem functionality EPS architecture functional Fully integrated
Proof of concept CHDS architecture functional Upgraded Basic Model
Verification Verify functions Qualification testing Acceptance testing
Examples Battery conditioning board Basic EPS in stack Flight EPS in stack
Power distribution board

Table 3.6: CubeSat Model Definitions

time there were still problems in making deadlines. Currently the faculty has hired several Delfi-C3 graduates to
finish the project. This solves most of the problems but is not the preferred solution.

In the Delfi-C3 project the protoflight approach was chosen as the MAIV philosophy. This meant that only one
satellite would be build and tested. Although this approach has the advantage of saving time and resources over
an EM/FM approach a negative consequence was that the MAIV phase was delayed due delays in electrical and
software development. Production of initial hardware and electronics started late in the project and issues that
could have easily been detected in an EM were now detected later. A large amount of rework and testing was
needed to get the subsystems up to flight status. The integrated electrical tests are scheduled only weeks before
delivery. This makes these tests crucial for the success of the project. Most of these problems can be found to lead
to the same source: a lagging electrical and software maturity in the project due to a lack of EEMCS students on
the project.

In the Delfi-C3 project the satellite remained a ’paper’ satellite for to long. Once the production was started
the schedule pressure and workload were very high. There was little margin for error and not enough time for
elaborate integrated testing. Another area of improvement is the project status awareness. Within the team only
few people know the actual project status. Having weekly meetings or status mailings could improve this and
present all teammembers with ’the big picture’.

3.5.1 Model Philosophy

Both AAU and DUT use different approaches for the models of the satellite produced for MAIV. At DUT a
ProtoFlight Model (PFM) is made and AAU uses an EM/FM approach. Both projects recognise the need for
prototypes and breadboarding before these complete models are produces. What is proposed is to use the best of
both worlds and make a MAIV testbed model before making the PFM. Table 3.6 shows the characteristics of the
different models used in this approach. The Basic model is used for initial subsystem and architecture testing.
Furthermore initial coarse environmental tests can be performed. The final design of is updated during the MAIV
of the Basic Model. The updated design is than used to produce the Flight Model design. This approach ensures
that (integrated) testing will start in time. Section 3.6 will illustrate how this new approach is to be implemented
in the phasing and scheduling.

3.5.2 Conclusions on CubeSat Integration

Both projects are dependent on launch delays in order to get their satellite integrated and tested in time. When a
Basic Model is used and the launch is booked at the end of the MAIV phase of this model the launch can be booked
with more confidence since less delays are expected during FM integration. After this milestone the project can
generally be finished in four to eight months, when proper attention is given to the MAIV of the FM. With around

25
two CubeSat launches scheduled a year 1 and negotiation of a launch generally taking around three months around
nine to twelve months is needed to get from launch negotiation to launch. This would mean that there is enough
time to finish the project and allow for some delays. Furthermore if time is left the team can work on thesis reports
and general documentation.

Another weapon against the delays is tighter phasing in the MAIV. This can increase the awareness of the project
status in the MAIV. If more control gates are implemented in the MAIV phase delays can be spotted earlier.
Furthermore the MAIV phase can be shortened by starting with simple breadboarding and simple hardware pro-
duction in earlier phases of the project. In this way there is a more gradual transition from design to production
and verification. In the current CubeSat project structure CubeSat projects are forced to fade in the end due to the
lack of time and academic accreditation of the MAIV phase.

A detailed and elaborate design process can only be verified and validated in an elaborate integration phase.
Doing a short integration phase after an elaborate design phase compromises the satellite quality since the design
features can not all be verified to the degree in which they were defined. It is unrealistic to expect that in a two
year satellite project the integration can be done in 4 months while the design has taken 20. Furthermore it was
found to be very hard and time consuming to implement PMSE in the AAUAST-II project that was already in the
MAIV phase. This ’reflective PMSE’ illustrates the importance of defining the approach right at the start.

3.6 Managing CubeSat Complexity

Next to the project teams and the project lifecycle aspects of the project there are also some general PMSE
aspects that are of importance in a CubeSat project. This section will deal with phasing, scheduling, information
management, requirements management and interface control.

3.6.1 Phasing
As the project transcends through its lifecycle it is important to keep track of the status of the project. Each project
can be subdivided in phases that indicate where in the development the project is situated. These phases have been
defined in literature [17] for ’normal’ space projects and tailoring is required to make them suitable for CubeSat
projects (figure 3.1). Things that have to be taken into account in the tailoring process are the facts that CubeSats
projects have:
• a much shorter lifecycle
• are educational in setup
• are less complex than conventional space projects
• have great overlap between the different phases
At the end of each phase control gates are used to verify that the system is ready to progress to the next phase.
The spacing between these control gates influences their effectiveness. Space them to close after each other and
no measurable progress can be noted, space them to widely and the overview of all the work that has been done is
lost. During the MAIV phase a closer spacing of control gates might stimulate the project progress. The project
is then quickly converging to a finish and the interaction between the different subsystems becomes closer.

Within the AAUSAT-II project there is no detailed phasing within the project. Since the education is based on
PBL the project has natural phases of six months. One of the advantages of this is that the project progress is
uniform for all the subsystems since the workload for each group is similar. The down side is that no real control
gates were defined for the satellite in the development process after which the project actually evolves to the next
stage.
1 http://www.delfic3.nl/forum/showthread.php?t=678

26
The Delfi-C3 project has incorporated phasing in the development process. Since Delfi-C3 does not use the Prob-
lem Based Learning (PBL) structure it is more dependant on the availability of students for certain subsystems.
Because of this the maturity of these subsystems are not necessarily similar. Tailoring has been done in order
to account for these inconsistencies in the CubeSat project. So called ’delta-sessions’ have been implemented.
Delta-sessions are implemented for reviewing those subsystems that do not have the desired design maturity at the
time of system review. These sessions allow the subsystems to pass the review at a later time and not delay the
entire development process. It goes without saying that extra attention should be given to those subsystems that
make use of delta-sessions since they lag behind the rest of the development process. Delfi-C3 had implemented
these sessions but due to a lack of manpower the critical subsystems could not catch up with the rest of the system.

A new model for phasing is presented in figure 3.6 in combination with the Basic Model that was suggested.
This approach is a ’best of both worlds’ model in which the quick synthesis of AAU and the structured approach
of DUT are combined. In this model the main point is that a basic model is made to prove that all subsystems
have enough maturity and the subsystems have EPS and CDHS basic architecture. Once these requirements have
been met the launch can be negotiated and production of the FM (updated from the basic model) can be started.
If a subsystem is lagging, manpower from the mature subsystems can be transferred where possible. Furthermore
the students that have a mature subsystem can invest the time available in writing their thesis.

Figure 3.6: Proposed CubeSat phasing

3.6.2 Scheduling
Scheduling is another area where tailoring is needed for CubeSat projects. In conventional space projects the
development time is long while CubeSat projects generally take no more than 3 years. What CubeSats do have in
common with conventional projects is the fact that they both use space grade materials that have longer leadtimes
than commercial products. The scheduling needs to take these things into account and structure the project in
time. Since CubeSat projects have a short lifecycle, project phases are short and small disturbances in the project
can cause relatively large delays. Furthermore due to scope of CubeSat projects it is also important to keep the
scheduling at a usable level for the project. One needs to take care not to make a meticulous schedule for a project
section that takes only a few days. Furthermore scheduling is hard and unpredictable. There are no models or
charts that tell you how the project will develop and where things can go wrong. Scheduling is always a ’best
guess’ to how the project will develop.

Both projects suffered from extensive delays that pushed back the schedule over a year with respect to the launch

27
windows that were identified at the initiation of the project. AAUSAT-II simply did not have the manpower to
get things done in time. For Delfi-C3 one of the causes of the delays was the fact that there was an increase in
workload in the transition from detailed design to production and testing phases due to the large amount of parallel
activities. During this time there were not enough students to perform all the parallel activities.

The two project schedules have been compared at several location in the project lifecycle: The start of the project,
the halfway point (January 2006) and the current planning (June 2007). The results can be seen in figure 3.7.
The project lifecycle is divided up in five phases. The first and last phase indicate the semester in which the
project was initiated and should be delivered for launch. The more interesting phases are the middle three. What
can clearly be seen is the optimism that is present in both project plannings. Initially the projects are expected to
be finished in two to three years. At the second measuring point both projects conclude that the phases they have
went through have taken longer than expected (except preliminary design) but they still expect the phases to come
to be as short as initially defined. At the last measuring point this is also found to be inconsistent.

From this figure also the estimation can be derived that the length of a CubeSat project lies around three years.
There are obviously overlaps between the phases and project complexity and starting maturity also play a role.
The author believes that AAUSAT-II could have been finished in 2.5 years if the SSETI Express mission did not
interrupt the progress and the MAIV phase was defined inside of the curriculum. When looking at the Delfi-C3
schedule one can see that the MAIV phase had to be compressed in order to make the delivery date, else the
satellite would have been finished later.

Figure 3.7: Project schedules of AAUSAT-II (top) and Delfi-C3 (bottom) at three point in the lifecycle

From figure 3.7 something else can be noted. At the halfway measurement the teams both were aware that there

28
were delays, however both teams expected the delays to stop during the remainder of the project. The factors that
caused the delays in the design phases were thought to be restricted to these phases and were no overall problems.
In hindsight it is concluded that the underlying causes for delays remain throughout the project. Although certain
delays may be ’local’ the determining factors for the scheduleslip are omnipresent and are likely to be mostly
caused by the inexperienced teams.

Proper scheduling in CubeSat project is updated frequently and is realistic. A general result from both project
is that the production and verification of the satellite is structurally underestimated.

3.6.3 Information Management

The goal of Information Management during a space project life cycle is to ensure that every actor has access to
all the information that is needed in order to perform his task. Two important requirements on information for
CubeSat projects are that it should be unambiguous and easy to find. Information exists in many forms. The forms
used mostly are documents. Furthermore new media like forums and newsgroups form new information sources.
Table 3.7 shows an overview of the information management characteristics of both satellite projects.

Information Management
Item AAUSAT-II Delfi-C3
Document tree No No
Document standard No Yes
Document structure Thesis reports Technica Notes
Some satellite documents Data packages
Thesis reports
Golden Notes
Manuals
Document utilization Hardly updates Defined: Living documents
Static documents Utilization: Static documents
Document coding No Yes
Information sources Newsgoup Shared disk
Forum Forum
Website Team email
CVS
Team email

Table 3.7: AAUSAT-II and Delfi-C3 Information Management Characteristics

When the two projects are compared there are some key elements that cause this difference in approach. First of
all the Delfi-C3 satellite is more complex than AAUSAT-II. This results in a greater need for management of all the
data. Furthermore the Delfi-C3 project has several industry stakeholders that also actively take part in the project
together with staff members. These industry partners demand a project more or less up to industry standard. The
result of this is that the Delfi-C3 project is more an industry satellite than a student satellite. Students learn how
to run an industry standard project while in the AAUSAT-II project students focus more on the practical side on
how to design and build it. The disadvantage of the AAUSAT-II approach is that a lot of lessons learned for future
projects are lost when students leave the university and take their knowledge with them. Furthermore it will be
hard to make a bigger, more complex satellite without seriously revising and upscaling the documentation control.

Table 3.7 shows an overview of the information characteristics of both projects. Both projects lack an overall
document tree in which the documentation is clearly structured. Furthermore AAUSAT-II lacks dedicated project
documentation and a standard documentation format. What both projects experience is a lack of living documents.
If a proper documentation structure is defined there is very little need for new documents and old documents are

29
updated. Students however prefer to write their own documents rather than update existing ones. This results in a
large amount of double work and a loss of the usefulness of the work done by predecessors, since their documents
’die’.

An area of improvement for both projects is the spread of information. For the Delfi-C3 project documents are on
the network drive and on the forum. This can be confusing when searching for documents. For the AAUSAT-II
project this is even more so. Ideally there are two media used to spread and attain information. The first source is
a newsgroup or team-email that is used for announcements. Next to this there should be one system that contains
all other information. This can be a network drive, a CVS system, a forum or a wiki. It is also recommended to
use a centralized tool to keep track of the verification progress. In a wiki a matrix structure can be defined that
incorporates all information and presents it in the way the user wants to. An example of some structural elements
and their organisation in such a system figure 3.8 can be seen. The advantages of such a system are:
• Online, thus available to everyone
• Quick and up to date
• Everyone can review information and request changes/updates
• Everyone can send in new information
• New information is checked by subsystem administrators

Figure 3.8: Wiki structure

3.6.4 Requirements Management

Requirements form the red line that runs through each project. They are derived from the functions that the product
should have and flow through the design process where they are reviewed, implemented and verified. Require-
ments are measurable demands that are imposed on the system. The total set of requirements deal with different
sources, being customer wishes or industry standards. It is important to keep track of requirements as they flow
through the system. They form the lines that connect the final product to the initial mission statement and are the
key to validate that the system does as it is asked to and verify that it works as it is defined to. CubeSat projects
deal with different sets of requirements. First of all the CubeSat standard requirements dictate the physical proper-
ties and environmental performance of the satellite. Next to this there is a set of mission and payload requirements
that further specify the demands on the satellite project.

30
Within the Delfi-C3 project requirements are explicitly stated in a requirement specification document. This doc-
ument contains all requirements for the Delfi-C3 system categorized and numbered. The requirements originate
from the requirement analysis that was done at the start of the project. They are used later in the lifecycle during
the verification process.

Within the AAUSAT-II project also mission requirements were formulated. The general satellite requirements
were put into a requirements document. However the subsystem requirements were not stored centrally and a
standard for requirement tracing was not present. Furthermore in later phases of the development the documen-
tation was not kept up to date. This caused confusion on which requirements were to be verified. Requirements
were dropped by subsystem teams without proper documentation, leading to miscommunication within the team.

3.6.5 Interface Control

Both projects deal with a large amount of interfaces that are to be managed. The way in which this is done in both
projects illustrates the differences between them.

Within the AAUSAT-II project the interfaces are defined in the weekly meetings. Furthermore each individual
subsystems keeps a very basic list of its electrical interfaces and commands. The CDH subsystem is responsible
for implementing all these commands. This is often done by just implementing and testing the new command at
the spot. The mechanical interfaces were defined at the start of the project and are relatively simple. The areas
where the electrical system and mechanical system interface have caused some problems that required redesign of
either a sidepanel or a PCB.

Within the Delfi-C3 project Interface Control Documents are used in which the interfaces between the different
configuration items are defined. Because of the large amount of interfaces there is a need to track them thoroughly.
Different kinds of interface types are identified and charts are made in which these are related to the configuration
items. Furthermore in the stack design a special interface board, the InterConnect Board, is introduced to simplify
the interfaces. Both project use a modular design to simplify and concentrate the interfaces between the modules.

In interface control it is important to tailor the standards to the system needs. The interface control shows the
difference in tailoring done for both projects. AAU does it in a practical way while DUT uses the industry stan-
dard (although tailored somewhat) approach. Currently this work for both project although both still encounter
some interface problems. If AAU however wants to upscale the complexity of their satellites a better interface
control will be needed in order to cope with the increasing amount of interfaces.

3.7 Conclusions and Recommendations

Student CubeSat projects are a challenge in many ways. These projects are characterised by short development
time and complexity of both the project and the satellite. Multidisciplinary teams are of key importance in getting
the job done. Complexity is the key variable in defining the PMSE approach within the structure. With increas-
ing interactions and interfaces between the different (sub)systems the complexity increases exponentially. With
increasing complexity the need for PMSE increases. The Delfi-C3 project is a more complex and hence there is
more need for PMSE. Furthermore the educational background of the students is filled with PMSE courses and
projects. Within the AAUSAT-II project PMSE is used, but in a more implicit way.

The great challenge in PMSE control is that some subjects that are dealt with are unpredictable by nature. Things
like schedules and project teams can not be modeled and are subject to change. The ideal case scenario can always
be put on paper, but this does not incorporate the troubleshooting and ’educational’ errors that are so characteristic
for student satellite projects.

31
In the end good PMSE has two functions within the project. In the early phases it helps to develop the best
satellite that matches the functions desired for the system. Later on it helps structure the design and build of the
satellite. So in the end good PMSE contributes to the best satellite and the best way to build it. Good PMSE
structures and coordinates the project but also needs a good structure in its own setup in order to be successful.

Both projects have things that can be learned from eachother. AAUSAT-II could use more structure, standard-
ization, organization and documentation. This can be achieved by implementing more courses on PMSE and
being more thorough in the design phase. These things are obviously interrelated. When a better overall structure
is set up at the project start and more time is invested in putting down on paper which standards are used, what the
exact requirements are and how these will be verified the project will run smoother. This extra structure is needed
within these projects if AAU wants to develop more complex satellites in the future. AAU could cut back their
development time by enhancing their educational definition of the MAIV phase.

The Delfi-C3 project would benefit from the more pragmatic approach of AAUSAT-II and start working on proto-
types, and software in a much earlier phase. Furthermore the students working on the project are less multidisci-
plinary than the students at AAU. This is mainly because of the curriculum that is more based on pure aerospace
engineering courses instead of PBL which allows the students more time to develop necesarry skills. An advice
would be to implement more course on electrical engineering in the curriculum to make the students more all
round space systems engineers.

In general a CubeSat project ideally possesses a set of characteristics:

Team
• A balanced team of students disciplined in: PMSE, electrical engineering and mechanical engineering
• Experienced staff members in the above mentioned fields
• Firm base of hours available for all students involved
• Steady rate of student availability during the project
• Regular progress meetings (2 weekly)
Phasing and scheduling
• Phasing as proposed in figure 3.6
• Hard phase separation closed with reviews to ensure equal maturity at start of FM MAIV
• Use of delta sessions and invest manpower in lagging subsystems
• The MAIV phase should be equally long as the design phase
Design and Integration
• Top level, structured level PMSE from the start of the project
• Academic accreditation of the entire project
• Basic Model combined with ProtoFlight Model approach
• Integrated development approach (HW, SW and electronics)
• Early prototyping and breadboarding
Information
• Use of living documents that are kept up to date
• Clear documentation tree and structure
• A wiki or CVS based online verification system should be used
• Clear requirement and interface definitions

32
Appendix A
Thesis Plan

This appendix contains the thesis plan as it was handed in on May 22 2007. Although the timeline has been altered
the content is still valid.
Version 1
09-02-2007 Thesis Work Plan Joost Elstak

Student Supervisor
N Joost Elstak N Rob Hamann
# 1052942 E R.J.Hamann@TUDelft.nl
E J.Elstak@Student.TUDelft.nl T +31 (0)15 278 2079
T +31 (0)6 266 52825

Thesis title
Working title:
“A Comparative Analysis of Systems Engineering Techniques and Methods in CubeSat projects”

Introduction and background

In April 2006 the thesis work was started. The following three items were agreed upon to be part of the
work activities for the thesis:
• CubeSat exchange with Aalborg University AAUSAT-II team for one semester (30 ECTS)
• AIV activities on Delfi-C3

The idea behind the exchange was that the student could work in two CubeSat projects in their final phase
and get insight in the way they are set up and run. The comparison of the projects will form the core of the
master thesis that will comprise of a journal on PMSE in CubeSat projects together with background
information in the appendices.

In April 2006 the student started with his thesis work on Delfi-C3. From April to July the student worked on
the Student Parabolic Flight Campaign (SPFC) experiment that was entered for Delfi-C3. The experiment
concerned verification of the antenna deployments for Delfi-C3. From 01-09-2006 to 01-02-2007 the student
has been involved in the Assembly Integration and Verification (AIV) setup and supervision of the AAUSAT-
II satellite that is currently being developed at the Aalborg University. The thesis work done in that period
represents an approximate workload of 30 ECTS. This project work has been examined with a project
defense and graded a 10 according to the Danish scaling system (for conversion see final section of this
document). For the final phase of the thesis work the student has participated in the verification process of
the Delfi-C3.
Thesis objectives & Work to be performed

The final thesis will be based around a journal that compares AAUSAT-II and Delfi-C3 on PMSE items. The
thesis will be structured as follows:

Introduction
Mentioning the work done on Delfi and referring to the appendices
Mentioning the work done on AAUSAT-II/SPFC and referring to the report
Team information
Project information

Core
10 - 15 page journal in which the projects are compared on PMSE

Appendix 1
Concise description PMSE Delfi-C3
Concise description PMSE AAUSAT-II

Appendix 2
Lessons Learned DK (from report DK)
Lessons Learned Delfi-C3; Based on my experience and AB JR reports

Appendix 3
Delfi-C3: ICB work performed

--

AAUSAT-II report handed in separately for the exam comity

The journal will look at both projects and identify where they excel and where there is room for
improvement. Since the Delfi-C3 is highly organized and structured while the AAUSAT-II project
has a strong pragmatic approach the way in which the projects are ran differs greatly. This
makes them very interesting subjects. For AAUSAT-II special attention will also be given to the
influence of the lessons learned and heritage of the previous two satellite projects on t he
current project.

Timeline

For the planning the student will work on his thesis at home half time. Depending on the
progress the writing time can be increased to make the due dates

May 20: Introduction done

June 3: Draft on Core

Week of June 3:
Review of material
Decision on date depending on work handed in

June 8: Appendices
June 22: Hand in final thesis

Involved parties
• Chair of System Integration, Design and Analysis of Space Systems
• Delfi-C3 Team
• AAUSAT-II Team
Auxiliary information and references

Denmark and Delft

The credits and grade awarded in Denmark will count as half the work done for the thesis. In
Delft the remaining half of the thesis work will be done by writing a journal that compares the
two projects on PMSE.

Danish Grade conversion:

Using the following information the grade conversion was established:

University of Copenhagen
Delft University of Technology
Wikipedia

A Danish 10 relates to a firm B (B+) in ECTS which translates to a 8.5>9- in the Dutch scale.
This mark corresponds to the value that fellow students and tutors indicated as corresponding
to a Danish 10. Furthermore the following table shows the Danish system directly related to the
Dutch one when a linear relation is assumed.

DK NL

0.00 1/2/3
3.00 4.00
5.00 5.00
6.00 6.00
7.00 6.67
8.00 7.33
9.00 8.00
10.00 8.67
11.00 9.33
13.00 10.00

note: grading assumptions:

NL6=DK6
NL10=DK13

Information on AAUSAT-II:
www.aausatii.aau.dk

AAU final report: ‘AAUSAT-II AIV Definition and Supervision’

Path: S:\Gezamenlijk\Personal Directories\Joost_Elstak\AAU

Availability

The following has been arranged with Rob Hamann concerning my availability: During my thesis writing I
will cut back my ‘Delfi Time’ to 50% and focus on writing my thesis at home. If necessary the writing time
will be increased.
Appendix B
PMSE Setup in Delfi-C3 and AAUSAT-II

This appendix contains an overview of the PMSE philosophies used in both projects.
B.1 PMSE in the Delfi-C3 Project
Already several documents have been written on PMSE [5], [21]. The first document [5] defines the PMSE
approach for the Delfi-C3 project. This document represents the PMSE point of departure for Delfi-C3 and was
written in August 2005. The second report written [21] deals with the implementation of PMSE into the Delfi-C3
project. This document was written in April 2006 and continues on the work done in [5] and presents the status of
the project at that time while also reporting on changes that have been made in the PMSE. This document can be
seen in line with the previous two documents. It further evaluates the PMSE activities that have been performed
over the last two years by comparing them to another CubeSat project.

Systems Engineer 1
Requirement Definition & Specification
System Breakdown
Functional & Operational Analysis
Performance Budgeting
Systems Engineer 2
Requirements Verification
Interface Control
Configuration Management
Manufacturing and Integration
Detailed Design
Systems Engineer 3
Technical Resource Budget Control
Interface Control
Configuration Management
Assembly, Integration and Verification (AIV) Implementation and Management
Operations Planning and Execution
Coordinating of Post Launch Activities

Table B.1: Systems Engineer Definition for Delfi-C3

Within the project the project manager and systems engineer have distinct functions. Since the project manager
and systems engineer are students they cannot be end responsible for the entire process. The project leader
therefore is ir. Rob Hamann, who is final responsible for financial budgeting, resource allocation and Statements
Of Work (SOWs). However, the day to day management of the project is in the hand of the project manager. It is
the function of the project manager to support the general design process of the Delfi-C3 . One of the challenges
that arrises here is the fact that in theory the project manager function is a student function within the project.
In practice this is however partly true. The project manager function started as a student function. But after the
graduation of the project manager the handover to a successor proved hard. This is due to the fact that the new
project manager has to achieve the working quality and knowledge that his predecessor had at the point of his
graduation. This is to much to expect from a starting student project manager. Therefore the initial student project
manager was hired by the faculty to finish the project. The following tasks are allocated to the project manager:
• Phasing and Scheduling
• Organisation and Work Breakdown
• Design Data and Documentation Management
• Publicity and Outreach
• Golden Notes
Throughout the lifecycle of the satellite the tasks that are to be done by systems engineers vary greatly. In the
early stages the systems engineer is there to help translate the mission statement to functions and requirements.

38
Later in the process the systems engineer structures and guards the integrity of the assembly and verification of
the satellite. Due to the different nature of the tasks there is less difficulty in handing over work to new student
systems engineers, although still a period of overlap is applied to ensure a smooth transition. Furthermore within
the project almost all students get a systems engineering task appointed to them. In this way every student is
involved in the systems engineering process.

The different tasks can be seen when the Vee-model is used. This model is a graphical representation of the
design, construction and verification of the satellite. An example of a Vee-model for Delfi-C3 can be seen in
figure B.1. What this model is used for is to first illustrate the decomposition of the mission need statement to a
detailed design of the satellite (the left flank of the figure). From there on the right flank of the figure shows how
this detailed design is integrated from part and components to a satellite. The levels of depth in the assembly are
related back to the decomposition to illustrate what the system should be verified against. This figure also shows
the different tasks that are typically appointed to a systems engineer throughout the development process.

In figure B.1 also the functional division between the different systems engineers that were defined for Delfi-
C3 are show. This division was defined in the thesis reports of Abe Bonnema [5] and later updated by Jeroen
Rotteveel [21]. Initially two systems engineers were ’defined’ [5]. A year later also a third systems engineer
had been ’defined’ [21]. Table B.1 shows the distribution of the different systems engineering functions, some of
which overlap.

Figure B.1: The Vee-model together with the systems engineer definition for Delfi-C3 [5]

In the Delfi-C3 project Abe Bonnema has been project manager for most of the project. He has also been Systems
Engineer 1. Jeroen Rotteveel has been Systems Engineer 2 and is still part time involved in the project. Bram
Vaartjes is currently Systems Engineer 3 and as things are will be the last Systems Engineer on the project.

Within the Delfi-C3 project there is a strong awareness that due to length of the project (handover) and the com-

39
plexity of the satellite good PMSE should be the cornerstone of the project. Especially good PMSE in the AB
phase can provides a firm and transparant project in the later phases.

40
B.2 PMSE in the AAUSAT-II project
The discussion of the Project Management and Systems Engineering (PMSE) approach within AAUSAT-II is
strongly related to the general approach of PMSE within satellite projects and general projects within Aalborg
University (AAU). Therefore these will also be treated in this section. This section has been based on personal
experiences and a paper on space related education at AAU [20].

The core of the educational philosophy at AAU is the fact that students should be in charge of every aspect of
the projects that they perform. Normal project are performed under a supervisor that functions solely as advisor
and guardian of the educational content. For projects that involved several groups of students, like AAU CubeSat
and AAUSAT-II, top level management is applied in an attempt to guide the project. A central person is appointed
as project manager. Together with the supervisors of all subprojects and student representatives from each group
a steering committee is formed that oversees and guides the project. This groups is effectively the management
group of the satellite project. Also former CubeSat students take the role of supervisor/advisor upon themselves
within this group. Figure B.2 shows this structure. The steering committe has the following tasks:

• Define mission and payload

• Discuss and determine interface specifications
• Ensure that loose threads were picked up
• Keep an overview of the project
• Manage the financial budget
• Communicate with the students as an engineer to his peer

Figure B.2: The project organisation within the CubeSat projects of AAU

Next to these tasks the steering committee also functions as mediator between the three different groups involved.
One of the issues that was found during previous projects was that it was hard to keep the subgroups focused on
building a subsystem based on the Keep It Simple Stupid (KISS) principle. Supervisors tended to desire impres-
sive and complex subsystems instead of simple, reliable functional satellite subsystems. The steering committee
ensured that the project groups stuck to the KISS principles. In general the management style was very "Laissez-
faire" and the steering group activities were kept to a minimum to ensure that the students performed the bulk of
the work on the project.

According to the project manager of the different satellite projects the management falls into three different
phases[20]:

• The startup phase

• The design/construction phase
• The finalization phase

41
In the first phase visible management is needed to help the students set up the project and define responsibilities.
Furthermore in this phase the management together with the steering committee does some reconnaissance work
for the different subsystems. This is done because the project work at AAU has a strong focus on practical im-
plementation. By doing the initial design trade-offs and satellite design the management ensures that the student
projects done after the startup can be translated into assignments with practical elements. This ensures that the
students get the chance to get hands on experience in space systems engineering. In the second phase the man-
agement is invisible and hands over the work to the students. They start to work on their projects and define the
satellite subsystems in detail. In this phase all responsibility lies with the students. In the third and final phase
the students finish the project on a voluntary base and the the management becomes visible again and guides the
integration and troubleshooting of the satellite.

Within the project the students were the ones to implement the day to day PMSE activities, guided in the project
management by the steering committee. In practice the systems engineering was mostly focused on interface
control and was done "on- the fly" during weekly meetings. After the AAU CubeSat projects the students indi-
cated that they wanted more top level management in future projects. However when this as done for AAUSAT-II
project was ’over-managed’ and students felt that it as not their project anymore since the committee made all the
decisions. The situation was then turned back to the old situation. Ideally the students would be responsible for
the definition and implementation of the overall PMSE philosophies and principles within the project. However,
they lack practical knowledge of the subjects since they are not part of the curriculum. In the current situation es-
pecially the systems engineering is done by each group individually to an extent that each individual group deems
necessary. This implicit form of systems engineering lacks common purpose for its use.

During the lifecycle of the satellite projects a large group of students is involve in the project. At the start of
a project normally around 10 groups of around 5-7 students start on the a project related to the satellite. During
the Manufacturing, Assembly, Integration and Verification (MAIV) phase of the project, that is entirely on volun-
tary base, all of the activities are performed by 5-8 students. This causes difficulties and delays during this phase
of the project.

42
Appendix C
MAIV Lessons Learned

This section contains the lessons learned from Delfi-C3 and AAUSAT-II and are focused around the lessons learned
by the author concerning verification.

’Verification:
Everything will take twice as long as you think, even when you take this rule into account’.
C.1 MAIV Lessons Learned from the Delfi-C3 Project
This section contains the main lessons learned in the Manufacturing, Assembly, Integration and Verification
(MAIV) of the Delfi-C3 satellite and more specifically the InterConnect Boards (ICBs).

C.1.1 Planning
The biggest lesson learned is that the MAIV of satellite subsystems never goes as smooth as thought. The quote
on the front page of this appendix illustrates this.

The process of getting the subsystem produced properly, implement faultless software and verify these two things
flawlessly is highly unlikely to go right at the first try. Trial and error and problemsolving is needed to get the
system working.

Another lesson learned was that the implementation of software takes long and was started too late. Software
engineers should be working on the project several weeks before the first prototyping is started. Also there was a
lack of electrical engineers which put a lot of pressure on those that did work in the project. Their limited avail-
ability proved to be a bottleneck.

The last lesson learned that deals with planning deals with the workfoce. The Delfi-C3 project uses parallel
phasing. This can be a very good way to make the development of the satellite compact. However using this
method makes it of paramount importance that a proper size of workforce is available. In the transition between
design to MAIV a lot of activities are ended and new ones started and there were not enough students to get all the
workpackages that were to be done finished in time. In the end this caused delays in the project. Furthermore mul-
tiple phases being conducted at the same time by a small group of people makes it hard to set the right priorities
and contributes to a spread in maturity growth.

C.1.2 MAIV Process

During the verification process a number of things were noticed that could be approved. First of all the first Flight
Model (FM) produced of each board had to be turned to Non-Flight within a few weeks due to design errors and
extensive rework. So three boards were made for each InterConnect Board (ICB): One Non Flight Model, one FM
and one Flight Spare Model (FSM). The Non-Flight board was used for electrical verification since the system
was electrically identically to the others. The FM and FSM were produced while the Non Flight model was still
undergoing testing and was producing rework and redesign data. This meant that eventually all boards had to get
components replaced due to design changes on the boards and rework due to workmanship errors. Ideally the first
board was used as a testbed and a flight worthy redesign was produced after all testing was performed on the first
model. This approach is suggested in section 3.5.1. Also subsystem environmental testing should be done before
the final design is issued.

Some practical recommendations concerning the verification process will also be made. The ICB contains a
large amount of connectors and all of these should be keyed. At several occasions the connectors were connected
wrongly. Also when pinsavers are made these should be keyed to ensure that the connector can only be connected
in one way. The need for pinsavers for all connectors should also be evaluated. The task of making pinsavers is
timeconsuming and not very academic, but desirable for the connectors that are going to be used in flight. It is
advised not to use them on programming connectors and other connectors that will not be connected during the
flight.

C.1.3 Information Management

Since each ICB had three versions in use for the verification process there was a total of six Printed Circuit
Boards (PCBs) under the supervision of the author. Therefore it was very important to keep track of the status

44
of each individual board. This was done by using separate storage containers, logbooks and testplans. Further-
more a document was created in which a quick overview of the verification status and rework could be found.
This method of version control proved to be very successful and further investigation to using online databases or
wiki’s for better availability and flexibility is advised.

The tesplans that were made for the ICBs were not updated frequently enough. Since the test procedures changed
substantially due to hardware and software changes on the boards they sometimes lost their efficiency. It would
be wise to minimally do a testplan review and update after the first board has been tested. When a design was
altered a Non-Conformance report was produced. These reports were however not followed up and and so the
Non-Conformance system did not work properly and should be reconsidered.

C.1.4 The MAIV playing field

This section will list some general issues and contradiction that are typical for university satellite projects. These
items illustrate the playing field of the project and shows the project characteristics.

During the project the students have to hold a balance between doing thesis work and project work. Although
the two are interrelated the students should be informed about what is expected from them in the project and in
their thesis work. Ideally the project documentation made by the students is handed in as thesis work and the total
work done is evaluated. In practice things like making pinsavers are not considered to be part of the thesis work
and the exam committee prefers a thesis with academic content and hence a separation between thesis and project
documentation exists. In order to satisfy both the project and the curriculum the management should accept that
the practical satellite engineering is part of the work done by students and be flexible in the judgement of the
academic work done by the students. In return the students must be aware of the fact that they are also expected to
deliver some academic content at the end of their thesis year and should shift priorities to this in the final months
of their work. The author considers this thesis to be a first attempt in producing an academic thesis in the practical
CubeSat context.

Another CubeSat characteristic is the conflict within the project between being an educational, learning envi-
ronment and the desire to run a smooth project. Especially during MAIV the project schedule does not allow time
for making mistakes. It is the duty of the project manager to make sure this balance is maintained. This is not
an easy task and allowing more time for the MAIV phase would allow more time for the learning environment.
Furthermore the project manager faces the challenge of steering a team over which he has no authority. In the
industry the project manager is the boss of the team. In a student project the project manager is often a student of
tutor with limited power over the team. The project manager is more than often dependant on the voluntary work
done by the team to get the project done.

As a final word on the lessons learned the author feels that the past year has given him a huge amount of high level
engineering skills that could have never been learned from books, mathematical models or standard procedures.
There is no better way to learn how to build a satellite than by building a satellite.

45
C.2 Lessons Learned from the AAUSAT-II Project
This section is copied from [7]. Conclusions and recommendations are highlighted in the text.

This chapter deals with the lessons learned from AAUSAT-II. The project will be critically looked and and recom-
mendations for future projects will be made. First the project planning will be discussed. After this the assembly
and integration related items will be discussed. Finally the verification will be discussed. This chapter partly sum-
marizes what has been said in previous chapters and addresses certain new items. Together they give an overview
of the most important lessons learned in the previous months. Furthermore general project recommendations are
made. The chapter is concluded with a short summary of the contributions that were made to the AAUSAT-II
project.

C.2.1 Project Planning

The basic planning of the AAUSAT-II is based on the project based learning method that is used throughout the
Aalborg University. This means a lot of work is done in project groups working on a specific subsystem.

The AIV Phase Definition

Project Phase Definition One of the areas where the project work can be improved is in the project phase
definition. For AAUSAT-II a large part of the requirement definition is done by the management. Furthermore
for most subsystems the project phases are defined as being done by project groups. When all this is done the
satellite still needs to be build, integrated and tested before launch and here is where there is no project definition.
The last phases of the project are performed by enthusiastic students in their own time. These people are highly
motivated and know the system well since they often worked on it in previous projects. It is however very hard to
steer and guide a process done on voluntary basis. The time available fluctuates and it was considered to be hard
to demand certain things to be done, since everything is voluntary. This is especially hard when critical deadlines
and delivery dates are coming. So the lack of a steady amount of working hours makes the project hard to
steer and finish in time. Ideally a small team would oversee and guide the final phases of the project as part of
their curriculum. This would ensure more continuity in the project and give a proper status to the final phase of
the project that is currently missing. Changing the requirements on the project work deliverables and looking
into incorporating the AIV phase into the curriculum could be considered in order to check the viability of
having a small team.

Project Structure Another recommendation for next missions is to structure the later project phases more
clearly. This start by defining when what will be done and documenting more of the activities done and choices
made. This will increase transparency and improve the transfer of project tasks within the team and from the team
to new members or external relations. During the fall semester in 2006 a start has been made in restructuring the
documentation and making it easily accessible through a forum. However more work can be done to improve
this. Most documentation used stems from the project group phase and it was found to be hard to update the
information because there simply is no more documentation. One of the reasons is that people prefer to work on
their subsystem rather than on a document, especially when they only have limited time available for the project.
This documentation gap makes it hard to transfer work to other people since there is so little information. Further-
more one of the main dangers is that valuable lessons learned or experiences gained are lost because they are not
documented for new projects. This prevents the same mistakes from being made again.

Another lesson learned is that it is important to get all the information needed from the launch provider
as early as possible. During the course of the project the launch provider has not been very forthcoming in their
information supply and this has lead to unclarities about the delivery dates, acceptance tests to be done and test
specifications. It is advisable to keep in close contact with the launch broker and to stay on top of all developments
and make sure all information is given to you in time.

46
Software development

Next to the development of the mechanical and electrical subsystems also software for the satellite has to be
written. Each subsystem is considered to be responsible for writing their own software. Furthermore the CDH
subsystem is responsible for providing the general software architecture. It has been found difficult to asses the
software status of the subsystems in the course of the project. There are several causes that can be found for
this.

First of all every subsystem is very self involved in their own software. It is hard for other people to help with
troubleshooting since they do not know the software. Furthermore it is hard to judge the progress made and the
work to be done for software. Often what appears to be a small problem at first turns out to be a big issue that
takes long to resolve.

Another big problem throughout the project in the Assembly, Integration and Verification (AIV) phase
is the simple fact that people do not have enough time available to work on the project. The first project
phases in which the subsystems are defined and developed are done as part of the project education system. Stu-
dents get a semester to work on their project and devote all their time to the project. For the integration and testing
phase of the project there is no official project defined. Students work on their project in their own time, next to
other project work that has to be done for other projects.

Also the fact that there were a lot of problems with the software concerned the CAN bus and the Hardcore Satellite
Network (HSN) drivers slowed things down. Because the basic integrated communication did not work properly
it was not possible to do integrated tests on a functioning stack. This functioning stack was needed to test and
verify many other integrated functions that concerned multiple subsystems.

In order to try to get a better overview of the software development process several things were tried. Regular
meetings, subsystem planning and the forum have contributed to better communication, a better software planning
was however not achieved. One of the causes of this was also simply the fact that the author lacks knowledge about
software development. This made it harder to asses the current status and things to be done. Furthermore the lack
of up to date information made this problem even bigger.

In general it was considered to be very difficult to get a clear overview of the software status and plan-
ning. The solution that was obtained was making clear schematic overviews of the software architecture
that was intended to be developed. Using tic-boxes the current status of a specific element could be indicated.
Furthermore colors and short hands were used to indicate element criticality and activities to be done. Most sub-
systems have a thread on the CDH and a structure of their own. Furthermore every subsystem has a Interrupt
Service Routine (ISR) and generic HSN part.

C.2.2 Assembly and Integration

This section reviews the AAUSAT-II hardware. It will deal with several items that have caused some difficulties
and delays in the course of the project. Although the nature of the problems might seem very different they are all
related to hardware.

Long Leadtime Items

On of the things that was noticed in the course of the project is that certain items were delayed due to unexpected
long leadtimes. For standard Commercial Of The Shelf (COTS) items a leadtime of one to two weeks can be
expected. When specific space hardware, like epoxies is ordered the leadtime can vary anywhere from 2 weeks
to 4 months. This was especially problematic for the silicone adhesive that is to be used to glue the solar cells
to the sidepanels. Because of the rarity of the product and the paperwork often attached to getting it a high price
and long leadtime must be expected. It is therefore important to identify the long leadtime items well before

47
assembly begins. It is desirable to order these items no later than 4 months before assembly starts. In general the
following items can be considered to be long leadtime items:

• Space rated adhesives and hardware

• Specific rare electronical components
• Custom designed mechanical components
• Connectors
• PCBs

Mechanical Department Hardware

Due to the fact that the mechanical design was finished well before the software and subsystem design a
development discrepancy arose. Since the summer of 2005 no one had the complete picture on the mechanical
structure status. When all hardware was checked it seemed that some hardware was missing or had been used for
test setups. Furthermore some redesign had to be done on the designs in order to update the mechanical design.
Normally these things would have been relatively simple tasks but with the mechanical team only limited available
these tasks took longer than expected.

Another mechanical problem that arose was the fact that there was no single final version of the AAUSAT-
II in any Computer Aided Design (CAD) program . Different versions were circulating and none represented
the satellite as it was to be launched. The sidepanels were numbered differently in different versions, making it
very hard to identify a final version of AAUSAT-II. It is desirable to apply some version control to the circulating
drawings and keep them at a central place.

The final mechanical lesson learned to be addressed is the deployable solar panel. The panel is considered to
be an extra in the AAUSAT-II design and is not a mission critical item that is to be flown. In the original plans the
AAUSAT-II would have a deployable solar panel on the side of sidepanel B. During the hardware inventory no
FM or EM version of this panel was found. After consulting the mechanical team several testpanels were found
at the mechanical department. None of these panels was up to FM or EM standard because the overall production
quality of the panels was low. For the assembly phase this means that a new panel has to be made if the panel is
to be flown at all. When testfitting a satellite mockup with the Poly Picosatellite Orbital Deployer (P-POD) there
appeared to be a misfit between the two. Although AAUSAT-II is to be launched in a X-POD which may have
different dimensions this raised concern about flying the panel. If it is to be flown it should be made as flat as
possible and it must be ensured to be able to fit inside the X-POD. This is of special importance since the panel
will hold the sidepanel B solar cell. If in a later phase of the project the panel is scrubbed from the design there is
th
a chance that sidepanel B can not be refitted with a solar cell and this would results in AAUSAT-II losing 16 of
its power. All these issues have resulted in the removal of the panel from the current AAUSAT-II design. If during
the assembly time is found to produce the panel, without compromising the rest of the satellite’s assembly and
verification process, it can still be added to the design. For the time being it is not part of the design. It is however
incorporated in most procedures, assembly plans and drawings so it can be easily added later on.

Hardware Choices
In case of the batteries the wrong choice was made concerning the type used. The EPS report stated a choice
between a space rated and a COTS battery. The COTS battery is chosen because of better performance and the
fear of limited availability of the space rated type. Because of this choice a lot of time in the AIV phase has to be
dedicated to the testing of the batteries. In general the qualification of space hardware can be seen as a learning
experience with educational value. However mission critical items like the power system for the satellite have
proved to be sensitive to malfunctions and are a mission critical system. With the limited AIV time available the
choice for reliable and proved technology would be favorable in this case.

48
Another issue that has arisen with the batteries is that the expected charging and discharging conditions are at
and sometimes over the battery envelope. From previous thermal analysis the in orbit temperature is expected
to stay below zero (when the satellite is switched off) which gives rise to charging and discharging issues. This
requires extra testing to be done on the batteries and potentially makes the batteries a liability for the entire system.
While the possibility of below zero orbital conditions is modeled in the mechanical report of May 2005, the
issue of potential power problems did not arise until a year later. This issue should have been spotted and
solutions tracked much sooner.

C.2.3 Verification
Requirement Tracing
One of the lessons learned from setting up the verification process of AAUSAT-II deals with the requirement
definition. It proved to be very hard to track down the basic technical requirements of AAUSAT-II. This is of
great importance for the verification phase because these requirements form the basis of the tests to be done. The
general project requirements are well documented at the start of the project. These form the basis of the project.
The technical specifications of the satellite are however spread over the different project reports and seem to change
in the course of the project. It is recommended that one single document is kept that contains all initial and
updated requirements for the satellite numbered and grouped according to subsystems. Furthermore certain
requirements were altered or changed in the course of the project without clear documentation. The persons
involved in the subsystems know of the alteration but an external person can not find this alteration on his own.
An example of this is the ADCS pointing accuracy requirements. These can be found as requirements in the
ADCS project group documents but investigation learned that the requirements were simply dropped.

Verification Structure
The lessons learned for the verification structure concern the structure of the AIV phase. Before the AIV phase
is started it should be clear who does what and who is responsible for for certain parts of the project.

A transparent planning will also result in a better structured verification phase. Due to the fact that it is sometimes
unclear when certain elements will be ready tests are postponed, cutting the verification time short. Furthermore
several tests and activities depend on external relations which makes keeping deadlines even more important.

A major lesson learned is the fact that there is a need for problem tracing. On several occasions a problem
was noticed and discussed without a conclusion or follow up. This meant that the same problems keep popping up
without being resolved. When a problem arises it should be made someone’s responsibility to track and resolve it
and report this.

Furthermore a lesson learned is that all documentation and communication should be in English. The
fact that the mechanical report was in Danish was cumbersome and it cost some time to interpret the work done.

49
50
Appendix D
SPFC2006 Conclusions Report Summary

This section contains the summary of the Student Parabolic Flight Campaign 2006 Conclusions Report [8]. This
report was handed in after the testflight had taken place. The results of this report have been incorporated in a
redesign for the Modular Antenna Boxes (MABs).
Summary

In this document the results of the Student Parabolic Flight Campaign 2006 can be found. For this campaign the
Modular Antenna Box (MAB) was tested in order to verify that functionality of the MAB and deployment elec-
tronics. During the flight MABs were deployed in a specially constructed rack. These deployments were recorded
and analyzed after the flight.

The main mission of the experiment is: "Verification of the deployment of the Modular Antenna Boxes of the
Delfi-C3 in microgravity"

After a trade-off it was decided to choose the rack as experiment setup. This configuration keeps the design
simple and makes observations easy. Furthermore the perturbations are not expected to interfere with the experi-
ment setup.

One of the lessons learned was that the integration phase is a very critical for the deployment performance of
the MABs. Furthermore the MAB and its components are very small in size and easily damaged or assembled in
the wrong way.

During the first flight the experiment was executed almost exactly as scripted. However the antenna deploy-
ment did not go as smooth as expected. Not all antennas deployed and the ones that did took longer than was
observed on the ground. Changes made in the burning program and integration procedures could not improve the
performance.

During the 2 flights a total of 48 deployment attempts were made, 23 of which can be considered successful.
Of the unsuccessful deployments 1/3 was caused by integration errors or a wire next to the resistors, 1/3 could not
be determined due to deployment at ICB interchange and 1/3 were caused by a error in the deployment system.
With the proper improvement in the integration process the first group of errors can be eliminated. Further exper-
iments should be able to track down what caused the second group to deploy later. Redesign and reconfiguration
of deployment of the system should be done in order to eliminate the final group.

The experiment has generated a large amount of very useful data about the performance of the antenna deployment
system. In general it can be concluded that at this time there is a lack of reliability in the system. The system is not
robust enough at this time and more testing must be done in order to check if the performance can be increased.
Even though integration errors were made there still are to much incidences in which the failed deployment can
not be solely explained by saying that the system was not put together properly. Some failures can not be com-
pletely explained at this time. The fact that some antennas simply get stuck on themselves seems to be inherent to
the system. There should be more extensive tests to determine how large the chance actually is and how it can be
minimized. These tests will also determine if it is inherent to only the short antenna. Also further ground testing
in the recent weeks has shown that sometimes the antenna just does not deploy.
Appendix E
Delfi-C3 Verification Activities

This appendix contains the documentation related to the Manufacturing, Assembly, Integration and Verification of
the InterConnect Boards. It contains the following elements:
• ICB Testplan
• ICB Test Result Report
• List of verification and troubleshooting activities
• Current deploy sequence for Delfi-C3 depoyables
E.1 InterConnect Board Testplan

54
 Document DC3-TP-702-008
Date 26-02-2007
Test Plan Issue 1
Page 1

Distribution Title
R.J. Hamann ICB Test Plan
A.R. Bonnema
H.J de Graaf
Delfi-C3 archive

Summary

This document contains the test plan for the verification of the ICB Z- and Z+ boards. This test plan
comprises of the tests and test procedures to be performed up to integration. Furthermore the document will
provide a clear overview on the procedures by which the ICB should be handled and tested. This document
will also be used as a template in which test results are noted.

Keywords: ICB, Test Specification, Test Plan, Delfi-C3

Name Unit Date Signature

Written February 26,
J. Elstak TUD/AE/SIS
2007
Checked
A.R. Bonnema TUD/AE/SIS
Approved
R.J. Hamann TUD/AE/SIS

©2006. All rights reserved. Disclosure to third parties of this document or any part thereof, or the use of DC3-TP-702-008 - TP-
any information contained therein for purposes other than provided for by this document, is not permitted, ICB testing 23-03-
except prior and express written permission of Delft University of Technology, Aerospace Engineering. 2007.doc
 Document DC3-TP-702-008
Date 26-02-2007
Test Plan Issue 1
Page 2

Revision Record

issue date total Author affected brief description of change

pages pages

1 <date> J. Elstak All First issue

2 22-03-2007 J. ELstak All Second issue
- test template adapted
- test sequence updated

List of TBD’s and TBC’s

TBC/TBD Paragraph Subject Due date Action by

5.1 What software program is used for health check + RK/JE
deploy times of table
5.3 CoM tool GB
5.4 Geometric reference board BV/JE
5.5 Stack mockup specifications and MAB mounting GB
manual
5.7,6.7,7.2 OBC deployment software for PICs and OBC JB, RK
ICE software refereces
Robustnes verification RK, JE

©2006. All rights reserved. Disclosure to third parties of this document or any part thereof, or the use of DC3-TP-702-008 - TP-
any information contained therein for purposes other than provided for by this document, is not permitted, ICB testing 23-03-
except prior and express written permission of Delft University of Technology, Aerospace Engineering. 2007.doc
 Document DC3-TP-702-008
Date 26-02-2007
Test Plan Issue 1
Page 3

Table of contents

1. INTRODUCTION 5

2. ICB Z- VS. ICB Z+ 6

3. TEST RESOURCES 7

3.1 Locations 7

3.2 Equipment 7
3.2.1 Mechanical equipment 7
3.2.2 Environmental control equipment 7
3.2.3 Electrical measuring equipment 7
3.2.4 Electrical stimulating equipment 8

4. ICB Z- HANDLING PROCEDURES 9

4.1 General handling 9

4.2 Connecting to the board 9

4.2.1 PIC Programming connectors (J1/J2) 10
4.2.2 MAB Connectors (J5/J6/J7/J8) 10
4.2.3 Solar Panel connectors (J9/J10) 11
4.2.4 Data Bus (J14) 12
4.2.5 Solar Panel Power Connectors (J15/J16) 12
4.2.6 RF connectors (RF1-RF6) 13
4.2.7 Pin Savers 14

4.3 ICB Status Board (ISB) 15

4.4 Powering the board 15

5. TEST PROCEDURES ICB Z- PCBS 17

5.1 Health Check 18

5.2 Mass Verification 20

5.3 Center of Mass Verification 21

5.4 ICB Z- Envelope Determining 22

5.5 ICB Z- Test Fit 23

5.6 Functional Verification OBM Mode 24

5.7 Functional Verification OBC Mode 27

5.8 RF Testing 29

5.9 Thermal Testing 31

©2006. All rights reserved. Disclosure to third parties of this document or any part thereof, or the use of DC3-TP-702-008 - TP-
any information contained therein for purposes other than provided for by this document, is not permitted, ICB testing 23-03-
except prior and express written permission of Delft University of Technology, Aerospace Engineering. 2007.doc
 Document DC3-TP-702-008
Date 26-02-2007
Test Plan Issue 1
Page 4

6. TEST PROCEDURES ICB Z+ PCBS 34

6.1 Health Check 35

6.2 Mass Verification 37

6.3 Center of Mass Verification 38

6.4 ICB Z+ Envelope Determining 39

6.5 ICB Z+ Test Fit 40

6.6 Functional Verification OBM Mode 41

6.7 Functional Verification OBC Mode 44

6.8 RF Testing 46

7. TEST PROCEDURES COMBINED ICB Z- AND Z+ TESTING 48

7.1 Functional Verification OBM Mode 49

7.2 Functional Verification OBC Mode 52

8. FUTURE ACTIVITIES 54

REFERENCES 55

DC3-TP-612-004 55

APPENDIX A: TEST FLOW DIAGRAM 56

APPENDIX B: THERMAL TEST FORM 59

DESIGN DATA CONTROL SHEET 61

8.1 Input data used 61

8.2 Output data generated 61

8.3 References 61

DOCUMENT INPUT SHEET 62

©2006. All rights reserved. Disclosure to third parties of this document or any part thereof, or the use of DC3-TP-702-008 - TP-
any information contained therein for purposes other than provided for by this document, is not permitted, ICB testing 23-03-
except prior and express written permission of Delft University of Technology, Aerospace Engineering. 2007.doc
 Document DC3-TP-702-008
Date 26-02-2007
Test Plan Issue 1
Page 5

1. Introduction

The InterConnect Boards on the Delfi-C3 satellite form a key node in the communication system and release
mechanism structure of the satellite. It holds and controls the release wiring for the solar panels and
antennas. Next to that it passes the radio signal through from the stack to the antennas and vice versa. It is
the main interface between the satellite stack and the mechanisms and communication system.

This Test Plan provides the framework within which the ICBs will be tested and verified to comply with the
requirements. The time schedule for the tests can be found on the forum under subsystems/ICB Z-.

The document is structured in such a way that there is a clear distinction between the Z- and Z+ testing.
Although these boards are relatively similar it is important to keep the verification procedures clearly
separated in order to prevent unclarities. Also the combined testing of ICB Z+ and Z- is specified separate.

©2006. All rights reserved. Disclosure to third parties of this document or any part thereof, or the use of DC3-TP-702-008 - TP-
any information contained therein for purposes other than provided for by this document, is not permitted, ICB testing 23-03-
except prior and express written permission of Delft University of Technology, Aerospace Engineering. 2007.doc
 Document DC3-TP-702-008
Date 26-02-2007
Test Plan Issue 1
Page 6

2. ICB Z- vs. ICB Z+

The Delfi-C3 satellite has two ICBs, ICB Z- and Z+. Although both boards have the same basic functionality
they are slightly separate in layout and functionality. This fact makes it very important to keep the procedures
separated to prevent confusion about the ICBs. Figure 2.1 shows the prints of both ICB next to each other. At
a first glance they seem similar but when examined closely the layout differences can be seen. These
differences can cause unclarities about pin layouts, connector positions and component positions and
therefore there are two completely different verification sets for ICB Z- and Z+

Figure 2.1: ICB Z- and ICB Z+ print comparison

©2006. All rights reserved. Disclosure to third parties of this document or any part thereof, or the use of DC3-TP-702-008 - TP-
any information contained therein for purposes other than provided for by this document, is not permitted, ICB testing 23-03-
except prior and express written permission of Delft University of Technology, Aerospace Engineering. 2007.doc
 Document DC3-TP-702-008
Date 26-02-2007
Test Plan Issue 1
Page 7

3. Test Resources

In the next chapter a brief overview of the different test resources is given. These resources can be divided
into three categories: locations, equipment, and personnel.

3.1 Locations

At a basic level, only two locations will be used for performing the subsystem level tests of the Electrical
Power Subsystem board. These are:

EEMCS
Delft University of Technology, Faculty of Electrical Engineering, Mathematics, and Computer
Sciences, 18th floor

AE
Delft University of Technology, Faculty of Aerospace Engineering, 8th floor, room 8.01

3.2 Equipment

In order to successfully perform tests on the ICB boards, various measuring and stimulating equipment has to
be used. These are briefly described in the following sections.

3.2.1 Mechanical equipment

Ruler
This device is a commonly available simple ruler, which can be used for determining dimensions of
geometrical bodies. It is available at both EEMCS and AE.

Scales
This device is a commonly available set of digital scales, which can be used for determining the mass
of a geometrical body. It is available at both EEMCS and AE.

3.2.2 Environmental control equipment

Thermal vacuum chamber

This facility is a confined environment, which can be pumped vacuum on demand. Furthermore, the
temperature of this environment can be raised above nominal room temperature. For these reasons,
it can be applied to test the ICB board for functional operation in vacuum and high temperature
conditions. This facility is available at AE.

Thermal Chamber
The aircraft hall houses a thermal chamber that can be used to cool and heat the PCB. This setup can
be used for thermal cycling of the PCB.

3.2.3 Electrical measuring equipment

Digital multimeter

©2006. All rights reserved. Disclosure to third parties of this document or any part thereof, or the use of DC3-TP-702-008 - TP-
any information contained therein for purposes other than provided for by this document, is not permitted, ICB testing 23-03-
except prior and express written permission of Delft University of Technology, Aerospace Engineering. 2007.doc
 Document DC3-TP-702-008
Date 26-02-2007
Test Plan Issue 1
Page 8

This device is a commonly available simple digital multimeter, which can be used for measuring DC
voltages and currents. It is restricted to measuring only a single quantity at a time, but can be flexibly
applied for quick checks of voltages and currents. It is available at both EEMCS and AE.

Oscilloscope

This device is a commonly used oscilloscope, which can be used to visualize voltages and currents in
the time domain. An available oscilloscope is the Fluke PM3082, which has four channels. This means
it is able to measure and visualize four signals at a time. It is available at both EEMCS and AE.

3.2.4 Electrical stimulating equipment

12V DC Power supply

This device is a generic direct current power supply. It can be calibrated to generate a 12V DC supply
for powering electronic equipment. However, the delivered current is limited by a maximum. It is
available both at EEMCS and AE.

ICB Stimuli Board (ISB)

This board is used to simulate the solar panels and antenna boxes. The ICB can be connected to the
ISB and the burn sequence is then visualized through LEDs on the board. Furthermore the individual
TACT switches can be switch open and closed through simple switches on the ISB.

©2006. All rights reserved. Disclosure to third parties of this document or any part thereof, or the use of DC3-TP-702-008 - TP-
any information contained therein for purposes other than provided for by this document, is not permitted, ICB testing 23-03-
except prior and express written permission of Delft University of Technology, Aerospace Engineering. 2007.doc
 Document DC3-TP-702-008
Date 26-02-2007
Test Plan Issue 1
Page 9

4. ICB Z- handling procedures

First the general handling of the board and the ways in which to connect to the board will be discussed.

4.1 General handling

The person who handles the board should always take precautions against ESD. For this reason they should
be grounded when handling the board. The board should also be kept in a clean environment in order to
prevent contamination. When working on components on the board gloves should be worn to prevent
contamination.

4.2 Connecting to the board

When connecting the board pin-savers should be used. There are several different points on the board that
can be connected to. Figure 4.1 shows the position of all connectors on the board. Each will be shortly
described here:

4.1: position of all connectors on the board

©2006. All rights reserved. Disclosure to third parties of this document or any part thereof, or the use of DC3-TP-702-008 - TP-
any information contained therein for purposes other than provided for by this document, is not permitted, ICB testing 23-03-
except prior and express written permission of Delft University of Technology, Aerospace Engineering. 2007.doc
 Document DC3-TP-702-008
Date 26-02-2007
Test Plan Issue 1
Page 10

4.2.1 PIC Programming connectors (J1/J2)

These connectors are used to program the PICs they are shown in figure 4.2

Figure 4.2: J1/J2 PIC programming connectors

4.2.2 MAB Connectors (J5/J6/J7/J8)

These connectors are connected to the MABs and transmit the burn signals and the TACT signal. Figure 4.3
shows these connectors and their pinsavers.

Caution: The connectors are not fool proof and can be connected the wrong way. Remember
that the yellow connector wire should always be pointing to the outmost corner of the
connector. Figure 4.5 shows this connection method.

Figure 4.3: J5/J6/J7/J8 MAB connectors

©2006. All rights reserved. Disclosure to third parties of this document or any part thereof, or the use of DC3-TP-702-008 - TP-
any information contained therein for purposes other than provided for by this document, is not permitted, ICB testing 23-03-
except prior and express written permission of Delft University of Technology, Aerospace Engineering. 2007.doc
 Document DC3-TP-702-008
Date 26-02-2007
Test Plan Issue 1
Page 11

4.2.3 Solar Panel connectors (J9/J10)

These connectors are used for the release commands and TACT switch readout of the solar panels. Figure 4.4
shows these connectors and their pinsavers.

Figure 4.4: J9/J10 Solar panel connectors

Figure 4.5: J5/J6/J7/J8 connection scheme

©2006. All rights reserved. Disclosure to third parties of this document or any part thereof, or the use of DC3-TP-702-008 - TP-
any information contained therein for purposes other than provided for by this document, is not permitted, ICB testing 23-03-
except prior and express written permission of Delft University of Technology, Aerospace Engineering. 2007.doc
 Document DC3-TP-702-008
Date 26-02-2007
Test Plan Issue 1
Page 12

4.2.4 Data Bus (J14)

This connector connects the ICB with the rest of the satellite. There is a throughput pin saver in the
connector to which connection can be made. Figure 4.6 shows this connector.

Figure 4.6: J14 Data bus connector

4.2.5 Solar Panel Power Connectors (J15/J16)

These connectors are used to throughput the power from the solar cells to the bus. Figure 4.7 shows the
connector and the pin savers connected to them.

Caution: The pins on these two connectors are mirrored and not identical. Please consult the
drawings when connecting power through these pins

Figure 4.7: J15/J16 Solar panel power connector

©2006. All rights reserved. Disclosure to third parties of this document or any part thereof, or the use of DC3-TP-702-008 - TP-
any information contained therein for purposes other than provided for by this document, is not permitted, ICB testing 23-03-
except prior and express written permission of Delft University of Technology, Aerospace Engineering. 2007.doc
 Document DC3-TP-702-008
Date 26-02-2007
Test Plan Issue 1
Page 13

Figure 4.8: All connectors minus the data bus connector positioned on the board

4.2.6 RF connectors (RF1-RF6)

These connectors are used for connecting the radio signals from the inside of the satellite to the antennas.
RF5 and RF6 are located on the Z+ side of the board, the other 4 are located on the Z- side of the board. A
coax line will be used to connect the two sets of connectors. Figure 4.9 shows the connectors.

Caution: RF1-4 are connected to the MABs. The way in which these are connected is not ‘logical’ due to the
requirements on the polarity of the signals and the phase regulators. Figure 4.10 shows how the connection
should be made in the end.

Figure 4.9: RF1-6 RF connectors

©2006. All rights reserved. Disclosure to third parties of this document or any part thereof, or the use of DC3-TP-702-008 - TP-
any information contained therein for purposes other than provided for by this document, is not permitted, ICB testing 23-03-
except prior and express written permission of Delft University of Technology, Aerospace Engineering. 2007.doc
 Document DC3-TP-702-008
Date 26-02-2007
Test Plan Issue 1
Page 14

Figure 4.10: RF1-4 to MAB connections

4.2.7 Pin Savers

In order to connect to the board several pinsavers are used. These are shown in figure 4.11

©2006. All rights reserved. Disclosure to third parties of this document or any part thereof, or the use of DC3-TP-702-008 - TP-
any information contained therein for purposes other than provided for by this document, is not permitted, ICB testing 23-03-
except prior and express written permission of Delft University of Technology, Aerospace Engineering. 2007.doc
 Document DC3-TP-702-008
Date 26-02-2007
Test Plan Issue 1
Page 15

Figure 4.11: Picture of the different pinsavers (Left Top: programming; Right Top: Solar Power; Bottom:
MAB)

4.3 ICB Status Board (ISB)

The ISB is used to visualize the resistor burning. Figure xxx shows the layout of the board. The lower
markings show which connector should be connected to which location on the board.

Figure 4.12

4.4 Powering the board

When the board is power the following steps have to be taken

1. Connect the electrical scheme as can be seen in figure 4.12; However do not connect the power to the
ICB board yet
2. Switch on the power supply and regulate the voltage down to 0
3. Connect the power connector to the data bus connector (J14)
4. Carefully screw the voltage up to 12 V.

©2006. All rights reserved. Disclosure to third parties of this document or any part thereof, or the use of DC3-TP-702-008 - TP-
any information contained therein for purposes other than provided for by this document, is not permitted, ICB testing 23-03-
except prior and express written permission of Delft University of Technology, Aerospace Engineering. 2007.doc
 Document DC3-TP-702-008
Date 26-02-2007
Test Plan Issue 1
Page 16

Figure 4.13: Power Connection scheme for the ICB

In order to check the board the voltage on the test pins can be measured. The following data should be
found:

TP1 = 3.3 V (U2 voltage) Notice the switch around; TP1 measures U2 voltage and vice versa
TP2 = 3.3 V (U1 voltage)
TP3 = 12 V (RA supply voltage)
TP4 = 12 V (RB supply voltage)
TP5 = 5 V (driver supply VCC2)
TP6 = 5 V (driver supply VCC1)

The position of these TP’s can be found in figure 4.1. When the PICs need to be programmed there needs to
be an extra 12V line on the PIC. This voltage is supplies by the programming connector. When that is done
the board is ready for use

©2006. All rights reserved. Disclosure to third parties of this document or any part thereof, or the use of DC3-TP-702-008 - TP-
any information contained therein for purposes other than provided for by this document, is not permitted, ICB testing 23-03-
except prior and express written permission of Delft University of Technology, Aerospace Engineering. 2007.doc
 Document DC3-TP-702-008
Date 26-02-2007
Test Plan Issue 1
Page 17

5. Test Procedures ICB Z- PCBs

PCB ID #:

This section describes the different tests that will be done for the verification of ICB Z-.

©2006. All rights reserved. Disclosure to third parties of this document or any part thereof, or the use of DC3-TP-702-008 - TP-
any information contained therein for purposes other than provided for by this document, is not permitted, ICB testing 23-03-
except prior and express written permission of Delft University of Technology, Aerospace Engineering. 2007.doc
 Document DC3-TP-702-008
Date 26-02-2007
Test Plan Issue 1
Page 18

Software Version: …
5.1 Health Check
Block #
Purpose: Checking ICB health before and after each test
Corresponding requirement:
Personnel: JE
Location: AE (CR)
Equipment: ICB Z- board, Stimuli board, power supply, ICB data bus cable, multimeter

Action: Values/remarks

5.1A: Setup

1. Without attaching the data bus and the probing voltmeter 01

to the board, connect the setup according to figure 4.13

2. Connect the ISB to the ICB (section 4.2.2 and 4.2.3 and 02
4.3)

3. Switch on the power supply and turn the voltage down to 03

0
04
4. Connect the programmer to the power supply
05
5. Connect the data bus to the ICB (section 4.2.4)

6. Increase the power to 12 V 06

5.1B: Checkout: V= [REF: 3.3V]

07
7. Measure and note TP1 Voltage using probe
08 V= [REF: 3.3V]
8. Measure and note TP2 Voltage using probe
09 V= [REF: 12V]
9. Measure and note TP3 Voltage using probe
10 V= [REF: 12V]
10. Measure and note TP4 Voltage using probe
11
V= [REF: 5V]
11. Measure and note TP5 Voltage using probe
12
V= [REF: 5V]
12. Measure and note TP6 Voltage using probe
13
13. Connect the programmer to the U1 pinsaver and program
U1 with REF program [TBD]
14
14. Connect the programmer to the U2 pinsaver and program
U2 with REF program [TBD]
15
15. Disconnect the program cable from the pinsaver
16
16. Disconnect the power from the board by manually
disconnecting the power cable from the data bus from the
power supply
17

©2006. All rights reserved. Disclosure to third parties of this document or any part thereof, or the use of DC3-TP-702-008 - TP-
any information contained therein for purposes other than provided for by this document, is not permitted, ICB testing 23-03-
except prior and express written permission of Delft University of Technology, Aerospace Engineering. 2007.doc
 Document DC3-TP-702-008
Date 26-02-2007
Test Plan Issue 1
Page 19

17. Boot the board by plugging the power connector back into
the power supply
18 Primary PIC (RA)
18. Visually verify that all deploy resistors burn as specifies by / t_start t_stop
the software [TBD] 0 5 SP_Z-Y-
5 10 SP_Z-Y+
10 15 M_Z-X-
15 20 M_Z-X+
20 25 M_Z-Y-
25 30 M_Z-Y+
Secondary PIC (RB)
t_start t_stop
30 35 SP_Z-Y-
35 40 SP_Z-Y+
40 45 M_Z-X-
45 50 M_Z-X+
50 55 M_Z-Y-
55 60 M_Z-Y+

5.1C: Breakdown:
19
19. Decrease the power to 0 V
20
20. Disconnect the data bus cable
21
21. Switch the power supply off
22
22. Disconnect the ISB connectors

Notes: The Health Check has 3 components: Setup(A), Check-out (B) and Breakdown and (C). This is done so
other tests can use the Health Check without having to disassemble and reassemble the setup before testing
commences (5.1AB) or can perform the Health Check in the testsetup (5.1BC)

Signature
Test Date: …

Test Executor: …

©2006. All rights reserved. Disclosure to third parties of this document or any part thereof, or the use of DC3-TP-702-008 - TP-
any information contained therein for purposes other than provided for by this document, is not permitted, ICB testing 23-03-
except prior and express written permission of Delft University of Technology, Aerospace Engineering. 2007.doc
 Document DC3-TP-702-008
Date 26-02-2007
Test Plan Issue 1
Page 20

Software Version: …
5.2 Mass Verification
Block 1
Purpose: Determining mass of ICB Z- board
Corresponding requirement:
Personnel: JE
Location: AE (CR)
Equipment: ICB Z- board, accurate scales

Action: Values/remarks

1. Perform Health Check as specified in 5.1ABC 01

2. Turn on scales 02

3. Remove all pinsavers and stands from the ICB and put 03
the ICB board on the scales

4. Read and note the value for its mass from the scales 04 Mass: [76.83 grams]

5. Turn off scales. 05

6. Remount the pinsavers and stands to the board. 06

7. Perform a health check as specified in 5.1ABC 07

8. Staple the test form and the health check forms 08

together and put them in the DC3-FM-STA-100 file

Notes: Test is performed to ensure compliance of the ICB Z- board to the Delfi-C3 mass budget

Signature
Test Date: …

Test Executor: …

©2006. All rights reserved. Disclosure to third parties of this document or any part thereof, or the use of DC3-TP-702-008 - TP-
any information contained therein for purposes other than provided for by this document, is not permitted, ICB testing 23-03-
except prior and express written permission of Delft University of Technology, Aerospace Engineering. 2007.doc
 Document DC3-TP-702-008
Date 26-02-2007
Test Plan Issue 1
Page 21

Software Version: …
5.3 Center of Mass Verification
Block 2
Purpose: Determining Centre of Mass of ICB Z- board
Corresponding requirement:
Personnel: JE, GB
Location: AE (CR)
Equipment: ICB Z- board, CoM tool

Action: Values/remarks

1. Perform Health Check as specified in 5.1ABC 01

2. Turn on tool [TBD] 02

3. Put ICB board on tool for measuring X_com 03

4. Read and note the value for X_com 04 X_CoM: [mm]

5. Put ICB board on tool for measuring Y_com 05

6. Read and note the value for Y_com 06 Y_CoM: [mm]

7. Put ICB board on tool for measuring Z_com 07

8. Read and note the value for Z_com 08 Z_CoM: [mm]

9. Turn off tool 09

10. Perform Health Check as specified in 5.1ABC 10

11. Staple the test form and the health check forms 11
together and put them in the DC3-FM-STA-100 file

Notes:

Signature
Test Date: …

Test Executor: …

©2006. All rights reserved. Disclosure to third parties of this document or any part thereof, or the use of DC3-TP-702-008 - TP-
any information contained therein for purposes other than provided for by this document, is not permitted, ICB testing 23-03-
except prior and express written permission of Delft University of Technology, Aerospace Engineering. 2007.doc
 Document DC3-TP-702-008
Date 26-02-2007
Test Plan Issue 1
Page 22

Software Version: …
5.4 ICB Z- Envelope Determining
Block 3
Purpose: Determining geometrical dimensions of ICB Z- board
Corresponding requirement:
Personnel: JE
Location: AE (CR)
Equipment: Unpopulated ICB Z- board, PCB geometric verification board

Action: Values/remarks

1. Take an unpopulated ICB Z- 01

2. Put this ICB Z- on the verified PCB in the CR [TBD] 02

3. Check whether the external dimensions match 03

4. Check whether the hole distances match 04

5. Stow the boards 05

6. Put the test form in the DC3-FM-STA-100 file 06

Notes: Test is performed to ensure compliance to the allotted envelope of the ICB Z- board in the printed circuit
board stack

Signature
Test Date: …

Test Executor: …

©2006. All rights reserved. Disclosure to third parties of this document or any part thereof, or the use of DC3-TP-702-008 - TP-
any information contained therein for purposes other than provided for by this document, is not permitted, ICB testing 23-03-
except prior and express written permission of Delft University of Technology, Aerospace Engineering. 2007.doc
 Document DC3-TP-702-008
Date 26-02-2007
Test Plan Issue 1
Page 23

Software Version: …
5.5 ICB Z- Test Fit
Block 4
Purpose: Verifying that the board fits in the stack
Corresponding
requirement: JE
Personnel: AE (CR)
Location: ICB Z- board, stack mockup, MAB mockups (4x)
Equipment:

Action: Values/remarks

1. Perform Health Check as specified in 5.1ABC 01

2. Place the MABs on the ICB (REF TBD) 02

3. Place the ICB into the stack mockup (REF TBD) 03

4. Verify that the ICB fits and that all access points are 04
available (REF TBD)

5. Dismount the setup 05

6. Remove the MABs from the ICB 06

7. Perform Health Check as specified in 5.1ABC 07

8. Staple the test form and the health check forms 08

together and put them in the DC3-FM-STA-100 file

Signature
Test Date: …

Test Executor: …

©2006. All rights reserved. Disclosure to third parties of this document or any part thereof, or the use of DC3-TP-702-008 - TP-
any information contained therein for purposes other than provided for by this document, is not permitted, ICB testing 23-03-
except prior and express written permission of Delft University of Technology, Aerospace Engineering. 2007.doc
 Document DC3-TP-702-008
Date 26-02-2007
Test Plan Issue 1
Page 24

Software Version: …
5.6 Functional Verification
OBM Mode Block 5

Purpose: Determining the functionality of the OBM mode of ICB Z-

Corresponding requirement:
Personnel: JE, RK
Location: AE (CR)
Equipment: ICB Z- board, power supply, computer, programmer, multimeters (3x),
stopwatch, stimuliboard

Action: Values/remarks

1. Perform Health Check as specified in 5.1AB 01 Run 1: Primary PIC

t_start t_stop t_start t_stop
2. Program U1 with flight OBM software 02
10 22 SP_Z-Y-
03 76 88 SP_Z-Y+
3. Program U2 with flight OBM software
88 100 M_Z-X-
4. Start OBM mode by disconnecting and 04 100 112 M_Z-X+
reconnecting the power cable to the board 112 124 M_Z-Y-
124 136 M_Z-Y+
5. Note the deployment times for t he first run of 05 Seconday PIC
ICB Z-
t_start t_stop t_start t_stop
326 338 SP_Z-Y-
679 691 SP_Z-Y+
691 703 M_Z-X-
703 715 M_Z-X+
715 727 M_Z-Y-
727 739 M_Z-Y+
921 s< Deployment < 1272 s

Run 2: Primary PIC

6. Repeat step 4-5 for the second run 06 t_start t_stop t_start t_stop
10 22 SP_Z-Y-
76 88 SP_Z-Y+
88 100 M_Z-X-
100 112 M_Z-X+
112 124 M_Z-Y-
124 136 M_Z-Y+
Seconday PIC
t_start t_stop t_start t_stop
326 338 SP_Z-Y-
679 691 SP_Z-Y+
691 703 M_Z-X-
703 715 M_Z-X+
715 727 M_Z-Y-
727 739 M_Z-Y+
921 s< Deployment < 1272 s

©2006. All rights reserved. Disclosure to third parties of this document or any part thereof, or the use of DC3-TP-702-008 - TP-
any information contained therein for purposes other than provided for by this document, is not permitted, ICB testing 23-03-
except prior and express written permission of Delft University of Technology, Aerospace Engineering. 2007.doc
 Document DC3-TP-702-008
Date 26-02-2007
Test Plan Issue 1
Page 25

7. Repeat step 4-5 for the third run 07 Run 3: Primary PIC
t_start t_stop t_start t_stop
10 22 SP_Z-Y-
76 88 SP_Z-Y+
88 100 M_Z-X-
100 112 M_Z-X+
112 124 M_Z-Y-
124 136 M_Z-Y+
Seconday PIC
t_start t_stop t_start t_stop
326 338 SP_Z-Y-
679 691 SP_Z-Y+
691 703 M_Z-X-
703 715 M_Z-X+
715 727 M_Z-Y-
727 739 M_Z-Y+
921 s< Deployment < 1272 s

8. Repeat step 4-5 for the fourth run 08

Run 4: Primary PIC
t_start t_stop t_start t_stop
10 22 SP_Z-Y-
76 88 SP_Z-Y+
88 100 M_Z-X-
100 112 M_Z-X+
112 124 M_Z-Y-
124 136 M_Z-Y+
Seconday PIC
t_start t_stop t_start t_stop
326 338 SP_Z-Y-
679 691 SP_Z-Y+
691 703 M_Z-X-
703 715 M_Z-X+
715 727 M_Z-Y-
727 739 M_Z-Y+
921 s< Deployment < 1272 s

©2006. All rights reserved. Disclosure to third parties of this document or any part thereof, or the use of DC3-TP-702-008 - TP-
any information contained therein for purposes other than provided for by this document, is not permitted, ICB testing 23-03-
except prior and express written permission of Delft University of Technology, Aerospace Engineering. 2007.doc
 Document DC3-TP-702-008
Date 26-02-2007
Test Plan Issue 1
Page 26

9. Repeat step 4-5 for the fifth run 09 Run 5: Primary PIC
t_start t_stop t_start t_stop
10. Perform Health Check as specified in 5.1BC 10 10 22 SP_Z-Y-
76 88 SP_Z-Y+
11. Staple the test form and the health check forms 11 88 100 M_Z-X-
together and put them in the DC3-FM-STA-100 100 112 M_Z-X+
file 112 124 M_Z-Y-
124 136 M_Z-Y+
Seconday PIC
t_start t_stop t_start t_stop
326 338 SP_Z-Y-
679 691 SP_Z-Y+
691 703 M_Z-X-
703 715 M_Z-X+
715 727 M_Z-Y-
727 739 M_Z-Y+
921 s< Deployment < 1272 s

Notes:

Signature
Test Date: …

Test Executor: …

©2006. All rights reserved. Disclosure to third parties of this document or any part thereof, or the use of DC3-TP-702-008 - TP-
any information contained therein for purposes other than provided for by this document, is not permitted, ICB testing 23-03-
except prior and express written permission of Delft University of Technology, Aerospace Engineering. 2007.doc
 Document DC3-TP-702-008
Date 26-02-2007
Test Plan Issue 1
Page 27

Software Version: …
5.7 Functional Verification
OBC Mode Block 6

Purpose: Determining the functionality of the OBC mode of ICB Z-

Corresponding requirement:
Personnel: JE, RK, HG
Location: AE (CR)
Equipment: ICB Z- board, power supply, computer, programmer, multimeters (3x),
stopwatch, stimuliboard

Action: Values/remarks

1. Perform Health Check as specified in 5.1AB 01

2. Connect and power ICE 02

3. Program U1 with flight software 03

4. Program U2 with flight software 04

5. Send deployment commands through ICE (TBD 05

with RK)
06
6. Send command 2
07
7. Send command 3
08
8. Send command 4
09
9. Check correct sequence for RA and RB with
stimuliboard

10. Switch TACT SP_Y- 10

11. Read out PIC and verify registration 11

12. Switch TACT SP_Y+ 12

13. Read out PIC and verify registration 13

14. Switch TACT M_Y- 14

15. Read out PIC and verify registration 15

16. Switch TACT M_Y+ 16

17. Read out PIC and verify registration 17

18. Switch TACT M_X- 18

19. Read out PIC and verify registration 19

20. Switch TACT M_X+ 20

©2006. All rights reserved. Disclosure to third parties of this document or any part thereof, or the use of DC3-TP-702-008 - TP-
any information contained therein for purposes other than provided for by this document, is not permitted, ICB testing 23-03-
except prior and express written permission of Delft University of Technology, Aerospace Engineering. 2007.doc
 Document DC3-TP-702-008
Date 26-02-2007
Test Plan Issue 1
Page 28

21. Read out PIC and verify registration 21

22. Readout PICs (TBD with RK) 22

23. Perform Health Check as specified in 5.1BC 23

24. Staple the test form and the health check forms 24
together and put them in the DC3-FM-STA-100
file

Notes:

Signature
Test Date: …

Test Executor: …

©2006. All rights reserved. Disclosure to third parties of this document or any part thereof, or the use of DC3-TP-702-008 - TP-
any information contained therein for purposes other than provided for by this document, is not permitted, ICB testing 23-03-
except prior and express written permission of Delft University of Technology, Aerospace Engineering. 2007.doc
 Document DC3-TP-702-008
Date 26-02-2007
Test Plan Issue 1
Page 29

Software Version: …
5.8 RF Testing
Block 7
Purpose: Verifying the correct working of the RF connections on the ICB Z- board
Corresponding requirement:
Personnel: JE, WU
Location: DIMES
Equipment: ICB Z- board + transport container, Vector Network Analyzer (VNA) + cables,
terminated in SMA-M, 5 50 ohm terminations, 2 SMA-M SMA-F pin savers, 4
MCX-M SMA-F adapters / pin savers, Gloves,
2 ESD wrist straps, ESD bench mat (TBD)

Action: Values/remarks

1. Perform Health Check as specified in 5.1ABC 01

2. Calibrate VNA + cables at 435.6MHz using a cal set

(short, open, load) 02

3. Hybrid isolation (S12 port 1 to 2, all other ports

terminated in 50 ohm 03

4. Return loss / S11 port 1, all other ports terminated in

50 ohm 04

5. Return loss / S11 port 2, all other ports terminated in

50 ohm 05

6. S12 port 1 to MAB Z-X+ port, all other ports

terminated in 50 ohm 06

7. phase port 1 to MAB Z-X+ port, all other ports

terminated in 50 ohm 07

8. S12 port 1 to MAB Z-X- port, all other ports

terminated in 50 ohm 08

9. phase port 1 to MAB Z-X- port, all other ports

terminated in 50 ohm 09

10. S12 port 1 to MAB Z-Y+ port, all other ports

terminated in 50 ohm 10

11. phase port 1 to MAB Z-Y+ port, all other ports

terminated in 50 ohm 11

12. S12 port 1 to MAB Z-Y- port, all other ports

terminated in 50 ohm 12

13. phase port 1 to MAB Z-Y- port, all other ports

terminated in 50 ohm 13

14. S12 port 2 to MAB Z-X+ port, all other ports

terminated in 50 ohm 14

©2006. All rights reserved. Disclosure to third parties of this document or any part thereof, or the use of DC3-TP-702-008 - TP-
any information contained therein for purposes other than provided for by this document, is not permitted, ICB testing 23-03-
except prior and express written permission of Delft University of Technology, Aerospace Engineering. 2007.doc
 Document DC3-TP-702-008
Date 26-02-2007
Test Plan Issue 1
Page 30

15. phase port 2 to MAB Z-X+ port, all other ports

terminated in 50 ohm 15

16. S12 port 2 to MAB Z-X- port, all other ports

terminated in 50 ohm 16

17. phase port 2 to MAB Z-X- port, all other ports

terminated in 50 ohm 17

18. S12 port 2 to MAB Z-Y+ port, all other ports

terminated in 50 ohm 18

19. phase port 2 to MAB Z-Y+ port, all other ports

terminated in 50 ohm 19

20. S12 port 2 to MAB Z-X- port, all other ports

terminated in 50 ohm 20

21. phase port 2 to MAB Z-X- port, all other ports

terminated in 50 ohm 21

22. S12 port 1 to MABZ-X+ at 145.900MHz, all other

ports terminated in 50 ohm

23. Perform Health Check as specified in 5.1ABC

24. Staple the test form and the health check forms
together and put them in the DC3-FM-STA-100 file

Notes: Test frequency: 435.600 MHz (sweep over 433.6-437.6 MHz, include plots with test parameters as
function of frequency for every test).

Note that the phase measured is in degrees, and S parameters in dB

Note furthermore that the actual absolute phase shift measured from the reference planes of the VNA between
the input and output ports of the board differs from the measured ones due to the phase shift introduced by the
additional length of the pin savers. This is not an issue, however, since only the relative phase shift between the
MAB ports is of importance.

Signature
Test Date: …

Test Executor: …

©2006. All rights reserved. Disclosure to third parties of this document or any part thereof, or the use of DC3-TP-702-008 - TP-
any information contained therein for purposes other than provided for by this document, is not permitted, ICB testing 23-03-
except prior and express written permission of Delft University of Technology, Aerospace Engineering. 2007.doc
 Document DC3-TP-702-008
Date 26-02-2007
Test Plan Issue 1
Page 31

Software Version: …
5.9 Thermal Testing
Block 8
Purpose: Verifying the functionality of the board in all operating conditions
Corresponding requirement:
Personnel: JE, GB
Location: AE (Vliegtuighal)
Equipment: ICB Z- board, power supply, stimuliboard, thermal chamber, multimeters (3x),
stopwatch, wiring, thermocouples (2x), thermocouple reader

Action: Values/remarks

1. Perform Health Check as specified in 5.1ABC 01

2. Print Appendix B and note all required values there 02

during the test

3. Place 2 thermocouples on the board with LTT, each 03

on one side

4. Setup the board in the thermal chamber, connect the 04

power cable, ISB and TP connectors.

5. Guide all the wiring out off the chamber 05

6. Connect the thermocouples to the reader 06

7. Connect the TP1 connector to a multimeter and 07

ground this meter to the ‘–‘ side of the power supply.
Put the meter on Volts.

8. Perform a Health Check as specified in 5.1AB and fill 08

in the form

9. Heat the oven to 5 degrees above ambient 09

temperature and close the door

10. Perform a Health Check as specified in 5.1B and fill in 10

the form

11. Switch system off 11

12. Heat to 45 degrees 12

13. Wait for 3 minutes after both thermocouples register 13

45 degrees

14. Perform a Health Check as specified in 5.1B and fill in 14

the form

15. Cool the oven to -25 degrees 15

16. Wait for 3 minutes after both thermocouples register 16

-25 degrees

©2006. All rights reserved. Disclosure to third parties of this document or any part thereof, or the use of DC3-TP-702-008 - TP-
any information contained therein for purposes other than provided for by this document, is not permitted, ICB testing 23-03-
except prior and express written permission of Delft University of Technology, Aerospace Engineering. 2007.doc
 Document DC3-TP-702-008
Date 26-02-2007
Test Plan Issue 1
Page 32

17. Perform a Health Check as specified in 5.1B and fill in 17

the form

18. Switch the power off 18

19. Repeat step 10 - 17 6 times 19

20. Heat to 45 degrees 20

21. Wait for 3 minutes after both thermocouples register 21

45 degrees

22. Perform a Health Check as specified in 5.1B and fill in 22

the form

23. Switch the power off 23

24. Heat to 60 degrees 24

25. Wait for 3 minutes after both thermocouples register 25

60 degrees

26. Cool down to 45 degrees 26

27. Perform a Health Check as specified in 5.1B and fill in 27

the form

28. switch the power off 28

29. Cool the oven to -25 degrees 29

30. Wait for 3 minutes after both thermocouples register 30

-25 degrees

31. Perform a Health Check as specified in 5.1B and fill in 31

the form

32. Switch power off 32

33. Cool down to -40 degrees 33

34. Wait for 3 minutes after both thermocouples register 34

-40 degrees

35. Heat back to -25 degrees 35

36. Perform a Health Check as specified in 5.1B and fill in 36

the form

37. Switch the power off 37

38. Heat the oven to 5 degrees above ambient 38

temperature and let the setup stand for 5 minutes

39. Open the door and remove the setup 39

©2006. All rights reserved. Disclosure to third parties of this document or any part thereof, or the use of DC3-TP-702-008 - TP-
any information contained therein for purposes other than provided for by this document, is not permitted, ICB testing 23-03-
except prior and express written permission of Delft University of Technology, Aerospace Engineering. 2007.doc
 Document DC3-TP-702-008
Date 26-02-2007
Test Plan Issue 1
Page 33

40. Perform Health Check as specified in 5.1BC 40

Notes: It is important that the oven is warmer than the ambient temperature when the door is open to prevent
water vapor from condensing in the oven.

Signature
Test Date: …

Test Executor: …

©2006. All rights reserved. Disclosure to third parties of this document or any part thereof, or the use of DC3-TP-702-008 - TP-
any information contained therein for purposes other than provided for by this document, is not permitted, ICB testing 23-03-
except prior and express written permission of Delft University of Technology, Aerospace Engineering. 2007.doc
 Document DC3-TP-702-008
Date 26-02-2007
Test Plan Issue 1
Page 34

6. Test Procedures ICB Z+ PCBs

PCB ID #:

This section describes the different tests that will be done for the verification of ICB Z+.

©2006. All rights reserved. Disclosure to third parties of this document or any part thereof, or the use of DC3-TP-702-008 - TP-
any information contained therein for purposes other than provided for by this document, is not permitted, ICB testing 23-03-
except prior and express written permission of Delft University of Technology, Aerospace Engineering. 2007.doc
 Document DC3-TP-702-008
Date 26-02-2007
Test Plan Issue 1
Page 35

Software Version: …
6.1 Health Check
Block 9
Purpose: Checking ICB health before and after each test
Corresponding requirement:
Personnel: JE
Location: AE (CR)
Equipment: ICB Z+ board, Stimuli board, power supply, ICB data bus cable, multimeter

Action: Values/remarks

6.1A: Setup

1. Without attaching the data bus and the probing voltmeter 01

to the board, connect the setup according to figure 4.13

2. Connect the ISB to the ICB (section 4.2.2 and 4.2.3 and 02
4.3)

3. Switch on the power supply and turn the voltage down to 0 03

4. Connect the programmer to the power supply 04

5. Connect the data bus to the ICB (section 4.2.4) 05

6. Increase the power to 12 V

06
6.1B: Checkout:

07 V= [REF: 3.3V]
7. Measure and note TP1 Voltage using probe
08 V= [REF: 3.3V]
8. Measure and note TP2 Voltage using probe

9. Measure and note TP3 Voltage using probe 09 V= [REF: 12V]

10. Measure and note TP4 Voltage using probe 10 V= [REF: 12V]

11. Measure and note TP5 Voltage using probe 11

V= [REF: 5V]

12. Measure and note TP6 Voltage using probe 12

V= [REF: 5V]
13. Connect the programmer to the U1 pinsaver and program 13
U1 with REF program [TBD]

14. Connect the programmer to the U2 pinsaver and program 14

U2 with REF program [TBD]

15. Disconnect the program cable from the pinsaver 15

16. Disconnect the power from the board by manually 16

disconnecting the power cable from the data bus from the
power supply

©2006. All rights reserved. Disclosure to third parties of this document or any part thereof, or the use of DC3-TP-702-008 - TP-
any information contained therein for purposes other than provided for by this document, is not permitted, ICB testing 23-03-
except prior and express written permission of Delft University of Technology, Aerospace Engineering. 2007.doc
 Document DC3-TP-702-008
Date 26-02-2007
Test Plan Issue 1
Page 36

17. Boot the board by plugging the power connector back into 17
the power supply
Primary PIC (RA)
18. Visually verify that all deploy resistors burn as specifies by 18
the software [TBD] / t_start t_stop
0 5 SP_Z+X-
5 10 SP_Z+X+
10 15 M_Z+X-
15 20 M_Z+X+
20 25 M_Z+Y-
25 30 M_Z+Y+
Secondary PIC (RB)
t_start t_stop
30 35 SP_Z+X-
35 40 SP_Z+X+
40 45 M_Z+X-
45 50 M_Z+X+
50 55 M_Z+Y-
6.1C: Breakdown: 55 60 M_Z+Y+

19. Decrease the power to 0 V 19

20. Disconnect the data bus cable 20

21. Switch the power supply off 21

22. Disconnect the ISB connectors 22

Notes: The Health Check has 3 components: Setup(A), Check-out (B) and Breakdown and (C). This is done so other
tests can use the Health Check without having to disassemble and reassemble the setup before testing commences
(6.1AB) or can perform the Health Check in the testsetup (6.1BC)

Signature
Test Date: …

Test Executor: …

©2006. All rights reserved. Disclosure to third parties of this document or any part thereof, or the use of DC3-TP-702-008 - TP-
any information contained therein for purposes other than provided for by this document, is not permitted, ICB testing 23-03-
except prior and express written permission of Delft University of Technology, Aerospace Engineering. 2007.doc
 Document DC3-TP-702-008
Date 26-02-2007
Test Plan Issue 1
Page 37

Software Version: …
6.2 Mass Verification
Block 10
Purpose: Determining mass of ICB Z+ board
Corresponding requirement:
Personnel: JE
Location: AE (CR)
Equipment: ICB Z+ board, accurate scales

Action: Values/remarks

9. Perform Health Check as specified in 6.1ABC 01

10. Turn on scales 02

11. Remove all pinsavers and stands from the ICB and put 03
the ICB board on the scales

12. Read and note the value for its mass from the scales 04 Mass: [72.83 grams]

13. Turn off scales. 05

14. Remount the pinsavers and stands to the board. 06

15. Perform a health check as specified in 6.1ABC 07

16. Staple the test form and the health check forms 08
together and put them in the DC3-FM-STA-900 file

Notes: Test is performed to ensure compliance of the ICB Z+ board to the Delfi-C3 mass budget

Signature
Test Date: …

Test Executor: …

©2006. All rights reserved. Disclosure to third parties of this document or any part thereof, or the use of DC3-TP-702-008 - TP-
any information contained therein for purposes other than provided for by this document, is not permitted, ICB testing 23-03-
except prior and express written permission of Delft University of Technology, Aerospace Engineering. 2007.doc
 Document DC3-TP-702-008
Date 26-02-2007
Test Plan Issue 1
Page 38

Software Version: …
6.3 Center of Mass Verification
Block 11
Purpose: Determining Centre of Mass of ICB Z+ board
Corresponding requirement:
Personnel: JE, GB
Location: AE (CR)
Equipment: ICB Z+ board, CoM tool

Action: Values/remarks

12. Perform Health Check as specified in 6.1ABC 01

13. Turn on tool [TBD] 02

14. Put ICB board on tool for measuring X_com 03

15. Read and note the value for X_com 04 X_CoM: [mm]

16. Put ICB board on tool for measuring Y_com 05

17. Read and note the value for Y_com 06 Y_CoM: [mm]

18. Put ICB board on tool for measuring Z_com 07

19. Read and note the value for Z_com 08 Z_CoM: [mm]

20. Turn off tool 09

21. Perform Health Check as specified in 6.1ABC 10

22. Staple the test form and the health check forms 11
together and put them in the DC3-FM-STA-900 file

Notes:

Signature
Test Date: …

Test Executor: …

©2006. All rights reserved. Disclosure to third parties of this document or any part thereof, or the use of DC3-TP-702-008 - TP-
any information contained therein for purposes other than provided for by this document, is not permitted, ICB testing 23-03-
except prior and express written permission of Delft University of Technology, Aerospace Engineering. 2007.doc
 Document DC3-TP-702-008
Date 26-02-2007
Test Plan Issue 1
Page 39

Software Version: …
6.4 ICB Z+ Envelope Determining
Block 12
Purpose: Determining geometrical dimensions of ICB Z+ board
Corresponding
requirement: JE
Personnel: AE (CR)
Location: Unpopulated ICB Z+ board, PCB geometric verification board
Equipment:

Action: Values/remarks

7. Take an unpopulated ICB Z+ 01

8. Put this ICB Z+ on the verified PCB in the CR [TBD] 02

9. Check whether the external dimensions match 03

10. Check whether the hole distances match 04

11. Stow the boards 05

12. Put the test form in the DC3-FM-STA-900 file 06

Notes: Test is performed to ensure compliance to the allotted envelope of the ICB Z+ board in the printed
circuit board stack

Signature
Test Date: …

Test Executor: …

©2006. All rights reserved. Disclosure to third parties of this document or any part thereof, or the use of DC3-TP-702-008 - TP-
any information contained therein for purposes other than provided for by this document, is not permitted, ICB testing 23-03-
except prior and express written permission of Delft University of Technology, Aerospace Engineering. 2007.doc
 Document DC3-TP-702-008
Date 26-02-2007
Test Plan Issue 1
Page 40

Software Version: …
6.5 ICB Z+ Test Fit
Block 13
Purpose: Verifying that the board fits in the stack
Corresponding
requirement: JE
Personnel: AE (CR)
Location: ICB Z+ board, stack mockup, MAB mockups (4x)
Equipment:

Action: Values/remarks

9. Perform Health Check as specified in 6.1ABC 01

10. Place the MABs on the ICB (REF TBD) 02

11. Place the ICB into the stack mockup (REF TBD) 03

12. Verify that the ICB fits and that all access points are 04
available (REF TBD)

13. Dismount the setup 05

14. Remove the MABs from the ICB 06

15. Perform Health Check as specified in 6.1ABC 07

16. Staple the test form and the health check forms 08
together and put them in the DC3-FM-STA-900 file

Signature
Test Date: …

Test Executor: …

©2006. All rights reserved. Disclosure to third parties of this document or any part thereof, or the use of DC3-TP-702-008 - TP-
any information contained therein for purposes other than provided for by this document, is not permitted, ICB testing 23-03-
except prior and express written permission of Delft University of Technology, Aerospace Engineering. 2007.doc
 Document DC3-TP-702-008
Date 26-02-2007
Test Plan Issue 1
Page 41

Software Version: …
6.6 Functional Verification
OBM Mode Block 14

Purpose: Determining the functionality of the OBM mode of ICB Z+

Corresponding requirement:
Personnel: JE, RK
Location: AE (CR)
Equipment: ICB Z+ board, power supply, computer, programmer, multimeters (3x),
stopwatch, stimuliboard

Action: Values/remarks

01 Run 1: Primary PIC

12. Perform Health Check as specified in 6.1AB
t_start t_stop t_start t_stop
13. Program U1 with flight OBM software 02 31 43 SP_Z+X-
43 55 SP_Z+X+
14. Program U2 with flight OBM software 03 188 200 M_Z+X-
200 212 M_Z+X+
15. Start OBM mode by disconnecting and 04
212 224 M_Z+Y-
reconnecting the power cable to the board
224 236 M_Z+Y+
16. Note the deployment times for t he first run of 05 Seconday PIC
ICB Z+ t_start t_stop t_start t_stop
467 479 SP_Z+X-
479 491 SP_Z+X+
1021 1033 M_Z+X-
1033 1045 M_Z+X+
1045 1057 M_Z+Y-
1057 1069 M_Z+Y+
921 s< Deployment < 1272 s
Run 2: Primary PIC
t_start t_stop t_start t_stop
17. Repeat step 4-5 for the second run 06 31 43 SP_Z+X-
43 55 SP_Z+X+
188 200 M_Z+X-
200 212 M_Z+X+
212 224 M_Z+Y-
224 236 M_Z+Y+
Seconday PIC
t_start t_stop t_start t_stop
467 479 SP_Z+X-
479 491 SP_Z+X+
1021 1033 M_Z+X-
1033 1045 M_Z+X+
1045 1057 M_Z+Y-
1057 1069 M_Z+Y+
921 s< Deployment < 1272 s

©2006. All rights reserved. Disclosure to third parties of this document or any part thereof, or the use of DC3-TP-702-008 - TP-
any information contained therein for purposes other than provided for by this document, is not permitted, ICB testing 23-03-
except prior and express written permission of Delft University of Technology, Aerospace Engineering. 2007.doc
 Document DC3-TP-702-008
Date 26-02-2007
Test Plan Issue 1
Page 42

18. Repeat step 4-5 for the third run 07

Run 3: Primary PIC
t_start t_stop t_start t_stop
31 43 SP_Z+X-
43 55 SP_Z+X+
188 200 M_Z+X-
200 212 M_Z+X+
212 224 M_Z+Y-
224 236 M_Z+Y+
Seconday PIC
t_start t_stop t_start t_stop
467 479 SP_Z+X-
479 491 SP_Z+X+
1021 1033 M_Z+X-
1033 1045 M_Z+X+
1045 1057 M_Z+Y-
1057 1069 M_Z+Y+
921 s< Deployment < 1272 s

19. Repeat step 4-5 for the fourth run 08 Run 4: Primary PIC
t_start t_stop t_start t_stop
31 43 SP_Z+X-
43 55 SP_Z+X+
188 200 M_Z+X-
200 212 M_Z+X+
212 224 M_Z+Y-
224 236 M_Z+Y+
Seconday PIC
t_start t_stop t_start t_stop
467 479 SP_Z+X-
479 491 SP_Z+X+
1021 1033 M_Z+X-
1033 1045 M_Z+X+
1045 1057 M_Z+Y-
1057 1069 M_Z+Y+
921 s< Deployment < 1272 s

©2006. All rights reserved. Disclosure to third parties of this document or any part thereof, or the use of DC3-TP-702-008 - TP-
any information contained therein for purposes other than provided for by this document, is not permitted, ICB testing 23-03-
except prior and express written permission of Delft University of Technology, Aerospace Engineering. 2007.doc
 Document DC3-TP-702-008
Date 26-02-2007
Test Plan Issue 1
Page 43

Run 5: Primary PIC

20. Repeat step 4-5 for the fifth run 09 t_start t_stop t_start t_stop
31 43 SP_Z+X-
21. Perform Health Check as specified in 6.1BC 10 43 55 SP_Z+X+
188 200 M_Z+X-
22. Staple the test form and the health check forms 11
together and put them in the DC3-FM-STA-900 200 212 M_Z+X+
file 212 224 M_Z+Y-
224 236 M_Z+Y+
Seconday PIC
t_start t_stop t_start t_stop
467 479 SP_Z+X-
479 491 SP_Z+X+
1021 1033 M_Z+X-
1033 1045 M_Z+X+
1045 1057 M_Z+Y-
1057 1069 M_Z+Y+
921 s< Deployment < 1272 s

Notes:

Signature
Test Date: …

Test Executor: …

©2006. All rights reserved. Disclosure to third parties of this document or any part thereof, or the use of DC3-TP-702-008 - TP-
any information contained therein for purposes other than provided for by this document, is not permitted, ICB testing 23-03-
except prior and express written permission of Delft University of Technology, Aerospace Engineering. 2007.doc
 Document DC3-TP-702-008
Date 26-02-2007
Test Plan Issue 1
Page 44

Software Version: …
6.7 Functional Verification
OBC Mode Block 15

Purpose: Determining the functionality of the OBC mode of ICB Z+

Corresponding requirement:
Personnel: JE, RK, HG
Location: AE (CR)
Equipment: ICB Z+ board, power supply, computer, programmer, multimeters (3x),
stopwatch, stimuliboard

Action: Values/remarks

25. Perform Health Check as specified in 6.1AB 01

26. Connect and power ICE (ref) 02

27. Program U1 with flight software 03

28. Program U2 with flight software 04

29. Send deployment commands through ICE (TBD 05

with RK)
06
30. Send command 2
07
31. Send command 3
08
32. Send command 4
09
33. Check correct sequence for RA and RB with
stimuliboard

34. Switch TACT SP_Y- 10

35. Read out PIC and verify registration 11

36. Switch TACT SP_Y+ 12

37. Read out PIC and verify registration 13

38. Switch TACT M_Y- 14

39. Read out PIC and verify registration 15

40. Switch TACT M_Y+ 16

41. Read out PIC and verify registration 17

42. Switch TACT M_X- 18

43. Read out PIC and verify registration 19

44. Switch TACT M_X+ 20

©2006. All rights reserved. Disclosure to third parties of this document or any part thereof, or the use of DC3-TP-702-008 - TP-
any information contained therein for purposes other than provided for by this document, is not permitted, ICB testing 23-03-
except prior and express written permission of Delft University of Technology, Aerospace Engineering. 2007.doc
 Document DC3-TP-702-008
Date 26-02-2007
Test Plan Issue 1
Page 45

45. Read out PIC and verify registration 21

46. Readout PICs (TBD with RK) 22

47. Perform Health Check as specified in 6.1BC 23

48. Staple the test form and the health check forms 24
together and put them in the DC3-FM-STA-900
file

Notes:

Signature
Test Date: …

Test Executor: …

©2006. All rights reserved. Disclosure to third parties of this document or any part thereof, or the use of DC3-TP-702-008 - TP-
any information contained therein for purposes other than provided for by this document, is not permitted, ICB testing 23-03-
except prior and express written permission of Delft University of Technology, Aerospace Engineering. 2007.doc
 Document DC3-TP-702-008
Date 26-02-2007
Test Plan Issue 1
Page 46

Software Version: …
6.8 RF Testing
Block 16
Purpose: Verifying the correct working of the RF connections on the ICB Z+ board
Corresponding requirement:
Personnel: JE, WU
Location: DIMES
Equipment: ICB Z+ board + transport container, Vector Network Analyzer (VNA) + cables,
terminated in SMA-M, 5 50 ohm terminations, 2 SMA-M SMA-F pin savers, 4
MCX-M SMA-F adapters / pin savers, Gloves,
2 ESD wrist straps, ESD bench mat (TBD)

Action: Values/remarks

25. Perform Health Check as specified in 6.1ABC 01

26. Calibrate VNA + cables at 435.6MHz using a cal set

(short, open, load) 02

27. Hybrid isolation (S12 port 1 to 2, all other ports

terminated in 50 ohm 03

28. Return loss / S11 port 1, all other ports terminated in

50 ohm 04

29. Return loss / S11 port 2, all other ports terminated in

50 ohm 05

30. S12 port 1 to MAB Z+X+ port, all other ports

terminated in 50 ohm 06

31. phase port 1 to MAB Z+X+ port, all other ports

terminated in 50 ohm 07

32. S12 port 1 to MAB Z+X- port, all other ports

terminated in 50 ohm 08

33. phase port 1 to MAB Z+X- port, all other ports

terminated in 50 ohm 09

34. S12 port 1 to MAB Z+Y+ port, all other ports

terminated in 50 ohm 10

35. phase port 1 to MAB Z+Y+ port, all other ports

terminated in 50 ohm 11

36. S12 port 1 to MAB Z+Y- port, all other ports

terminated in 50 ohm 12

37. phase port 1 to MAB Z+Y- port, all other ports

terminated in 50 ohm 13

38. S12 port 2 to MAB Z+X+ port, all other ports

terminated in 50 ohm 14

©2006. All rights reserved. Disclosure to third parties of this document or any part thereof, or the use of DC3-TP-702-008 - TP-
any information contained therein for purposes other than provided for by this document, is not permitted, ICB testing 23-03-
except prior and express written permission of Delft University of Technology, Aerospace Engineering. 2007.doc
 Document DC3-TP-702-008
Date 26-02-2007
Test Plan Issue 1
Page 47

39. phase port 2 to MAB Z+X+ port, all other ports

terminated in 50 ohm 15

40. S12 port 2 to MAB Z+X- port, all other ports

terminated in 50 ohm 16

41. phase port 2 to MAB Z+X- port, all other ports

terminated in 50 ohm 17

42. S12 port 2 to MAB Z+Y+ port, all other ports

terminated in 50 ohm 18

43. phase port 2 to MAB Z+Y+ port, all other ports

terminated in 50 ohm 19

44. S12 port 2 to MAB Z+X- port, all other ports

terminated in 50 ohm 20

45. phase port 2 to MAB Z+X- port, all other ports

terminated in 50 ohm 21

46. S12 port 1 to MABZ+X+ at 145.900MHz, all other

ports terminated in 50 ohm

47. Perform Health Check as specified in 6.1ABC

48. Staple the test form and the health check forms
together and put them in the DC3-FM-STA-900 file

Notes: Test frequency: 435.600 MHz (sweep over 433.6-437.6 MHz, include plots with test parameters as
function of frequency for every test).

Note that the phase measured is in degrees, and S parameters in dB

Note furthermore that the actual absolute phase shift measured from the reference planes of the VNA between
the input and output ports of the board differs from the measured ones due to the phase shift introduced by the
additional length of the pin savers. This is not an issue, however, since only the relative phase shift between the
MAB ports is of importance.

Signature
Test Date: …

Test Executor: …

©2006. All rights reserved. Disclosure to third parties of this document or any part thereof, or the use of DC3-TP-702-008 - TP-
any information contained therein for purposes other than provided for by this document, is not permitted, ICB testing 23-03-
except prior and express written permission of Delft University of Technology, Aerospace Engineering. 2007.doc
 Document DC3-TP-702-008
Date 26-02-2007
Test Plan Issue 1
Page 48

7. Test Procedures Combined ICB Z- and Z+ Testing

PCB IDs #:

This section describes the different tests that will be done for the verification of ICB Z+.

©2006. All rights reserved. Disclosure to third parties of this document or any part thereof, or the use of DC3-TP-702-008 - TP-
any information contained therein for purposes other than provided for by this document, is not permitted, ICB testing 23-03-
except prior and express written permission of Delft University of Technology, Aerospace Engineering. 2007.doc
 Document DC3-TP-702-008
Date 26-02-2007
Test Plan Issue 1
Page 49

Software Version: …
7.1 Functional Verification
OBM Mode Block 17

Purpose: Determining the functionality of the OBM mode of ICB Z+ and ICB Z-
Corresponding requirement:
Personnel: JE, RK
Location: AE (CR)
Equipment: ICB Z+ board, power supply, computer, programmer, multimeters (3x),
stopwatch, stimuliboard

Action: Values/remarks

1. Perform Health Check for ICB Z- as specified in 01

5.1AB

2. Perform Health Check for ICB Z+ as specified in 02 Run 1

6.1AB
/ Primary PIC (RA)
3. Program U1 with flight software 03 10 22 SP_Z-Y-
31 43 SP_Z+X-
4. Program U2 with flight software 04 43 55 SP_Z+X+
76 88 SP_Z-Y+
5. Power off the boards (removing ICB power pin 05 88 100 M_Z-X-
from power supply) 100 112 M_Z-X+
06 112 124 M_Z+Y-
6. Power on the boards
124 136 M_Z+Y+
7. Check correct sequence for RA and RB with 07 188 200 M_Z+X-
stimuliboard and fill in the table for run1 200 212 M_Z+X+
212 224 M_Z+Y-
224 236 M_Z+Y+
Seconday PIC (RB)
326 338 SP_Z-Y-
467 479 SP_Z+X-
479 491 SP_Z+X+
679 691 SP_Z-Y+
691 703 M_Z-X-
703 715 M_Z-X+
715 727 M_Z-Y-
727 739 M_Z-Y+
1021 1033 M_Z+X-
1033 1045 M_Z+X+
1045 1057 M_Z+Y-
1057 1069 M_Z+Y+
921 s< Deployment < 1272 s

©2006. All rights reserved. Disclosure to third parties of this document or any part thereof, or the use of DC3-TP-702-008 - TP-
any information contained therein for purposes other than provided for by this document, is not permitted, ICB testing 23-03-
except prior and express written permission of Delft University of Technology, Aerospace Engineering. 2007.doc
 Document DC3-TP-702-008
Date 26-02-2007
Test Plan Issue 1
Page 50

8. Repeat step 5-7 for run 2 08

9. Repeat step 5-7 for run 3 09

10. Repeat step 5-7 for run 4 10

Run 2 Run 3 Run 4
/ Primary PIC (RA) / Primary PIC (RA) / Primary PIC (RA)
10 22 SP_Z-Y- 10 22 SP_Z-Y- 10 22 SP_Z-Y-
31 43 SP_Z+X- 31 43 SP_Z+X- 31 43 SP_Z+X-
43 55 SP_Z+X+ 43 55 SP_Z+X+ 43 55 SP_Z+X+
76 88 SP_Z-Y+ 76 88 SP_Z-Y+ 76 88 SP_Z-Y+
88 100 M_Z-X- 88 100 M_Z-X- 88 100 M_Z-X-
100 112 M_Z-X+ 100 112 M_Z-X+ 100 112 M_Z-X+
112 124 M_Z+Y- 112 124 M_Z+Y- 112 124 M_Z+Y-
124 136 M_Z+Y+ 124 136 M_Z+Y+ 124 136 M_Z+Y+
188 200 M_Z+X- 188 200 M_Z+X- 188 200 M_Z+X-
200 212 M_Z+X+ 200 212 M_Z+X+ 200 212 M_Z+X+
212 224 M_Z+Y- 212 224 M_Z+Y- 212 224 M_Z+Y-
224 236 M_Z+Y+ 224 236 M_Z+Y+ 224 236 M_Z+Y+
Seconday PIC (RB) Seconday PIC (RB) Seconday PIC (RB)
326 338 SP_Z-Y- 326 338 SP_Z-Y- 326 338 SP_Z-Y-
467 479 SP_Z+X- 467 479 SP_Z+X- 467 479 SP_Z+X-
479 491 SP_Z+X+ 479 491 SP_Z+X+ 479 491 SP_Z+X+
679 691 SP_Z-Y+ 679 691 SP_Z-Y+ 679 691 SP_Z-Y+
691 703 M_Z-X- 691 703 M_Z-X- 691 703 M_Z-X-
703 715 M_Z-X+ 703 715 M_Z-X+ 703 715 M_Z-X+
715 727 M_Z-Y- 715 727 M_Z-Y- 715 727 M_Z-Y-
727 739 M_Z-Y+ 727 739 M_Z-Y+ 727 739 M_Z-Y+
1021 1033 M_Z+X- 1021 1033 M_Z+X- 1021 1033 M_Z+X-
1033 1045 M_Z+X+ 1033 1045 M_Z+X+ 1033 1045 M_Z+X+
1045 1057 M_Z+Y- 1045 1057 M_Z+Y- 1045 1057 M_Z+Y-
1057 1069 M_Z+Y+ 1057 1069 M_Z+Y+ 1057 1069 M_Z+Y+
921 s< Deployment < 1272 s 921 s< Deployment < 1272 s 921 s< Deployment < 1272 s

11. Perform Health Check for ICB Z- as specified in 11

5.1BC

12. Perform Health Check for ICB Z+ as specified in 12

6.1BC

13. Staple the test form and the health check forms 13
together and put them in the DC3-FM-STA-100
(ICB Z-) and DC3-FM-STA-900 (ICB Z+) file

Notes:

Signature
Test Date: …

©2006. All rights reserved. Disclosure to third parties of this document or any part thereof, or the use of DC3-TP-702-008 - TP-
any information contained therein for purposes other than provided for by this document, is not permitted, ICB testing 23-03-
except prior and express written permission of Delft University of Technology, Aerospace Engineering. 2007.doc
 Document DC3-TP-702-008
Date 26-02-2007
Test Plan Issue 1
Page 51

Test Executor: …

©2006. All rights reserved. Disclosure to third parties of this document or any part thereof, or the use of DC3-TP-702-008 - TP-
any information contained therein for purposes other than provided for by this document, is not permitted, ICB testing 23-03-
except prior and express written permission of Delft University of Technology, Aerospace Engineering. 2007.doc
 Document DC3-TP-702-008
Date 26-02-2007
Test Plan Issue 1
Page 52

Software Version: …
7.2 Functional Verification
OBC Mode Block 18

Purpose: Determining the functionality of the OBC mode of ICB Z+ and Z-

Corresponding requirement:
Personnel: JE, RK, HG
Location: AE (CR)
Equipment: ICB Z+ board, ICB Z- board, power supply, computer, programmer,
multimeters (3x), stopwatch, stimuliboard Z+, stimuliboard Z-

Action: Values/remarks

1. Perform Health Check as specified in 5.1 01

2. Power the boards according to the specifications 02

3. Connect the stimuli boards 03

4. Connect and power ICE (ref) 04

5. Check the TP voltages 05

6. Program U1 06

7. Program U2 07

8. Send commands through ICE (TBD with RK) 08

9. Check correct sequence for RA and RB with 09

stimuliboard

10. Use the TACT switches 10

11. Readout PICs (TBD with RK) 11

12. Perform Health Check as specified in 5.1 12

Notes:

Signature
Test Date: …

Test Executor: …

©2006. All rights reserved. Disclosure to third parties of this document or any part thereof, or the use of DC3-TP-702-008 - TP-
any information contained therein for purposes other than provided for by this document, is not permitted, ICB testing 23-03-
except prior and express written permission of Delft University of Technology, Aerospace Engineering. 2007.doc
 Document DC3-TP-702-008
Date 26-02-2007
Test Plan Issue 1
Page 53

Robustness Verification

©2006. All rights reserved. Disclosure to third parties of this document or any part thereof, or the use of DC3-TP-702-008 - TP-
any information contained therein for purposes other than provided for by this document, is not permitted, ICB testing 23-03-
except prior and express written permission of Delft University of Technology, Aerospace Engineering. 2007.doc
 Document DC3-TP-702-008
Date 26-02-2007
Test Plan Issue 1
Page 54

8. Future activities

In the coming weeks the subsystem level tests will be performed. After this the ICBs will be integrated in the
satellite for acceptance testing.

©2006. All rights reserved. Disclosure to third parties of this document or any part thereof, or the use of DC3-TP-702-008 - TP-
any information contained therein for purposes other than provided for by this document, is not permitted, ICB testing 23-03-
except prior and express written permission of Delft University of Technology, Aerospace Engineering. 2007.doc
 Document DC3-TP-702-008
Date 26-02-2007
Test Plan Issue 1
Page 55

References

DC3-TP-612-004

©2006. All rights reserved. Disclosure to third parties of this document or any part thereof, or the use of DC3-TP-702-008 - TP-
any information contained therein for purposes other than provided for by this document, is not permitted, ICB testing 23-03-
except prior and express written permission of Delft University of Technology, Aerospace Engineering. 2007.doc
 Document DC3-TP-702-008
Date 26-02-2007
Test Plan Issue 1
Page 56

Appendix A: Test Flow Diagram

©2006. All rights reserved. Disclosure to third parties of this document or any part thereof, or the use of DC3-TP-702-008 - TP-
any information contained therein for purposes other than provided for by this document, is not permitted, ICB testing 23-03-
except prior and express written permission of Delft University of Technology, Aerospace Engineering. 2007.doc
 Document DC3-TP-702-008
Date 26-02-2007
Test Plan Issue 1
Page 57

©2006. All rights reserved. Disclosure to third parties of this document or any part thereof, or the use of DC3-TP-702-008 - TP-
any information contained therein for purposes other than provided for by this document, is not permitted, ICB testing 23-03-
except prior and express written permission of Delft University of Technology, Aerospace Engineering. 2007.doc
 Document DC3-TP-702-008
Date 26-02-2007
Test Plan Issue 1
Page 58

©2006. All rights reserved. Disclosure to third parties of this document or any part thereof, or the use of DC3-TP-702-008 - TP-
any information contained therein for purposes other than provided for by this document, is not permitted, ICB testing 23-03-
except prior and express written permission of Delft University of Technology, Aerospace Engineering. 2007.doc
 Document DC3-TP-702-008
Date 26-02-2007
Test Plan Issue 1
Page 59

Appendix B: Thermal Test Form

Prescibed Measured MAB X- MAB X+ MAB Y- MAB Y+ SP Y- SP Y+ TP U1 TP U2
Cycle # T_chamber T_Tc1 T_Tc2 T_chamber T_Tc1 T_Tc2 2 3 6 1 4 5
test
1 25 25 25
2 45 45 45
3 -25 -25 -25
4 45 45 45
5 -25 -25 -25
6 45 45 45
7 -25 -25 -25
8 45 45 45
9 -25 -25 -25
10 45 45 45
11 -25 -25 -25
12 45 45 45
13 -25 -25 -25
14 45 45 45
15 -25 -25 -25
16 45 45 45
17 60 60 60
18 45 45 45
19 -25 -25 -25
20 -40 -40 -40
21 -25 -25 -25
22 25 25 25

©2006. All rights reserved. Disclosure to third parties of this document or any part thereof, or the use of DC3-TP-702-008 - TP-
any information contained therein for purposes other than provided for by this document, is not permitted, ICB testing 23-03-
except prior and express written permission of Delft University of Technology, Aerospace Engineering. 2007.doc
 Document DC3-TP-702-008
Date 26-02-2007
Test Plan Issue 1
Page 60

Thermal Test Temperature Overview

80

60

40
Temperature (deg C)

20

0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

-20

-40

-60
cycle

©2006. All rights reserved. Disclosure to third parties of this document or any part thereof, or the use of DC3-TP-702-008 - TP-
any information contained therein for purposes other than provided for by this document, is not permitted, ICB testing 23-03-
except prior and express written permission of Delft University of Technology, Aerospace Engineering. 2007.doc
 Document DC3-TP-702-008
Date 26-02-2007
Test Plan Issue 1
Page 61

Design Data Control Sheet

Created by: Name

Issue: 1 Issue date: dd-mmm-yyyy

Applicable Document
Name Document name SLR ###
Issue # Issue date: dd-mmm-yyyy

This sheet gives an overview of the input data for the applicable document and the generated output data of
this document. Please list all the inputs you have used for your analyses and the correct reference for these
inputs. Also, try to identify which documents use the output data that have been generated by the document
as inputs. Please include the Design Data Control Sheet in your document as an appendix.

8.1 Input data used

Parameter: Value: Source [SLR]:

8.2 Output data generated

Parameter: Value: Destination [SLR]:

8.3 References
SLR or Ref code: Title:

©2006. All rights reserved. Disclosure to third parties of this document or any part thereof, or the use of DC3-TP-702-008 - TP-
any information contained therein for purposes other than provided for by this document, is not permitted, ICB testing 23-03-
except prior and express written permission of Delft University of Technology, Aerospace Engineering. 2007.doc
 Document DC3-TP-702-008
Date 26-02-2007
Test Plan Issue 1
Page 62

Document Input Sheet

To: Author Date: dd-mmm-yyyy

Copy to: Delfi-C3 Systems Engineer DIS number: DC3-DIS-mmy-xx
Originator: Name

Document title: Document Name Document number: ###

Description of input:

Criticality:
[] urgent [] verification impact
[] prior to review [] software design impact
[] document consistency [] hardware design impact
[] cosmetic [] requirements impact

Rationale and objective:

Remarks:

Document Responsible:

Response of document
responsible

DDM processing status:

DDM Final check Date:

This document provides a means to communicate input on documents in such a way that requests and
questions are documented and traceable. If you for instance have a remark, found an error or question a part
of a document you can use this sheet to communicate your input to the author of the document. The author
will then evaluate the Document Input Sheet, compare the input with the document and update if necessary.
The person responsible will also inform both the author of the Document Input Sheet and the systems
engineer whether the input is processed and how.

©2006. All rights reserved. Disclosure to third parties of this document or any part thereof, or the use of DC3-TP-702-008 - TP-
any information contained therein for purposes other than provided for by this document, is not permitted, ICB testing 23-03-
except prior and express written permission of Delft University of Technology, Aerospace Engineering. 2007.doc
E.2 InterConnect Board Test Result Report

117
 Document DC3-TR-706-020
Date 20-06-2007
Test Results Report Issue 2
Page 1

Distribution Title
R.J. Hamann ICB Test Results Report
A.R. Bonnema
H.J de Graaf
Delfi-C3 archive

Summary

This document contains the test results for the verification of the ICB Z- and Z+ boards. Furthermore it
evaluates the test procedures used in the verification.

Keywords: ICB, Test Specification, Test Plan, Delfi-C3

Name Unit Date Signature

Written April 16,
J. Elstak TUD/AE/SIS
2007
Checked
A.R. Bonnema TUD/AE/SIS
Approved
R.J. Hamann TUD/AE/SIS

©2006. All rights reserved. Disclosure to third parties of this document or any part thereof, or the use of DC3-TR-706-020
any information contained therein for purposes other than provided for by this document, is not permitted,
except prior and express written permission of Delft University of Technology, Aerospace Engineering.
 Document DC3-TR-706-020
Date 20-06-2007
Test Results Report Issue 2
Page 2

Revision Record

issue date total Author affected brief description of change

pages pages

1 16-04-2007 4 J. Elstak All First issue

2 20-06-2007 13 J. Elstak All Secon Issue

List of TBD’s and TBC’s

TBC/TBD Paragraph Subject Due date Action by

©2006. All rights reserved. Disclosure to third parties of this document or any part thereof, or the use of DC3-TR-706-020
any information contained therein for purposes other than provided for by this document, is not permitted,
except prior and express written permission of Delft University of Technology, Aerospace Engineering.
 Document DC3-TR-706-020
Date 20-06-2007
Test Results Report Issue 2
Page 3

Table of contents

SUMMARY ............................................................................................................................. 1

TABLE OF CONTENTS.......................................................................................................... 3

1. INTRODUCTION ........................................................................................................... 4

2. VERIFICATION EVALUATION .................................................................................... 5

2.1 Handling Procedures ...............................................................................................................5

2.2 Verification Procedures ....................................................................................................6

2.3 Maturity Overviews ............................................................................................................7

3. TEST RESULTS SUMMARY .......................................................................................... 8

ICBZ-001 ..............................................................................................................................................9

ICBZ-002 ..........................................................................................................................................11

ICBZ-003 ..........................................................................................................................................13

ICBZ+001.........................................................................................................................................15

ICBZ+002.........................................................................................................................................17

ICBZ+003.........................................................................................................................................19

4. FLIGHT STATUS.......................................................................................................... 21

©2006. All rights reserved. Disclosure to third parties of this document or any part thereof, or the use of DC3-TR-706-020
any information contained therein for purposes other than provided for by this document, is not permitted,
except prior and express written permission of Delft University of Technology, Aerospace Engineering.
 Document DC3-TR-706-020
Date 20-06-2007
Test Results Report Issue 2
Page 4

1. Introduction

This document gives an overview of the test results for the ICBs. The results are displayed in the maturity
overview excel files that were generated during the verification process and comments will be given for each
board. Furthermore the verification process itself will be looked at. The handling procedures, verification
procedures and the configuration management will be evaluated and recommendations for future project will
be made.

Six ICBs were tested during the verification process. For both Z+ and Z- three versions were made. Initially it
was planned to make only two but due to extensive rework and redesign the first board of both Z- and Z+
was declared non flight.

©2006. All rights reserved. Disclosure to third parties of this document or any part thereof, or the use of DC3-TR-706-020
any information contained therein for purposes other than provided for by this document, is not permitted,
except prior and express written permission of Delft University of Technology, Aerospace Engineering.
 Document DC3-TR-706-020
Date 20-06-2007
Test Results Report Issue 2
Page 5

2. Verification Evaluation

2.1 Handling Procedures

For all hardware used that could be flight hardware handling procedures were defined:
• Use ESD protection while handling
• Handle with gloves,
• Use pinsavers on connectors
• Make sure the boards are distinquishable

The ESD protection was used throughout the procedures except when rework was performed on boards. The
same is valid for handling with gloves. The pinsavers are used to reduce the number of times that a
connector is cycled and reduces the chances of potential connector failure. However when rework on the
boards was done all pinsavers are removed. Furthermore often pinsavers got loose due to handling of the
boards. This results in a large amount of connector cycles to be made on the boards even though pinsavers
are used. Also making pinsavers is an exhaustive time consuming job. Therefore the use of pinsavers should
be reconsidered for the next satellite project. It is however important to key all connectors on the board. In
the current design the MAB connectors were not keyed and this made them prone for connection errors.

In order to distinquish between the boards a number of actions have been taken
• Each board was kept in a unique container
• Each board had its own unique logbook
• Each board was labeled
• Each board was permanently marked with glue

Each board has its own storage container that is marked with its identifier. In this container also the logbook
of that specific board is kept. This ensures that all the work performed on t he board is logged in the
accompanying logbook. The container is shown in the figure below.

ICB Z-002 in container with logbook ICBZ-002 board icontainer identification

©2006. All rights reserved. Disclosure to third parties of this document or any part thereof, or the use of DC3-TR-706-020
any information contained therein for purposes other than provided for by this document, is not permitted,
except prior and express written permission of Delft University of Technology, Aerospace Engineering.
 Document DC3-TR-706-020
Date 20-06-2007
Test Results Report Issue 2
Page 6

Initially all boards were labeled with a label on a wire. Because this marking could be broken and was not
permanent it was choosen to label each board with drops of glue on predetermined places on the board. The
number of drops indicates the version of the board. The labeling is shown in the picture below.

ICB Z-002 with databus pinsaver ICBZ-002 board identification marker

2.2 Verification Procedures

During the verification process of the ICBs a number of things were noticed that needed improvement. First
of all it was immediately noticed that due to the troubleshooting and rework needed it was almost impossible
to stick to the test procedures. Since these procedures were written before the tests, board rework, redesign
and retesting was done the written plans were not flexible enough and needed to be rewritten after each
test. This makes them rather cumbersome and useless. In practice the testplans were used as guidelines for
the tests and the logbooks were used to write down what was done and found.

Furthermore the testplans stated an order in which the tests were to be performed. In practice however the
order of testing was more determined by board availability and maturity. In practice for instance the mass
determination was done as last step since often rework still needed to be done and the coax lines were
sometimes added after electrical verification. Also the RF tests were dependant on facility and staff
availability.

During testing it was found that the first versions of the boards were non flight due to design errors and large
amounts of rework. In hindsight it would have been better to use the first boards as prototypes to define the
testplans and procedures for the flight boards.

©2006. All rights reserved. Disclosure to third parties of this document or any part thereof, or the use of DC3-TR-706-020
any information contained therein for purposes other than provided for by this document, is not permitted,
except prior and express written permission of Delft University of Technology, Aerospace Engineering.
 Document DC3-TR-706-020
Date 20-06-2007
Test Results Report Issue 2
Page 7

2.3 Maturity Overviews

During the verification a need for better version control was identified. A number of things were noticed that
could be a threat to the verification process:
• Unclarity about test status
• Unclarity about troubleshooting status
• Unclarity about rework status

During verification it was difficult to keep track of which test was performed on which board. A method of
logging that gave more overview was needed. Also often a certain PCB was waiting on rework or
troubleshooting or a certain test to be passed before it could move on to the next test. These dependencies
were hard to keep track of since they were present for six boards and each ICB had different problems.
Furthermore each board had been reworked and a log of the rework was initially only kept by DF. Later these
changes were also logged in logbooks. These changes were hard to keep track of.

As a result of this a first attempt was made to make a single overview document that contains all this data.
This maturity chart contains was made in Excel and contains a tab for each PCB. In this tab there are three
tables. The first table shows a status overview in which the MAIV engineer can write down what is currently
done on the board and what the board is waiting for. The second shows which tests have been passed/failed
or still have to be performed and comments on these tests. The third table shows a log of all the rework that
is performed on the board and whether these have been logged in an official NC report.

This Excel documeny has been used with great success and has improved the clarity during the verification
process. However several recommendations can be made:

A more database like structure in which also the status history is tracked is desirable to get a more complete
overview. A more flexible and accessible version should be made to also allow others to work in the
document. This would allow the person who does the rework to log the rework online and would allow other
team members to fill in test results of tests they performed on the board. The structure that is thought of is a
for instance a wiki or database in which there is one administrator (MAIV end responsible for that subsystem)
per subsystem. Others can send in status changes that have to be confirmed by the subsystem administrator.
In this way everyone can influence and update the system and the AIV engineer keeps the overview of the
process. Things that could also be incorporated are locations of the boards and test procedures coupled to
the tests. This online database will exist next to the paper logbooks and only the test outcomes and critical
information needs to be logged. The maturity charts are used to give an overview of the test results in the
next section.

©2006. All rights reserved. Disclosure to third parties of this document or any part thereof, or the use of DC3-TR-706-020
any information contained therein for purposes other than provided for by this document, is not permitted,
except prior and express written permission of Delft University of Technology, Aerospace Engineering.
 Document DC3-TR-706-020
Date 20-06-2007
Test Results Report Issue 2
Page 8

3. Test Results Summary

This chapter contains and overview of the verification status of the ICBs on 20-06-2007. The maturity charts
discussed above are used for this.

©2006. All rights reserved. Disclosure to third parties of this document or any part thereof, or the use of DC3-TR-706-020
any information contained therein for purposes other than provided for by this document, is not permitted,
except prior and express written permission of Delft University of Technology, Aerospace Engineering.
 Document DC3-TR-706-020
Date 20-06-2007
Test Results Report Issue 2
Page 9

ICBZ-001

ICB_Z-#001
Current Status
08-06-2007: <nothing to report>

Verification Status
/
Item Remarks

Mass

CoM

Envelope

Test Fit

OBM Functionality

OBC functionality

RF

Thermal

Combined OBM
Delta_T 70 DEG

Non-Conformances
Item / Remarks
Pins connector SP power switched; Logged in a NC file for
J15/J16 all Z- and Z+ boards, SP connector will be adapted
Power pins z- z+ reversed on data bus:Logged in a NC file
J14 for all Z- and Z+ boards, no measures taken

Resistors changed Logged in NC: R1,2,3,4,6,7,8,9 changed from 18K to 39K

Resistor rework Logged in NC: R78, R84, R90 resoldered

©2006. All rights reserved. Disclosure to third parties of this document or any part thereof, or the use of DC3-TR-706-020
any information contained therein for purposes other than provided for by this document, is not permitted,
except prior and express written permission of Delft University of Technology, Aerospace Engineering.
 Document DC3-TR-706-020
Date 20-06-2007
Test Results Report Issue 2
Page 10

Zener replaced Logged in NC: Zener D5 replaced

Logged in NC: R17,24,31,38,42,46 changed from 4K99 to
Resistors changed 3K3
Q13/Q14 and Q15/16 replaced & 5 wires soldered on for
Component replaced troubleshooting (no NC log yet)

IC's Ics removed (4x)

resistor rework remove R78 and 72, replace R12346789 with 6.8K

©2006. All rights reserved. Disclosure to third parties of this document or any part thereof, or the use of DC3-TR-706-020
any information contained therein for purposes other than provided for by this document, is not permitted,
except prior and express written permission of Delft University of Technology, Aerospace Engineering.
 Document DC3-TR-706-020
Date 20-06-2007
Test Results Report Issue 2
Page 11

ICBZ-002

ICB_Z-#002
Current Status
07-06-2007: <nothing to report>

Verification Status
/
Item Remarks

Mass
46,5

CoM

Envelope
similar board to #001

Test Fit

OBM Functionality

OBC functionality

RF

Thermal

Combined OBM
ICB Z-001 and Z+001 have been combined tested

Non-Conformances
Item / Remarks
Pins connector SP power switched; Logged in a NC file for all
J15/J16 Z- and Z+ boards, SP connector will be adapted
Power pins z- z+ reversed on data bus:Logged in a NC file for
J14 all Z- and Z+ boards, no measures taken

Resoldering on R68/57
resistor rework

IC's Ics removed (4x)

resistor rework remove R78 and 72, replace R12346789 with 6.8K

©2006. All rights reserved. Disclosure to third parties of this document or any part thereof, or the use of DC3-TR-706-020
any information contained therein for purposes other than provided for by this document, is not permitted,
except prior and express written permission of Delft University of Technology, Aerospace Engineering.
 Document DC3-TR-706-020
Date 20-06-2007
Test Results Report Issue 2
Page 12

©2006. All rights reserved. Disclosure to third parties of this document or any part thereof, or the use of DC3-TR-706-020
any information contained therein for purposes other than provided for by this document, is not permitted,
except prior and express written permission of Delft University of Technology, Aerospace Engineering.
 Document DC3-TR-706-020
Date 20-06-2007
Test Results Report Issue 2
Page 13

ICBZ-003

ICB_Z-#003
Current Status
07-06-2007: <nothing to report>

Verification Status
/
Item Remarks

Mass
46.9 grams

CoM

Envelope
similar board to #001

Test Fit

OBM Functionality

OBC functionality
To be tested with (RK)

RF

Thermal

Combined OBM
ICB Z-001 and Z+001 have been combined tested

Non-Conformances
Item / Remarks
Pins connector SP power switched; Logged in a NC file for all
J15/J16 Z- and Z+ boards, SP connector will be adapted
Power pins z- z+ reversed on data bus:Logged in a NC file for
J14 all Z- and Z+ boards, no measures taken

TP6 During thermal test TP6 and TP4 touched, TP6 is now 5.5 V

IC's Ics removed (4x)

resistor rework remove R78 and 72, replace R12346789 with 6.8K

©2006. All rights reserved. Disclosure to third parties of this document or any part thereof, or the use of DC3-TR-706-020
any information contained therein for purposes other than provided for by this document, is not permitted,
except prior and express written permission of Delft University of Technology, Aerospace Engineering.
 Document DC3-TR-706-020
Date 20-06-2007
Test Results Report Issue 2
Page 14

©2006. All rights reserved. Disclosure to third parties of this document or any part thereof, or the use of DC3-TR-706-020
any information contained therein for purposes other than provided for by this document, is not permitted,
except prior and express written permission of Delft University of Technology, Aerospace Engineering.
 Document DC3-TR-706-020
Date 20-06-2007
Test Results Report Issue 2
Page 15

ICBZ+001

ICB_Z+#001

Current Status
07-06-2007: - NONflight

Verification Status
Item / Remarks

Mass
not relevant (other coax patern)

CoM

Envelope

Test Fit

OBM Functionality

OBC functionality

RF

Thermal

Combined OBM
ICB Z-001 and Z+001 have been combined tested

Non-Conformances
Item / Remarks
Pins connector SP power switched; Logged in a NC file
J15/16 for all Z- and Z+ boards, SP connector will be adapted
Power pins z- z+ reversed on data bus:Logged in a NC
J14 file for all Z- and Z+ boards, no measures taken

Zener replaced Logged in NC: Zener D6 replaced

IC U3 replacement IC U3 replaced

resistors added resistors PIC circuitry added (8x13K)

©2006. All rights reserved. Disclosure to third parties of this document or any part thereof, or the use of DC3-TR-706-020
any information contained therein for purposes other than provided for by this document, is not permitted,
except prior and express written permission of Delft University of Technology, Aerospace Engineering.
 Document DC3-TR-706-020
Date 20-06-2007
Test Results Report Issue 2
Page 16

IC's Ics removed (4x)

remove R78 and 72, replace R12346789 with 6.8K: No
Resistor Rework NC yet

U4 rework Rework done on U4, resistors couples through wrongly

©2006. All rights reserved. Disclosure to third parties of this document or any part thereof, or the use of DC3-TR-706-020
any information contained therein for purposes other than provided for by this document, is not permitted,
except prior and express written permission of Delft University of Technology, Aerospace Engineering.
 Document DC3-TR-706-020
Date 20-06-2007
Test Results Report Issue 2
Page 17

ICBZ+002

ICB_Z+#002

Current Status
19-06-2007: - Awaiting cold testing

Verification Status
Item / Remarks

Mass
48.1 grams

CoM

Envelope
Similar board to Z+001

Test Fit

OBM Functionality
Awaiting troubleshooting R 29

OBC functionality

RF

Thermal

Combined OBM
ICB Z-001 and Z+001 have been combined tested

Non-Conformances
Item / Remarks
Pins connector SP power switched; Logged in a NC file
J15/16 for all Z- and Z+ boards, SP connector will be adapted
Power pins z- z+ reversed on data bus:Logged in a NC
J14 file for all Z- and Z+ boards, no measures taken

IC's Ics removed (4x)

©2006. All rights reserved. Disclosure to third parties of this document or any part thereof, or the use of DC3-TR-706-020
any information contained therein for purposes other than provided for by this document, is not permitted,
except prior and express written permission of Delft University of Technology, Aerospace Engineering.
 Document DC3-TR-706-020
Date 20-06-2007
Test Results Report Issue 2
Page 18

Resistor rework R28/R30 rework: wrong resistor values

resistor rework Removed R29 and replaced a few days later

Pic rework U2 pin 24 lifted… and U2 eventually replaced

©2006. All rights reserved. Disclosure to third parties of this document or any part thereof, or the use of DC3-TR-706-020
any information contained therein for purposes other than provided for by this document, is not permitted,
except prior and express written permission of Delft University of Technology, Aerospace Engineering.
 Document DC3-TR-706-020
Date 20-06-2007
Test Results Report Issue 2
Page 19

ICBZ+003

ICB_Z+#003
Current Status
19-06-2007: <nothing to report>

Verification Status
Item / Remarks

Mass
48.2 grams

CoM

Envelope
Similar board to Z+001

Test Fit

OBM Functionality

OBC functionality

RF

Thermal

Combined OBM
ICB Z-001 and Z+001 have been combined tested

Non-Conformances
Item / Remarks
Pins connector SP power switched; Logged in a NC file
J15/16 for all Z- and Z+ boards, SP connector will be adapted
Power pins z- z+ reversed on data bus:Logged in a NC
J14 file for all Z- and Z+ boards, no measures taken

Zeners no zeners on the board since they are not used

©2006. All rights reserved. Disclosure to third parties of this document or any part thereof, or the use of DC3-TR-706-020
any information contained therein for purposes other than provided for by this document, is not permitted,
except prior and express written permission of Delft University of Technology, Aerospace Engineering.
 Document DC3-TR-706-020
Date 20-06-2007
Test Results Report Issue 2
Page 20

©2006. All rights reserved. Disclosure to third parties of this document or any part thereof, or the use of DC3-TR-706-020
any information contained therein for purposes other than provided for by this document, is not permitted,
except prior and express written permission of Delft University of Technology, Aerospace Engineering.
 Document DC3-TR-706-020
Date 20-06-2007
Test Results Report Issue 2
Page 21

4. Flight Status

This section indicates the flight status of the boards and comments on it.

Board ID Status Comment

ICBZ-001 NON-FLIGHT - Testboard with large amount of
rework
- Board has been adapted for
troubleshooting
- Electronically representative test
model
ICBZ-002 FLIGHT - Completely tested
- Some rework
ICBZ-003 FLIGHT-SPARE - Not completely tested yet
- Some rework
ICBZ+001 NON-FLIGHT - RF circuitry wrong
- Electronically representative test
model
ICBZ+002 FLIGHT-SPARE - Not completely tested yet
- Some rework (eg: PIC replaced)
ICBZ+003 FLIGHT - Completely tested
- Very little rework done

©2006. All rights reserved. Disclosure to third parties of this document or any part thereof, or the use of DC3-TR-706-020
any information contained therein for purposes other than provided for by this document, is not permitted,
except prior and express written permission of Delft University of Technology, Aerospace Engineering.
E.3 Deployment system verification
Next to the activities mentioned in the previous section the author also did testing on the ICB interfaces. During
these tests the ICB was tested with the solar panels and MABs attached to it. These tests both proved the func-
tionality of the interface and proved that the deployable itself functioned.

Since during these tests the ICB was operated in its standard, already verified, mode the test results were put
into the report of the students responsible for the MAB and solar panel test. The results of the solar panel test can
be found in [24], while the results of the MAB test can be found in [19]. Furthermore the author has together with
Bram Vaartjes defined the exact deploy sequence for the satellite that is currently undergoing final testing.
Note deploy tests with MABs and SPs

E.4 Overview of Activities

This section contains an overview of the different activities that were performed during the MAIV of the Delfi-C3
satellite. The author has been responsible for the deployment elements in the Delfi-C3 verification. During the
SPFC2006 the MABs were tested as one of the first Delfi-C3 subsystems. Furthermore the InterConnect Boards
were tested and was the first subsystems with a complete testplan that formed the basis for the other subsystems.

E.4.1 Verification Activities

Table E.1 lists the author’s tasks in the verification process of the Delfi-C3 satellite.

E.4.2 ICB Troubleshooting Activities

This section lists the problemsolving activities that were performed on the ICBs in the first semester of 2007 in
order to get them qualified and accepted for launch. The author has been responsible for the coordination and
execution of these activities. This list excludes the issues concerning software maturity since these were rather
exhaustive and should be accounted for in the software reports. This list purely deals with the hardware and design
changes made to the PCBs.

ICBZ-001 Troubleshooting

ICBZ-001 was the first ICB to be delivered for verification. Initially the board was supposed to be a flight board,
but due to the exhaustive rework and testing that was done on the board it was considered to be non-flight and a
third board (ICBZ-003 was produced).

ICBZ-002 Troubleshooting

The second board ICBZ- board that was produced had already incorporated several design changes from ICBZ-
001. However still some rework needed to be done in order to get it verified. Especially the problems that arose
during thermal testing influenced the verification process of the ICBs. Due to the difficulty in measuring PCB
parameters during thermal testing and the long time needed for preparation of the tests it caused large delays in
the verification process. Table E.3 shows an overview of the troubleshooting activities performed on the PCB.

ICBZ-003 Troubleshooting

The last ICBZ- board also had to have some rework due to the problems in thermal testing. Table E.4 shows an
overview of the troubleshooting activities performed on the PCB.

139
 Verification Activities on Delfi-C3
Activity Period Description
MAB MAIV 04/2006 - 07/2006 - MAIV of the MABs in parabolic flight
- First with functional hardware, software and electronics
(months before the rest) [8]
ICB MAIV 02/2007 - 07/2007 - Definition of the verification process for the ICBs
supervision and definition - Verification process used as standard for other PCB ver-
ification
- Coordinating the technical players involved in the ICB
verification process
ICB AIV 02/2007 - 07/2007 - Mass, CoM and geometric verification
- OBM mode verification
- OBC mode verification
- Thermal verification
- RF testing
- Integrated OBM testing
Solar Panel Integrated Deploy 05/2007 Integrated deployment test in which the structural model
Test of the solar panel was connected to the ICB and an actual
deployment was performed. Results of this test can be
found in the solar panel test report [24]
MAB Integrated Deploy Test 05/2007 Integrated deployment test in which the MAB prototype
was connected to the ICB and an actual deployment was
performed. Results of this test can be found in the MAB
test report [19]
Stack Integrated Communication 06/2007 Test in which the OBC internal communication was
Test checked with a partly complete stack consisting of the
OBC, COMBO, MeBoZ+ and ICBZ+. The communica-
tion was successfully

Table E.1: Verification Activities Performed on Delfi-C3

ICBZ+001 Troubleshooting

As with the firs ICBZ-001 board, also the ICBZ+001 board needed rework. Moreover there was a serious design
error on the board in which the coax used to connect the antennas to the RF connectors on the board interfered
with the MAB mounting spots. This resulted in a redesign. ICBZ+001 was however kept for electrical testing
since the electronics were identical to that of the redesign. Table E.5 shows an overview of the troubleshooting
activities performed on the PCB.

ICBZ+002 Troubleshooting

ICBZ+002 is the first ICBZ+ flight board. It has had rework done on it and moreover has had one of the PICs
replaced because it was malfunctioning. Table E.6 shows an overview of the troubleshooting activities performed
on the PCB.

ICBZ+003 Troubleshooting

No rework was done on the ICBZ+003 board on the time of writing. It was the last board to come in and the only
notable characteristic of it is that it does not contain the zeners and resistors that are present in 5V circuitry since
this circuitry was removed. On the other boards the zeners were isolated by removing R78 and R72, but here the
entire circuitry was omitted.

140
 Verification Activities on ICBZ-001
Item Period Description
J15 & J16 Connector 02/2007 The Solar Panel Connector pins are mirrored on the two
connectors (J15 & J16). The problem has been logged for
all ICBs and will be taken into account during MAIV of
the solar panels
J14 Connector 02/2007 The databus (J14) connector pins for Z+ and Z- power are
switched. The problem has been logged for all ICBs and
investigation showed that this does not effect the satellite
Resistor Replacement 02/2007 R1-4 and R6-9 were replaced by 18K resistors. This has
been logged and subsequent boards will have the 18K re-
sistors
Resistor Rework 02/2007 Problems with the deployment are caused by bad solder-
ings on R78, R84 and R90. Rework is done on these
resistors
Zener Replacement 03/2007 The cause of a malfunctioning PIC U2 is found to be a
broken Zener (D5). After replacement the board func-
tions again
TACT Switch Resistor 04/2007 A design error on the board causes the TACT switched to
Change malfunction. R17, R24, R31, R38, R42 and R46 values
are changed from 4K99 to 3K3.
Thermal Testing Deploy- 04/2007 During thermal tests the deployments are not all success-
ment Failure I ful. Q13, Q14, Q15 and Q16 are replaced and wires
are soldered on the circuitry to check performance dur-
ing testing . No problem resolvement
Thermal Testing Deploy- 05/2007 U3, U4. U5 and U6 are removed from the board and the
ment Failure II pads are connected through. The software is altered and
tests show that the deployments work better now. The
problem was in a low PIC and 5V driver voltage. Still the
PIC voltage is a problem
Thermal Testing Deploy- 05/2007 After extensive testing the resistors in the PIC supply cir-
ment Failure III cuitry are double and are now approximately 6.5 KΩ .
Testing now shows that the boards do work in thermal
conditions from -40 to 60 degrees Celsius
Thermal Testing Deploy- 06/2007 To ensure functionality R78 and R72 are removed to cut
ment Board Revision of the 5V circuitry

Table E.2: Verification Activities on ICBZ-001

Verification Activities on ICBZ-002

Item Period Description
Rework on Resistors 04/2007 After U2 functional problems it was discovered that R57
and R57 needed rework. After the rework the board func-
tioned again
Thermal Testing Deploy- 05/2007 As with Z-001 this board failed Thermal testing. U3,
ment Failure U4, U5, U6 were removed and connected through, R72,
R78 were removed and the values of R1-4 and R6-9 were
changed to 6.8 KΩ

Table E.3: Verification Activities on ICBZ-002

141
 Verification Activities on ICBZ-003
Item Period Description
Thermal Testing Deploy- 06/2007 As with Z-001 this board failed Thermal testing. U3,
ment Failure U4, U5, U6 were removed and connected through, R72,
R78 were removed and the values of R1-4 and R6-9 were
changed to 6.8 KΩ

Table E.4: Verification Activities on ICBZ-003

Verification Activities on ICBZ+001

Item
Replacement Zener D6
Replacement IC U3
Resistor Rework
Removed ICs
Resistor Rework
Rework Pads U4
Period Description
/2007
/2007
/2007 8 time 13K on top of R1-4 and R6-9 to check thermal
functionality
/2007 IC U3, U4, U5, U6 removed and connected through
/2007 R78 R72
/2007 Pads coupled through wrongly

Table E.5: Verification Activities on ICBZ+001

Verification Activities on ICBZ+002

Item
Thermal Testing Deploy-
ment Failure
Resistor Replacement
Resistor Replacement
U2 Pin Isolation
U2 Replacement
Period Description
05/2007 As with Z-001 this board failed Thermal testing. U3,
U4, U5, U6 were removed and connected through, R72,
R78 were removed and the values of R1-4 and R6-9 were
changed to 6.8 KΩ
06/2007 Wrong Resistor values caused TACT switch failures on
the board. R28 and R30 had to be replaced to overcome
this problem. Further troubleshooting had to be done to
isolate the problem
06/2007 Resistor R29 had to be removed in order to further locate
the error in the TACT switch circuitry. After the resistor
was removed the PIC interfered with the measurements
and the resistor was replaced.
06/2007 Pin 24 was isolated on the PIC to isolate the TACT switch
circuitry. The PIC was found to be defect after this.
06/2007 The defect PIC was replaced and tested. The board was
again functional after this

Table E.6: Verification Activities on ICBZ+002

E.5 Deploy Sequence

This section contains an overview of the deploy sequence the is performed in OnBoard Moron (OBM) Mode in
case of an OBC failure. Because of the different controllers that control the deployments and the fact that no
more than one deployment can be performed at a time due to power restrictions the sequence has incorporated the
standard and temperature dependant deviation between different controllers.

142
 ADP Time t_min t_max Comment
Event 1 2 3 4
1 SPZ-Y-A x 10
2 Stop Burn x 25 23,5 26,5
PIC Switch
3 SPZ+X-A x 29 27,26 30,74
4 Stop Burn x 44
5 SPZ+X+A x 44
6 Stop Burn x 59 55,46 62,54
PIC Switch
7 SPZ-Y+A x 67 62,98 71,02
8 Stop Burn x 82
9 MZ-X-A x 82
Primary resistors

10 Stop Burn x 89
11 MZ-X+A x 89
12 Stop Burn x 96
13 MZ-Y-A x 96
14 Stop Burn x 103
15 MZ-Y+A x 103
16 Stop Burn x 110 103,4 116,6
PIC Switch
17 MZ+X-A x 125 117,5 132,5
18 Stop Burn x 132
19 MZ+X+A x 132
20 Stop Burn x 139
21 MZ+Y-A x 139
22 Stop Burn x 146
23 MZ+Y+A x 146
24 Stop Burn x 153 143,82 162,18
PIC Switch
25 SPZ-Y-B x 173 162,62 183,38
26 Stop Burn x 188 176,72 199,28
PIC Switch
27 SPZ+X-B x 212 199,28 224,72
28 Stop Burn x 227
29 SPZ+X+B x 227
30 Stop Burn x 242 227,48 256,52
PIC Switch
31 SPZ-Y+B x 273 256,62 289,38
32 Stop Burn x 288
33 MZ-X-B x 288
Secondary Resistors

34 Stop Burn x 295

35 MZ-X+B x 295
36 Stop Burn x 302
37 MZ-Y-B x 302
38 Stop Burn x 309
39 MZ-Y+B x 309
40 Stop Burn x 316 297,04 334,96
PIC Switch
41 MZ+X-B x 357 335,58 378,42
42 Stop Burn x 364
43 MZ+X+B x 364
44 Stop Burn x 371
45 MZ+Y-B x 371
46 Stop Burn x 378
47 MZ+Y+B x 378
48 Stop Burn x 385

Min time 361,9 -6% deviation

Max time 408,1 +6% deviation
144
Bibliography

[1] L. Alminde, M. Bisgaard, N. Melville, , and J. Schaefer. The SSETI-express Mission: From Idea to Launch
in one and a Half Year. 2005.
[2] Lars Alminde, Morten Bisgaard, Dennis Vinther, Tor Viscor, and Kasper Østergard. Educational Value and
Lessons Learned from the AAU-CubeSat Project. 2004.
[3] I. Pineda Amo. CubeSat Concept Benefits. (IAC-04-P.5.B.06), 2004.
[4] Remon Annes, Jasper van der Graaff, Michael Meijers, and Barry Zandbergen. Operation Delfi - A Space
Mission Development Project. 2002.
[5] A.R. Bonnema. Securing controllability, continuity and consistency of the Delfi-C3 university nanosatellite
project by applying flexible Systems Engineering and Project Management. Master’s thesis, Delft University
of Technology, Faculty of Aerospace Engineering, 2005.
[6] J. Bouwmeester. OBC Systems Engineering and Design. Technical report, Delft University of Technology,
Faculty of Aerospace Engineering, 2007.
[7] J. Elstak. AAUSAT-II Assembly, Integration and Verification Definition and Supervision. 2007.
[8] Joost Elstak, Ruud Caljouw, Dick Allewelt, and Ana Frutos Pastor. Student Parabolic Flight Campaign
2006: Modular Antenna Box deployment testing in zero-g. Technical report, Delft University of Technology,
Faculty of Aerospace Engineering, 2006.
[9] Joost Elstak and Jeroen Rotteveel. DCS-STA-FM-100; InterConnect Board Z+ Verification Folder. Technical
report, Delft University of Technology, Faculty of Aerospace Engineering, 2007.
[10] Joost Elstak and Jeroen Rotteveel. DCS-STA-FM-900; InterConnect Board Z- Verification Folder. Technical
report, Delft University of Technology, Faculty of Aerospace Engineering, 2007.
[11] Peter Fortescue and John Stark. Spacecraft Systems Engineering. Wiley, 1999.
[12] R.J. Hamann. Space Systems Engineering. TU Delft, 2001.
[13] R.J. Hamann and M.J.L. van Tooren. Systems Engineering & Technical Management Techniques. TU Delft,
2004.
[14] Project Management Institute Inc. A Guide to the Project Management Body Of Knowledge. Newton Square,
Pennsylvania, Project Management Institute Inc., 2000 edition.
[15] INCOSE. http://www.incose.org/practice/fellowsconsensus.aspx. 2000.
[16] INCOSE. Systems Engineering Handbook. 2000.
[17] Members of ECSS. Space Engineering: Systems Engineering. Technical report, European Cooperation for
Space Standardization, 1996.
[18] N Narayana Moorthy. Polar Satellite Launch Verhicle Users’s Manual, 1999.
[19] T. Moret. Vibration Test Engineer. 2007.
[20] J. Dalsgaard Nielsen. Space Related Education at the University of Aalborg, Denmark. (Nordicspace Journal
2005), 2005.
[21] J. Rotteveel. Providing a customized control framework for the Delfi-C3 mission by means of flexible
Systems Engineering and Thermal Conrol Tools . Master’s thesis, Delft University of Technology, Faculty
of Aerospace Engineering, 2006.
[22] SSETI Express Team. SSETI Express Lessons Learned Submission Form. Technical report, European Space
Agency, 2005.
[23] W.J. Ubbels, A.R. Bonnema, E.D. van Breukelen, J.H. Doorn, R. van den Eikhoff, E van der Linden, G.T.
Aalbers, J. Rotteveel, R.J. Hamann, and C.J.M. Verhoeven. Delfi-C3: a Student Nanosatellite as a Test-bed
for Thin Film Solar Cells and Wirelees OnBoard Communication. IAC-05-B5.6.A.02, 2005.
[24] Danielle van Gent. Thermal Testing of Delfi-C3. 2007.

[25] Various. CubeSat Requirements Document. 2005.

[26] James R. Wertz and Wiley J. Larson. Space Mission Analysis and Design. Microcosm Press, 1999.

146