S PACE M ISSION A NALYSIS AND D ESIGN

AY 2017/2018

CHAPTER: MISSION ANALYSIS

Authors:
Sebastiano A LBERTI
Ariane C OURTOT
Mauro D E F RANCESCO
Marco Felice M ONTARULI
Professor:
Marco O RFANO
Michèle L AVAGNA
Marco P EZZIN
Margherita P ICCININ
Matteo QUIRINO
Anna S CHIAVO
Luca S COPEL

July 16, 2018

Team members and roles

Team member Team role

Alberti Sebastiano Electric Power Subsystem
Courtot Ariane Configuration
De Francesco Mauro Cost and risks, Programmatics, AIV
Montaruli Marco Felice Attitude Determination and Control
Orfano Marco Mission Analysis
Pezzin Marco On Board Data Handling
Piccinin Margherita Structural Subsystem
Quirino Matteo Thermal Control Subsystem
Schiavo Anna TT&C
Scopel Luca Propulsion Subsystem

GENOS i
Contents

Team members and roles i

1 Introduction 1
1.1 Gamma Ray Bursts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 State of the art . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3 Why GENOS? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4 Mission objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.5 Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.6 Payload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.6.1 Criticalities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.6.2 Rough estimate on lifetime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.6.3 Annealing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 Mission overview 7
2.1 LEO constellation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.1 Localization of the GRB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.2 GRB alert to ground . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2 Localization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.1 The annuli thickness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.2 The error box shape . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3 Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.1 Number of detectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.2 Coverage losses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3 GENOS constellation and satellite 13

3.1 GENOS constellation and lifetime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2 Reference frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3 GENOS satellite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.4 GRB simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.5 Sunpointing analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.6 The microsatellite class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4 Mission Analysis 19
4.1 Walker Constellation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.2 Localization performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.3 Mission phases and ∆V . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.3.1 Phasing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.3.2 Orbit trim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.3.3 Station keeping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

GENOS ii
CONTENTS CONTENTS

4.3.3.1 Perturbation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.3.3.2 Station Keeping Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.3.4 Disposal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.4 Eclipse duration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.5 South Atlantic Anomaly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.6 Backup Orbits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

5 Propulsion susbsytem 31
5.1 ∆v budget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.2 Technology selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.3 Thruster selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.4 Propellant mass budget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.5 Propulsion subsystem architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.6 Future developments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

6 Telemetry-Tracking & Commands 35

6.1 Objectives and drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
6.2 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
6.2.1 Globalstar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
6.2.2 LeafSpace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
6.2.2.1 Patch antenna ad transceiver . . . . . . . . . . . . . . . . . . . . . . . . . . 38
6.2.2.2 Contact analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
6.2.2.3 Link budget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
6.3 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
6.3.1 Mass and power budget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

7 On Board Data Handling 45

7.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
7.2 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
7.3 Functionalities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
7.4 Operations breakdown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
7.5 Sizing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
7.6 Architecture selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
7.6.1 Proposed architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
7.7 Redundancy and robustness strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
7.8 Components specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
7.9 Mass and power budget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

8 Attitude Determination and Control Subsystem 54

8.1 Design path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
8.1.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
8.1.2 Actuators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
8.1.3 Sensors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
8.2 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
8.3 Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
8.3.1 Detumbling mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
8.3.2 Maneuvering mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
8.3.2.1 Sunpointing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
8.3.2.2 Thrustpointing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
8.3.3 Science mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

GENOS iii
CONTENTS CONTENTS

8.3.4 Safe mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

9 Electrical power subsystem 64

9.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
9.1.1 Installed power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
9.2 Modes and sub-modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
9.2.1 Starting mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
9.2.2 Science mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
9.2.3 Maneuvering mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
9.2.4 Safe mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
9.3 Solar panels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
9.3.1 Solar cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
9.3.2 Solar panels configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
9.3.3 Sizing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
9.4 Batteries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
9.4.1 Li-ion cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
9.4.2 Sizing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
9.5 Bus architecture and PMDU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
9.5.1 DC/DC converters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
9.6 Off-design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
9.6.1 Numerical model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
9.6.2 Orbit injection phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
9.6.3 Safe mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

10 Thermal control subsystem 73

10.1 Requirements and Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
10.1.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
10.1.2 Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
10.2 Model, assumptions and preliminary design . . . . . . . . . . . . . . . . . . . . . . . . . . 73
10.2.1 Model and assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
10.3 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
10.4 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
10.5 Future developments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

11 Configuration 80
11.1 Drivers and most important requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
11.2 Design process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
11.2.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
11.2.2 General design flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
11.2.3 Criticalities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
11.3 Presentation of the design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

12 Structural subsystem 85
12.1 Requirements and design drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
12.2 List of structural components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
12.3 Baseline design and mass budget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
12.4 Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
12.5 FEM model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
12.6 Modal analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
12.7 Static and buckling analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

GENOS iv
CONTENTS CONTENTS

12.7.1 Loads definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

12.7.2 Static analysis results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
12.7.3 Buckling analysis results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

13 Modes 92
13.1 Phases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

14 Mass Budget 98

15 Programmatics / AIV 101

15.1 Model Philosophy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
15.2 AIV Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
15.3 Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

16 Risk Assessment 105

16.1 GENOS risk management policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
16.1.1 Success Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
16.1.2 Severity and Likelihood Categorizations . . . . . . . . . . . . . . . . . . . . . . . . 105
16.1.3 Risk index and acceptance policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
16.2 Risk Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
16.3 Top Risk Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

17 Costs 109
17.1 Cost Estimate Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
17.2 Cost Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
17.2.1 Space Segment Costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
17.2.2 Launch Segment Costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
17.2.3 Operations Costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
17.2.4 Results and Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

GENOS v
List of Figures

1.1 IPN triangulation method, from [?] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 Detector [?] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Detector’s lifetime estimation [?] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4 Annealing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.1 Annulus width d θ dependence on distance D and half-angle θ, with σ(T ) = 10µs . . . . 8
2.2 Annulus width d θ dependence on distance D and time uncertainty σ(T ), with θ = π/2 . 10
2.3 Degenerate case: tangent annuli . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4 Celestial sphere covered by 5 P/L of 160° FOV. Each color is a detector, the yellow vector
points the Sun . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.1 Satellite body reference frame and desired attitude frame. The number specify the face. 14
3.2 GENOS satellite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3 Error box example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.4 GRB simulation with random attitude . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.5 Result of the nanosatellites analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.6 Satellite body reference frame and desired attitude frame. The number specify the face. 18

4.1 2 planes accuracy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.2 3 planes accuracy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.3 Localization performance [arcmin], with full constellation . . . . . . . . . . . . . . . . . 22
4.4 Localization performance [arcmin], with satellite in SAA . . . . . . . . . . . . . . . . . . . 22
4.5 Mision phases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.6 Phasing maneuver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.7 ∆V for altitude correction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.8 ∆V for plane correction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.9 Annual RAAN variation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.10 Orbit lifetime estimation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.11 Relative semi-major axis differences among coplanar satellites . . . . . . . . . . . . . . . 26
4.12 Drag compensation strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.13 Natural decay time in LEO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.14 Shadow of the Earth model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.15 Plots of the eclipses duration for the year 2020 . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.16 South Atlantic Anomaly region . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5.1 Propulsion subsystem architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

6.1 Eyestar-D2 device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

6.2 LeafSpace network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
6.3 RBC signals network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

GENOS vi
LIST OF FIGURES LIST OF FIGURES

6.4 Antenna and transceiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

6.5 Transceiver architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.6 Ground track for LeafSpace network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
6.7 EbN0 [dB] for science data download . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

7.1 ESA SAVOIR functional architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

7.2 Sensors data rates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
7.3 Architecture scheme for the OBDH subsystem . . . . . . . . . . . . . . . . . . . . . . . . . 52

8.1 ADCS architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

8.2 Angular velocity trend during the detumbling . . . . . . . . . . . . . . . . . . . . . . . . . 58
8.3 Magnetic dipole during the detumbling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
8.4 Sunpointing precision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
8.5 Thrustpointing precision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
8.6 Reaction wheels momentum during the thrustpointing . . . . . . . . . . . . . . . . . . . 61
8.7 Angular velocity trend during the thrustpointing . . . . . . . . . . . . . . . . . . . . . . . 62
8.8 Detumbling during safe mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
8.9 Safe mode precision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

9.1 Power breakdown (25% margin) per subsystem for each mode. . . . . . . . . . . . . . . . 66
9.2 Solar panels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
9.3 Example of battery charging from 250 Wh of capacity. The power demand of the loads
are that of the science mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
9.4 Expected lifetime of the satellite in safe mode until the battery death. . . . . . . . . . . . 72

10.1 9 nodes model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

10.2 Worst hot case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
10.3 Worst cold case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
10.4 Comparison between OpenFOAM and MatLab results . . . . . . . . . . . . . . . . . . . . 78
10.5 OpenFOAM results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

11.1 Definition of the different faces and reference system for the configuration subsystem . 81
11.2 View of the deployed satellite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
11.3 View of the different faces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
11.4 View of the satellite without faces 2, 3 , 4, 5 and without antennas and solar panels for
more visibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
11.5 Stowed configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
11.6 View of the spacecraft while being assembled and tested . . . . . . . . . . . . . . . . . . . 84

12.1 GENOS structural items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

12.2 Beams sections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
12.3 Ruag Space deployment mechanism and damper . . . . . . . . . . . . . . . . . . . . . . . 88
12.4 Solar arrays deployment profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
12.5 Modal analysis results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
12.6 Lower panel Von Mises stress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

14.1 Mass Budget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

15.1 GENOS Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

16.1 Likelihood Categorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

16.2 Severity Categorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

GENOS vii
LIST OF FIGURES LIST OF FIGURES

16.3 Risk Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

17.1 Division of Space Segment Costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

17.2 Division of Subsystem Costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
17.3 Communication Costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

GENOS viii
List of Tables

1.1 Detector specifications [?] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1 Occultation due to solar system main bodies . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.1 Localization performance with random attitude . . . . . . . . . . . . . . . . . . . . . . . . 16

4.1 Accuracy for different number of satellite per plane . . . . . . . . . . . . . . . . . . . . . . 20

4.2 Accuracy for different inclination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.3 Starting nominal Keplerian parameters of the constellation . . . . . . . . . . . . . . . . . 21
4.4 GENOS localization performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.5 VEGA uncertainties and required ∆V . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.6 Effect of differential decay rate on relative phasing . . . . . . . . . . . . . . . . . . . . . . 25
4.7 Achievable accuracy with phasing error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.8 Time spent in the SAA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.9 Accuracy performance for different constellation configuration . . . . . . . . . . . . . . 30

5.1 ∆V budget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.2 Thruster specifications [?] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.3 Propellant mass budget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

6.1 Globalstar parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

6.2 Iridium 9603 device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
6.3 Patch parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.4 Transceiver specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.5 Link budget for the operational phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
6.6 Link budget for starting phase and safe mode . . . . . . . . . . . . . . . . . . . . . . . . . 43
6.7 Mass budget with margin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
6.8 Power budget with margin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

7.1 Throughput and size budget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

7.2 Size & throughput requirements refinement . . . . . . . . . . . . . . . . . . . . . . . . . . 49
7.3 Components properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
7.4 Mass & power budget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

8.1 ADCS number and baseline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

8.2 ADCS modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

9.1 Installed power on GENOS satellite. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

9.2 Power breakdown for modes and sub-modes. . . . . . . . . . . . . . . . . . . . . . . . . . 67
9.3 Summary of the panel feature. Note, the mass value is not margined. . . . . . . . . . . . 68
9.4 Battery pack data. Note, the values in this table are not margined. . . . . . . . . . . . . . 69

GENOS ix
LIST OF TABLES LIST OF TABLES

9.5 Summary of PS-MS01 datasheet [?]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

10.1 Temperature limits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

10.2 Worst hot and cold case environmental values [?] . . . . . . . . . . . . . . . . . . . . . . . 74
10.3 Masses computed according to structure and configuration output . . . . . . . . . . . . 76
10.4 Optical properties computed using sensitivity analysis . . . . . . . . . . . . . . . . . . . . 76

12.1 Design requirements from the launcher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

12.2 Panels characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
12.3 Reinforcements and tank support characteristics . . . . . . . . . . . . . . . . . . . . . . . 87
12.4 Worst load case [g] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

14.1 Mass breakdown update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

14.2 List of equipment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

15.1 Test Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

16.1 GENOS mission success criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

16.2 Risk Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

17.1 Space Segment Costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

17.2 Launch Segment Cost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
17.3 Operations Segment Cost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
17.4 Cost Budget for Life Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
17.5 Available Costs for some Components of the Spacecraft Bus . . . . . . . . . . . . . . . . . 112

GENOS x
1 Introduction

1.1 G AMMA R AY B URSTS

Gamma ray bursts are one of the most energetic radiations in the cosmos and for quite some years
have been puzzling the scientists. This intense radiation is one of the brightest of the sky, and the
mechanisms leading to it are not fully understood. The amount of released energy is very high and
therefore the photons are probably emitted as jets and not in all directions, since an isotropic emission
would require an exceedingly high energy. The directionality of the GRB implies that only the ones
directed towards Earth can be detected.
GRBs distribution in the sky has been observed to be isotropic, and for this reason it is known
that they come from outside our galaxy. They are relatively common events, as about one per day is
detected. There are two types of GRB, originating from different mechanisms.
Long duration GRB emitted when a massive star collapses due to its gravitational attraction into a
black hole (“hypernova” explosion). This type of emission is characterized by a duration of the
order of tens of seconds.

Short duration GRB emitted by the merging of two neutron stars, which have been orbiting around
each other and losing energy (also through the emission of gravitational waves). In this case the
duration is below 2 seconds.
Prompt emission is the first phase and it is the actual GRB itself. The emission is in the γ-ray band
and it is the most energetic part, with energies in the order of few MeV.
The prompt emission is quickly followed by the so-called afterglow, which is characterized by
a longer duration (from few hours up to some months) and an energy decreasing with time. The
bandwidth in this case spaces from x-ray to radio waves.

GRBs are strictly correlated with gravitational waves (GW), as demonstrated in 2017. GRB170817A
has been observed by the Fermi telescope about 1.7s after the detection of GW170817 by Advanced
Ligo and Advanced Virgo interferometers, relative to the merging of two binary neutron stars. This
joint effort between gravitational and electromagnetic observations led to major breakthroughs in
physics.

The data acquired during the mission can be very useful to the scientific community. In particular
they are meaningful to researchers that are currently trying to correlate GRB events with GWs. As
a consequence, the final users of the GRBs localization data flow would most likely be all those
observatory facilities related to this field. For example, they may be the interferometers Ligo and Virgo
or other ground telescopes, but also space telescopes as ATHENA.

1.2 S TATE OF THE ART

The two common strategies to localize the GRB source are:

GENOS 1
1 - Introduction 1.2 - State of the art

Autonomous localization based on detectors possessing anisotropic angular sensitivity[?], that are:

• affected by Earth albedo;

• affected by absorption of s/c materials;

• affected by systematic errors of several degrees.

Examples of mission using this strategy are AGILE[?], Fermi[?]REFEXPIRED, SWIFT[?] and INTEGRAL[?].
The main disadvantage coming form such type of localization method is that it is possible to observe
just a portion of the sky at a time, missing out what it might happen outside such region. On the other
hand, the most recent mission of this type, thanks to expensive sophisticated detectors and 24/7 fast
satellite communications links, are able to communicate the location of the GRB within ∼ 10 s from
the trigger [?].
Currently, missions with omni-directional instruments on board can communicate the alert quickly,
but:

• They don’t provide a precise localization, like in the WIND case.

• They are Near-Earth missions that don’t have a complete coverage.

Triangulation The triangulation method is the solution adopted by the Interplanetary Network to
localize the GRBs sources: its working principle is here described.

The GRB is a planar wave that triggers the detectors of the satellites at different time instants. Given
two spacecrafts, it is possible to know their relative distance and the time delay at which they detect the
event. With such data an annulus is constructed, as shown in figure 1.1. The GRB celestial coordinates
could be any point inside the annulus width.
A third satellite is necessary to identify two independent annuli, that will have two intersections. In
order to eliminate this ambiguity, different strategies can be exploited:

• To add the contribution of a 4th s/c.

• To include the coarse information about the direction from the GRB detector.

• To exploit missed-detection informations.

Exploiting more satellites many annuli can be built up. The GRB so is localized inside the error box
defined by their intersections. The localization accuracy is affected both by the annuli thickness and
by the way in which the annuli intersect. In fact, error boxes that are good for localization purposes
shall not have an elongated shape. For this reason, the satellites should define more planes.

Triangulation has a high precision of localization, but a long time is required to collect all the data
of the network (IPN employs about 1.5 day) [?]. It has to be noticed that some missions involved in
IPN are not GRB-dedicated, but are planetary experiments which have also a GRB detection mode;
therefore they may have coarser resolution and less sensitivity [?], making correlation between all of
them a time consuming procedure.

GENOS 2
1 - Introduction 1.3 - Why GENOS?

Figure 1.1: IPN triangulation method, from [?]

1.3 W HY GENOS?
The aim of GENOS mission is to make a step forward in the GRB observations field, providing the
scientific community with a service that is able to exploit the benefits of both strategies. Using a
network of satellites with the same detector on board will overcame the delays in the triangulation
typical of the IPN. Using dedicated HW for fast, prompt and 24/7 satellite communications link it will
be possible to transmit to ground the data needed for the triangulation and compute the location
within ∼ 10 s from trigger time.

So the greatest contribution provided by GENOS will be a very quick communication of the alert
that makes immediately possible a very precise localization of the GRB wherever in the sky. The union
of these three characteristics is not granted by current missions.

Another advantage of the mission it that it will monitor the whole sky with the same kind of de-
tectors, mounted on identical satellites. The analysis of scientific data will take advantage from this
uniformity of conditions, that ease the comparison of experimental results.

Moreover, the detector has been designed by INAF to contribute in particular to the study of
gravitational waves. So benefits for this research field are following as well.

1.4 M ISSION OBJECTIVES

The mission objectives are set by the customer, and are divided into mandatory and nice to have, and
are here reported with a brief explanation. The main objectives are the ones who must be achieved
whatever the final design of the mission:

• Complete celestial sphere coverage 24/7: this implies that the whole celestial sphere shall be
monitored continuously, and that the service supplied by the system shall be available at all
times. Indeed, the satellites shall be fully operative also during the eclipse period of the orbit.

• Detect and localize GRB with an accuracy of 1 arcmin: since the payload, as described in
section 1.6, does not provide any directional information, a system to locate the source precisely

GENOS 3
1 - Introduction 1.5 - Drivers

needs to be developed. The data about the event shall be reported in terms of celestial sphere
coordinates (i.e. right ascension and declination).

• Alert ground within 20 min: end users need to receive the alert of the detection of the GRB
within the specified time, in order to be able to perform science with ground and space assets.
This means that further scientific data (e.g. the energy level) can be down-linked in a second
moment.

Secondary objectives, or nice to have objectives, were also set by the customer, and are:

• European launcher preferred;

• Launch date after 2020: this might be due to scheduled pathfinder missions and to allow a full
development of the detector;

• Preferred single asset to be a microsatellite: this requirement implies that the space segment
should be composed of (if a constellation is indeed designed) satellites that are all the same.
Moreover, the microsatellite requirement sets constraints on mass, volume and power;

• Mission lifetime of 5÷8 years: this implies that, as described in section 1.6, the satellites will
need to be replaced.

1.5 D RIVERS
The design drivers are a specific set of requirement that lead the design process and greatly influence
the decision making process at any level of the project. The drivers for the GENOS mission are the
following:

Science The GENOS mission is devoted to science; in particular, to localize the GRB source, a specific
technique will have to be studied. If the designed system is not able to provide the required accuracy,
the team shall change it and find another solution to the problem. This driver has the highest priority.

Quick communication The alert communication to be performed within 20 minutes is a very strin-
gent requirement, and thus it was chosen as one of the main drivers. In fact, the GENOS satellites
only locates the source of the GRB; but for performing additional observation with Earth and space
telescopes, the information must be very fast in order to make it possible to observe such phenomena.

Reliability This driver is very important regarding the 24/7 operations request. In fact, in order to
be able to provide such service at any time, the system must be failure tolerant, and the performance
shall not decrease if one or more satellites are lost. Moreover, also in case of non-nominal orbits, the
system shall provide the required performance. (da valutare se lasciare l’ultima frase o no, Anna dice
che cambierebbe il design)

Low mass, volume, cost The trend nowadays is to build small satellites with few payloads on board
to reduce the cost of the single satellite, in contrast with what has been done in the past. In fact, the
team decided to use microsatellites class (characterized by a mass below 100 kg).

As it can be seen, the drivers are few, but they will constrain the design in a very critical way.

GENOS 4
1 - Introduction 1.6 - Payload

1.6 PAYLOAD
The payload of each GENOS satellite is composed of 5 detectors. The detectors are under development
at INAF (Istituto Nazionale di AstroFisica), and are composed by:

• Scintillator crystal;

• Photo Detector;

• Collimator.

In Fig. 1.2 is a picture of the detector, while in Tab.1.1 are reported the main characteristics of one
single detector.

Data Value
Dimensions [mm] 100 x 100 x 60
Effective area [cm2 ] 50
Mass [kg] 1
Power [W] 5
X hard energy range [KeV] 10 - 300
Energy resolution 15% at 30 keV
Field of view [°] 160
Temporal resolution [µs] 0.01 - 0.1
Working temperature range [°C] -10 ÷ -20

Figure 1.2: Detector [?] Table 1.1: Detector specifications [?]

1.6.1 Criticalities
Radiation The main criticality of the detectors is the degradation due to radiation. In particular, the
the main effect is due to the bulk displacement damage, which has the effect of increasing the leakage
current, resulting in a worse energy resolution.

Temperature Temperature is also very important for the detector operation. In fact, the higher its
temperature, the higher the leakage current and the noise. The maximum allowable leakage current is
500p A, and from experiments it is known that such current halves every 7◦C of temperature decrease.
Therefore, a good thermal control is needed in order to keep the temperature of the detector within
the specified range. The lower boundary is given by the crystal properties. In fact, if the temperature is
too low, it would crack and become useless.
Moreover, it cannot point the sun, as it would become blind, and it cannot be obscured by other
surfaces.

1.6.2 Rough estimate on lifetime

The INAF research team performed numerical computations using the AP8MIN model in Spenvis to
have an estimate of the payload lifetime depending on the orbit altitude and inclination. The results
are reported in Fig.1.3, and are obtained by assuming a leakage current of 500p A.

GENOS 5
1 - Introduction 1.6 - Payload

Figure 1.3: Detector’s lifetime estimation [?]

As it can be seen, the SSO inclinations are good for the detector only up to 400 km. In fact, above
such altitude, the integral proton flux increases and damages the detector.
This is not true for lower inclinations, in fact at 600 km and 5° the lifetime is much longer.
The real lifetime will be evaluated with a pathfinder mission.

1.6.3 Annealing
The detector’s lifetime can be increased by exploiting an annealing technique, which consists in heating
it and leaving it for 24 hours at a constant temperature of 49°C. The results are reported in Fig.1.4.

Figure 1.4: Annealing

A detector lifetime of 3 years is therefore assumed for the GENOS mission design.

GENOS 6
2 Mission overview

This chapter presents an overview of GENOS mission. Here the main design choices are discussed and
the solution directly coming from the customer objectives and payload requirements is described.

2.1 LEO CONSTELLATION

2.1.1 Localization of the GRB
Starting from the GRB localization objective, the detectors do not provide any relevant information
on the direction of the GRB, as shown in Ch. REF. Therefore, the only localization method that can
be exploited is the triangulation, being it based on the knowledge of the detection time, as already
explained in Ch. REF. This kind of information can actually be provided by GENOS detectors, but more
satellites are needed.

In first approximation, the accuracy of localization can be associated to the annulus width, neglect-
ing how the different annuli actually intersect. The annulus half angle θ and width d θ can be derived
as follows:
c · δT
cos θ = (2.1)
D
d θ = d θtime + d θposition (2.2)

Where c is the speed of light in vacuum, D is the distance between the satellites (called baseline),
δT is the time delay and d θtime and d θposition are given by equations 2.3:

c·σ(T )
(
d θtime = D·sin θ
σ(D)
(2.3)
d θposition = D·sin θ

Where σ(T ) is the time uncertainty and σ(D) is the uncertainty on the relative distance [?].

As it can be deduced by equations 2.3, the larger the distance between the satellites, the more
precise the localization. On the other hand, the payload lifetime is not well known in deep space and it
decreases much in a near-Earth environment at an altitude above 1000 km. Finally, a large baseline
might imply higher launch costs.

2.1.2 GRB alert to ground

Another stringent mission objective is to timely spread the detection alert and the GRB localization.
To accomplish this task a permanent, continuous, fast and reliable link is required. To fulfill all these
requirements is a challenge, especially because a dedicated ground stations network has prohibitive

GENOS 7
2 - Mission overview 2.2 - Localization

costs.

Being obliged to adopt the triangulation method, GENOS is composed by many satellites placed on
different planes, i.e. a constellation. Therefore, the communication issue is multiplied by the number
of spacecrafts.
To overcome this challenge, GENOS team has decided to rely on inter-satellites links services, like
Globalstar or Iridium (see Ch. ??). These services are excellent to spread the alerts but they constrain
the maximum altitude of the constellation, hence the maximum distance among satellites.

2.1.3 Conclusion
For these reasons, GENOS mission is LEO constellation. In fact, as it will be presented in the whole
report, the technological and economical advantages to stay near Earth allows GENOS to fulfill all the
mission objectives.

2.2 L OCALIZATION
As above-mentioned, the triangulation depends on different parameters. The goal of GENOS is to
properly tune these parameters to get a localization accuracy lower than 1 arcmin staying in a LEO
environment.

2.2.1 The annuli thickness

In first place, the localization accuracy is strictly correlated to the annuli thickness. The width depends
on the satellites distance, the position determination and the time determination.

Figure 2.1: Annulus width d θ dependence on distance D and half-angle θ, with σ(T ) = 10µs

The distance effect Increasing the distance between satellites produces a beneficial effect on the
accuracy, as visible in Fig. 2.1 and 2.2. Please note that for two satellites on the same orbit, the

GENOS 8
2 - Mission overview 2.2 - Localization

maximum baseline is two times the semi-major axis. This means that for a LEO the baseline ranges
from 13000 up to 17000 km.

The position uncertainty effect Since the constellation is set in LEO, another great advantage of this
environment is that the satellite position can be computed using a GNSS services. In particular GENOS
team has decided to adopt GPS. Therefore, the relative position uncertainties among satellites σ(D) is
approximately 10 m.

The time uncertainty effect As shown in Fig. 2.2, with a time accuracy larger than 10 µs it is not
possible to stay in LEO, as the width d θ is larger than 1 arcmin, even in the best case possible (θ = 90°).
With very precise clocks, LEO orbits become a feasible solution. Therefore, an atomic clock is needed.

Chip Scale Atomic Clocks Atomic clocks are expensive and massive, hence they are not suited for
a microsatellite. In the last years, there have been some major breakthroughs, which allowed the
development of the Chip Scale Atomic Clocks (CSAC). They are very small (< 17 cm3 ) and light (<
35 g) devices, with a very low power demand (< 120 mW). Moreover, these miniaturized clocks are
space-graded up to 20 krad [?]. These devices are therefore suited for microsatellites.
They can be disciplined with a GPS signal and can provide a time accuracy that ranges from 10 µs up
to 100 ns, thus they accomplish the localization requirements.
Since this is a very critical component, 3 CSAC are installed on each satellite. This allows to have
a warm redundancy but also to exploit a majority voting technique to improve the reliability of the
on-board time.

Uncertainties comparison The uncertainty on the position usually represents a negligible effect
with respect to the time uncertainty [?]. With σ(D) ≈ 10 m and σ(T ) ≈ 10−5 s, the ratio between the
uncertainties will be in the order of:
d θposition
≈ 10−2 (2.4)
d θtime
Therefore, the distance uncertainty will be neglected for the GENOS preliminary analysis. Please
note that with σ(T ) ≈ 10−5 s the absolute position of the satellites needs to be determined with an
uncertainty no larger than 300 m, to have d θposition < 0.1 ∗ d θtime .

The half angle effect Another variable that affects the accuracy is the annulus half angle, that is the
grazing angle of the GRB with respect to the two considered satellites. Indeed, for angles near to π/2
the performance is optimal, while it decreases for smaller angles, as shown in Fig. 2.2.
Since the grazing angle is not a control variable but depends on the GRB direction, to have acceptable
values for any possible GRB, the satellites have to be properly disposed on different orbital planes.

2.2.2 The error box shape

In second place, also the way in which the annuli intersect affects the error box shape and thus the
accuracy.

An example of degenerate case is shown in Fig. 2.3, where the annuli formed by satellites on an
equatorial orbit are tangent, as the GRB belongs to the equatorial plane too. This means that the error
box has an elongated shape and the accuracy is equal to its biggest dimension, that is far larger than
the annuli thickness.
This means that the constellation should be formed by at least two orbital planes.

GENOS 9
2 - Mission overview 2.3 - Coverage

Figure 2.2: Annulus width d θ dependence on distance D and time uncertainty σ(T ), with θ = π/2

Figure 2.3: Degenerate case: tangent annuli

2.3 C OVERAGE
Another important mission objective regards the coverage of the whole celestial sphere. Since one sin-
gle detector is not able to provide such a coverage, GENOS team had to decide between a constellation
made of:

1. Many satellites with a partial view of the celestial sphere.

2. Few satellites equipped with many detectors and able to monitor the whole celestial sphere.

Here it is important to remember that the customer asks for a microsatellite platform. Given the
detector mass, this class of platform is over-sized for the first option. Indeed, a microsatellite can carry
many detectors differently oriented.

Despite this consideration, the second option has been selected to reduce the size and the com-
plexity of the constellation. In fact, it is important to underline that the detector can not work if the Sun

GENOS 10
2 - Mission overview 2.3 - Coverage

(a) The full celestial sphere covered (b) Detail of the "Sun hole"

Figure 2.4: Celestial sphere covered by 5 P/L of 160° FOV. Each color is a detector, the yellow vector points the
Sun

is in its field of view. For this reason, the first option con be applied with one of the following strategies:

1. A pointing strategy. The detector is pointed according to the Sun and satellite position. Moreover,
a coordination is necessary to grant the full coverage of the sky and so the pointing needs to be
studied accounting also for the near satellites position and attitude. This might imply different
configurations among satellites and a complex attitude control, reducing the beneficial effects
of a single space asset. Please note that a dawn-dusk orbit may solve some of these problems,
but unfortunately more than one orbital plane is needed, as explained before.

2. A random strategy. The platforms are designed to be less complex and the attitude control
is much simpler. The coverage problem is solved by increasing the number of satellites in
the constellation, enough to compensate for possible Sun losses and grant a full coverage. A
simplified analysis (see section 3.6) shows that this option leads to a higher launched mass with
respect to GENOS solution.

2.3.1 Number of detectors

As shown in Fig. 2.4, to fully cover the celestial sphere with each satellite, 5 detectors are needed
on-board. The detectors are depicted with colored circles on the sphere. To avoid the Sun, a "hole" is
made, where the Sun direction is pointed by the yellow vector.
The Sun diameter seen from Earth is approximately 0.5°. To be sure to prevent the Sun in the detectors
field of views, a margin has been applied. Therefore, the hole has a radius of 1°, so, in Fig. 2.4, the hole
is represented by a square of 2° × 2° dimension.

Please note that, since both satellite and Sun move in the Earth frame, Sunpointing is needed to
keep the situation shown in Fig. 2.4.

2.3.2 Coverage losses

Since a "full" coverage of the sky is required, the occultation of GRBs due to solar system bodies is
estimated. Please note that Earth’s occultation affects the single satellite but it is counteracted by the
fact that GENOS is a constellation and so the different satellites are spread on the orbits.

GENOS 11
2 - Mission overview 2.3 - Coverage

The coverage of the other celestial body can be expressed in steradians, that can be computed by
definition as:
A π·r2
sr = 2 = (2.5)
d d2
where r is the radius of the celestial body and d the distance between the body and the Earth.

In Tab. 2.1 the occultation due to the main bodies of the solar system and the percentage of
occulted celestial sphere are reported. The main contribution belongs to the Sun hole and the total
occultation is just a small amount with respect to the entire sky.

Since to achieve a "full" coverage requires interplanetary missions, it has been decided to accept
this negligible occultation, avoiding an increment of cost, complexity and risks that are definitively not
worth.

Celestial body Occultation in steradian Occultation in percentage

Sun hole 9.57E-04 sr 7.62E-03 %
Mercury 5,58E-09 sr 4,44E-08 %
Venus 9,84E-09 sr 7,83E-08 %
Moon 6,41E-05 sr 5,10E-04 %
Mars 2,80E-09 sr 2,23E-08 %
Jupiter 2,53E-08 sr 2,02E-07 %
Saturn 5,19E-09 sr 4,13E-08 %
Uranus 2,45E-10 sr 1,95E-09 %
Neptune 9,41E-11 sr 7,49E-10 %
Total 1,02E-03 sr 8.13E-03 %

Table 2.1: Occultation due to solar system main bodies

GENOS 12
3 GENOS constellation and satellite

This chapter gives a brief overview of the nominal solution for GENOS constellation and GENOS
satellite. Reasons and trade-offs behind these solutions will be explained in the following chapters.
Moreover, it is described the numerical tool that has been developed to carry out the analysis and the
design of the constellation.

3.1 GENOS CONSTELLATION AND LIFETIME

GENOS constellation is a Walker 45: 15/3/1. The nominal altitude of the constellation is 500 km and
the three planes have RAAN [0° 120° 240°]. Each plane is occupied by 5 equispaced satellites, so the
constellation is composed by 15 satellites.

The estimated lifetime of the detector on these orbits is of approximately 3 years. For this reason
GENOS satellites are supposed to have same lifetime. To respect the desired mission duration, a
replacement strategy is implemented. In fact, all the 15 satellites will be replaced once.

Walker constellation and replacement strategy are found to be the best compromise between
coverage, localization performance, detectors lifetime and mission operability. A deep explanation
about all these features can be found in Ch. 4.

3.2 R EFERENCE FRAME

As shown in Ch. 2, all the satellites perform a Sunpointing. For this reason, it is now appropriate to
define the body reference frame and the desired attitude frame. Fig. 3.1 presents the body reference
frame of the satellite and it showns the alignment of the body frame with desired attitude frame. The
desired attitude frame is defined as:
 
x̂ body

 ŝ


ŷ =⇒ ŝ ∧ (−ĥ orbit ) (3.1)
 body 
 
−ĥ
ẑ body

orbit

Where ŝ is the versor pointing the Sun in the Earth inertial frame and ĥ orbit is the angular momentum
versor of the orbit. This attitude condition is the goal of the ADCS and is fundamental for localization
purposes.

Finally, the face numbering is reported in Fig. 3.1. Please note that the faces are numbered with
the dice rule and that the Sun pointed face is the number 1. This nomenclature will be used for the
whole report.

GENOS 13
3 - GENOS constellation and satellite 3.3 - GENOS satellite

Figure 3.1: Satellite body reference frame and desired attitude frame. The number specify the face.

(a) Sketch of the spacecraft with reference frame at- (b) Planar view of satellite. Solid arrows represent
tached. the normals to the detectors. Brown and purple
are the superposition of FOVs.

Figure 3.2: GENOS satellite

3.3 GENOS SATELLITE

From the results of the subsystems design, GENOS satellite will look like in Fig. 3.2a. Its prismatic
shape is oriented in space as indicated by the attached frame. The mass at launch is estimated to be
66 kg and the installed power is approximately 125 W. Finally, the stowed dimensions in x̂, ŷ and ẑ
directions are respectively 870 mm, 484 mm and 570 mm.

Referring to Fig. 3.1, it is possible to number all the faces of Fig. 3.2a. The 5 detectors are mounted
one per face, except face 1 that points toward the Sun. As shown in Fig. 3.2b, the detector on face 6 (in
red) is mounted parallel to the platform face. On the contrary, the other detectors are tilted by 9° to
have the desired Sun hole.

3.4 GRB SIMULATOR

In order to properly tune the number of satellites, the orbit parameters and to verify the achieved
localization accuracy, GENOS team has developed a numerical tool to simulate a GRB arrival and
compute the related error box and accuracy. In fact, as mentioned above, the annulus width alone

GENOS 14
3 - GENOS constellation and satellite 3.4 - GRB simulator

Figure 3.3: Error box example

is not sufficient to have a good estimation of the localization performance and thus the shape of the
error box needs to be considered in this study.
Please note that such tool is thought to be exploited at design level, but it could be a base for an
operational software.

The hypotheses behind the simulator are:

1. The constellation is considered fix in time and space.

2. Each spacecraft can monitor the whole celestial sphere except the region occulted by Earth.

3. Negligible position uncertainty and time uncertainty of 10 µs.

Under these hypotheses, the script takes in input the position of the satellites. Then it generates
a grid of GRB to cover the full celestial sphere. Please note that, due to computational speed, the
elements of the grid have a dimension of 10° or 20°.

Knowing the position of the satellites, those in sight of the GRB are selected. Then the relative
distances and annuli half angles are computed for each pair. Bad solutions are immediately discarded,
where bad means:

1. Baseline < 8000 km

2. Annulus half angle < 30°

For each couple of satellites the annulus is defined on the celestial sphere by the celestial coordi-
nates of its center, its half angle and its width.

Once all the annuli have been defined, two annuli at a time are considered and the error boxes at
the two intersections are found. An error box is made by four points at the edges and one point in the
center, as typically done in the IPN catalogs. An example is reported in Fig. 3.3.
The accuracy of localization is considered equal to the longest distance from the corners to the
center of the box. Between the two boxes the correct one associated with the GRB is selected.

By comparing the boxes of all the possible annuli couples, the best box is retained and leads to the
final localization accuracy for the considered GRB. Such method is conservative as smaller error boxes
can be found by considering all the annuli at the same time, instead of intersecting them couple by

GENOS 15
3 - GENOS constellation and satellite 3.5 - Sunpointing analysis

Figure 3.4: GRB simulation with random attitude

couple. For the purposes of this study, this operation is not necessary.

In the present report the numerical tool here described is referred to as GRB simulator.

3.5 S UNPOINTING ANALYSIS

At this point, it should be clear the reasons behind the choice of Sunpointing. Nevertheless, the GRB
simulator has been run by considering a random attitude for each space segment of the nominal
baseline. This means that the Sun is no more excluded from the detectors field of view. Therefore,
some detectors are blind and some satellites do not have anymore an omni-directional coverage.

The assumptions of this analysis are here listed:

1. Baseline detector disposition, with a 160° FOV.

2. If the detector on face 6 is blind, the detectors on face 3 and 4 have a reduced FOV because of
the presence of the solar panels.

3. A GRB is missed by a satellite if it is not in the FOV of any detector of that satellite.

The yellow region in Fig. 3.4 represents the missed GRBs. They are located in the same sky region,
i.e. in correspondence of the Sun. The localization accuracy (in Tab. 3.1) is worse than the nominal
performance, but it is still of the same order of magnitude. In conclusion, localization with a random
attitude is possible, but the complete coverage of the celestial sphere is no more granted. Such results
confirm the need of Sunpointing to fulfill the mission objectives.

Missed GRBs Mean accuracy [arcmin] 3σ accuracy [arcmin]

7.63% 1.66 21.08

Table 3.1: Localization performance with random attitude

3.6 T HE MICROSATELLITE CLASS

To check if the requirement of using microsatellites is actually convenient for the mission, an analysis
has been carried out, making a comparison with nanoplatforms.

For the nanosatellites, the following assumptions are adopted:

GENOS 16
3 - GENOS constellation and satellite 3.6 - The microsatellite class

(a) Percentage of GRBs lost for a SSO constellation. (b) Percentage of GRBs lost for a Walker constellation.

Figure 3.5: Result of the nanosatellites analysis

• Each segment carries one detector on-board, its FOV is still of 160°.

• The satellites have a nadir pointing, with the detector looking at the zenith.

The analysis is performed in a similar fashion of the GRB simulator, but the localization accuracy is
not computed and the GRBs are considered lost if:

• The baseline between satellites is D < 8000 km.

• The grazing angle θ < 30°.

• The angle within planes of 2 annuli is < 30°. This parameter is added to take into account the
bad annuli intersection if the satellites lie on the same plane.

A deeper analysis with the GRB simulator has not been performed because of computational power
issues, as growing the number of satellites the intersections computation becomes onerous.

The analysis has been performed for a Walker constellation and a Sun Synchronous constellation,
both at 500 km altitude. Please note that SSO have been taken in consideration also for the microsatel-
lite solution, but, as shown in Ch. 4, they have been discarded.
The considered Walker constellations are 45: t/3/1, where t varies. The results are shown in Fig. 3.5b.
For the SSO, the mid plane is always a dawn dusk orbit. The remaining two planes are placed at ±∆Ω,
as reported in Fig. 3.5a.

It can be observed that SSO are more efficient than Walker constellations for the nanoplatforms
case. This is due to the favorable condition of the dawn dusk orbit. In fact, under the above-mentioned
hypotheses, on a dawn dusk orbit the detectors avoid always the Sun.
From the figure, a good performance can be achieved for SSO with more than 40 satellites per plane.
However, please note that a 100% success is not obtained even with 60 satellites per plane.

From statistical data, the mass of a LEO nanosatellite carrying on board a 1 kg payload is of about
5.78 kg. Accounting for a 20% of margin, the mass is considered to be 6.94 kg.
The launched mass per plane vs. number of satellites is reported in Fig. 3.6. Please note that GENOS
mass per launch is of about 330 kg, as explained in Ch. ??. It is clear that, depending on the number
of nanosatellites per plane, the microsatellite asset could be more convenient or not. If a degraded

GENOS 17
3 - GENOS constellation and satellite 3.6 - The microsatellite class

performance is accepted, 40 nanosatellites per plane on SSO are a good compromise between local-
ization accuracy and launched mass. On the contrary, microsatellites result more suited for GENOS
performance level.

Figure 3.6: Satellite body reference frame and desired attitude frame. The number specify the face.

GENOS 18
4 Mission Analysis

The aim of mission analysis is the design of the orbit and mission phases capable of satisfying the
mission objectives. The main drivers are individuated in the localization requirements and communi-
cation needs.

4.1 WALKER C ONSTELLATION

As previously presented in Ch. 2, GENOS is a LEO constellation. A Walker delta pattern is adopted
for symmetry reasons. In fact, a symmetric disposition of the satellites grants an almost uniform
localization performance independently from the GRB source position.

The constellation parameters are chosen thanks to the use of the GRB simulator presented in Ch.
3. Many simulation has been ran in order to properly tune each parameter. Please note that to be
conservative, all the simulation presented here use the worst clock performance, i.e. 10 µs.

Number of planes As said, for localization purposes more orbital planes are needed. It has been
decide to use 3 planes to have an higher and more homogeneous accuracy with respect to 2 planes
with the same number of total satellites, as shown in Figs. 4.1,4.2. Moreover, more planes have not
been considered due to difficulties related to the launch strategy and costs.

Figure 4.1: 2 planes accuracy Figure 4.2: 3 planes accuracy

Number of satellites per plane The number of satellite per plane is important to have always a great
baseline, indeed more satellites ensure in most of the cases a distance close to the double of semi-major
axis. As reported in Tab. 4.1, 3 satellites per plane are not enough to localize every GRB with 1 arcmin
accuracy. According to simulation 4 satellites per plane are nominally enough.
To be reliable in case of failure, it has been decided to use 5 satellites per plane, so 15 satellites in
total. Moreover this slightly improves the localization performance.
Finally, always for symmetry reasons, the satellites are nominally equispaced on their orbit.

GENOS 19
4 - Mission Analysis 4.2 - Localization performance

Number of sat per plane Success Worst accuracy [arcmin]

3 86.63 % 2.4
4 100 % -
5 100 % -

Table 4.1: Accuracy for different number of satellite per plane

Inclination Success Mean accuracy [arcmin]

15 60.4% 0.94
30 100% 0.68
45 100% 0.60
60 100% 0.60
75 100% 0.61

Table 4.2: Accuracy for different inclination

Orbit RAAN and inclination To have a good annuli intersection, the orbital plane shall be well
separated in order to have sufficient grazing angle. For this reason, it can be easily understood that
each orbital plane is separated by a 120° RAAN from the others. So nominally, the three planes have
RAAN 0°, 120°, 240°.
For what concern the inclination, a sensitivity analysis with the GRB simulator has been performed:
in Tab. 4.2 are reported the results. As shown, the complete success is granted from 30° on, but the
accuracy is better from 40° to 60°. Since the detector has a reduced lifetime at high inclination (see Fig
??), it has been preferred to set the nominal orbit inclination at 45°.
Please note that thanks to the presence of an accuracy plateau there is a flexibility in the inclination of
the orbits of ± 5°.

Altitude and eccentricity Concerning the eccentricity of the orbits, always to have a symmetric
localization performance, circular orbits have been adopted.

The altitude has been chosen making a trade-off among three different aspects:
• GRBs localization accuracy that betters with larger distance between satellites and therefore a
higher altitude.

• Orbit lifetime that increases with the altitude. In particular orbits below 300 km are discarded for
the too demanding station keeping.

• Detector lifetime that decreases with the altitude.

As a result the nominal altitude of the constellation is of 500 km, selected for a mission duration
of three years.

Summary Finally, GENOS constellation is a Walker 45: 15/3/1 at 500 km altitude with 5 equispaced
satellites per plane. Tab. 4.3 reports the orbital parameters of each satellite.

4.2 L OCALIZATION PERFORMANCE

In this section are presented the results obtained with the GRB simulator for the nominal constellation
illustrated above. Two possible cases are analyzed:

GENOS 20
4 - Mission Analysis 4.3 - Mission phases and ∆V

a [km] e [-] i [°] Ω [°] ω [°] θ [°]

1 6878 0 45 0 0 0
2 6878 0 45 0 0 72
3 6878 0 45 0 0 144
4 6878 0 45 0 0 216
5 6878 0 45 0 0 288
6 6878 0 45 120 0 24
7 6878 0 45 120 0 96
8 6878 0 45 120 0 168
9 6878 0 45 120 0 240
10 6878 0 45 120 0 312
11 6878 0 45 240 0 48
12 6878 0 45 240 0 120
13 6878 0 45 240 0 192
14 6878 0 45 240 0 264
15 6878 0 45 240 0 336

Table 4.3: Starting nominal Keplerian parameters of the constellation

1. Full constellation, in Fig 4.3.

2. One satellite shut down, in Fig 4.4.

The second case is the typical situation, as almost always one satellite of the constellation crosses the
South Atlantic Anomaly region (see Sec. 4.5).

Satellite in SAA Time uncertainty Mean accuracy 3σ accuracy

No 10µs 0.60 arcmin 0.71 arcmin
Yes 10µs 0.62 arcmin 0.78 arcmin
Yes 100ns 0.37 arcsec 0.47 arcsec

Table 4.4: GENOS localization performance

The accuracy that can be granted varies depending on time instant in which the constellation
is considered and on the sky region. Nevertheless, it is almost uniform, as it can be seen from the
deviation from the mean value in Tab. 4.4.

The performance meets the mission objectives, being the mean accuracy lower than 1 arcmin.
Since the CSACs are capable of providing also a time uncertainty of 100 ns, this case has been analyzed.
In Tab 4.4 the achievable localization accuracy with 100 ns is lower than 1 arcsec.

4.3 M ISSION PHASES AND ∆V

The main phases of the mission are reported in Fig. 4.5. VEGA launch consists of 3 segments, described
in detail in the launcher manual [?]:

• Ascent phase to reach the required orbit.

GENOS 21
4 - Mission Analysis 4.3 - Mission phases and ∆V

Figure 4.3: Localization performance [arcmin], with full constellation

Figure 4.4: Localization performance [arcmin], with satellite in SAA

• Ballistic phase with orbital maneuvers of the AVUM for payload delivery in the proper conditions.

• AVUM orbit disposal

There are no stringent requirements on the launch windows that will be selected with the other
co-passengers of the launches.
The ∆Vs are computed with the assumptions of two body problem and impulsive burns.

4.3.1 Phasing
Each satellite performs a phasing maneuver to get the right in plane separation of 72 deg. Fig. 4.6
shows the ∆V cost as function of maneuver time, that is number of revolution in the phasing orbit. The
first impulse lowers the semi-major axis of 36 km and after 25 revolution a second burn re-circularizes
the orbit. 40 hours are selected to avoid large differential perturbation effects but keeping a reasonable
∆V of 40 m/s.

4.3.2 Orbit trim

The AVUM stage can ensure an injection in the desired orbit with a certain degree of uncertainty. These
intervals are described in the launcher manual and are expressed mainly in terms of semi-major axis
and orbital plane. In the case of non precise injection the propulsion system of the s/s is in charge of
the correction, to be performed after the phasing.
In Fig. 4.7 and Fig. 4.8 the trends ∆V for altitude and plane correction are reported. The two
maneuvers are assumed independent since the injection uncertainties should not be correlated. For
the worst case, the resulting costs are 10 m/s for semi-major axis adjustment and 28 m/s for plane
correction, Tab. 4.5

GENOS 22
4 - Mission Analysis 4.3 - Mission phases and ∆V

Figure 4.5: Mision phases

Figure 4.6: Phasing maneuver

Orbital parameter Uncertainty Corrective ∆V

Semi-major axis ±15 km 10 m/s
Eccentricity ±0.0010 -
Inclination ±0.15 deg
28 m/s
RAAN ± 0.2 deg

Table 4.5: VEGA uncertainties and required ∆V

GENOS 23
4 - Mission Analysis 4.3 - Mission phases and ∆V

Figure 4.7: ∆V for altitude correction Figure 4.8: ∆V for plane correction

4.3.3 Station keeping

For GENOS mission, perturbation analysis is important to evaluate the evolution in time of the relative
position of the constellation satellites, and consequently the variation in localization accuracy.
Orbits are propagated with RungeKutta89 with variable step size integrator considering:

• Zonal and tesseral harmonics for gravitational field

• MSIS-2000 model for atmospheric density

• Solar Radiation Pressure (SRP)

• Three body perturbations due to the Sun and the Moon

4.3.3.1 Perturbation

The most affecting perturbations for GENOS orbits are due to gravitational field of the Earth and
atmospheric drag; SRP and three body perturbation effects of the Sun and the Moon are of order of
magnitude lower than the uncertainty introduced by the density model.

Gravitational field Earth’s oblateness causes a nodal regression of 6 deg/day (see ??). Annual RAAN
variation is depicted in Fig. 4.9.

3 n J 2 R e2 µ
r
Ω̇ = − cos i [r ad /s] wi t h n= (4.1)
2 a 2 (1 − e 2 ) a3

Atmospheric drag Estimation of orbits lifetimes are base on ISO standards [?]. Due to 8 years mission
duration, GENOS satellites will face both minimum and maximum of solar activity. Fig. 4.10 show the
result of simulations starting on 2021(solar minimum) and 2024(solar maximum), corresponding to
satellites of launchers 1 and 4 ??. Orbit propagator uses a drag coefficient of 2.2 and an orbit averaged
cross sectional area of 0.61 m2 .
Another effect to be taken in account is the differential decay rate among satellites of the same
plane due to the dynamic behaviour of the atmosphere, responsible for possible variation in relative
phasing. In Tab. 4.6 the effects of differences in semi-major axis are reported. However, simulation
over the whole mission duration does not show a divergence in the difference of semi-major axis, Fig.
4.11

GENOS 24
4 - Mission Analysis 4.3 - Mission phases and ∆V

Figure 4.9: Annual RAAN variation

Figure 4.10: Orbit lifetime estimation

∆a [km] Phasing error [deg/day] Time to reach 20 deg [day]

0.1 0.12 167.38
0.2 0.23 83.69
0.5 0.59 33.47
1 1.19 16.73
2 2.39 8.37

Table 4.6: Effect of differential decay rate on relative phasing

GENOS 25
4 - Mission Analysis 4.3 - Mission phases and ∆V

Figure 4.11: Relative semi-major axis differences among coplanar satellites

4.3.3.2 Station Keeping Strategy

Gravitation perturbation can be left uncompensated because all the satellites have the same inclina-
tion: therefore there is no relative drift among planes of the constellation and localization performance
degradation.

Concerning orbit decay, drag compensation is required during period of maximum of solar activity
in order to ensure an orbit lifetime at least equal to the payload one; while it is not necessary during
quiet part of the solar cycle, as shown in Fig. 4.12. The selected strategy includes up to 2 maneuvers to
raise the semi-major axis from 6858 km to 6878 km with a ∆V cost of 12 m/s each.

Figure 4.12: Drag compensation strategy

For the error in relative phasing, the constellation is very robust in terms of accuracy, in fact it
remains constant even with large errors in phasing, see Tab. 4.6; nevertheless a threshold of 20 deg
in phasing error is fixed to avoid superposition or collision between satellites, keeping in mind that
satellites in adjacent planes are separated at the intersection point by 24 deg. For this reason it is
estimated that re-phasing maneuvers may be required with a frequency of up to 2 per year and cost of
5 m/s each.
The adopted station keeping strategy is a relative one, controlled by the Mission Operation Center,
with no stringent boundaries with the aim to have a common decay rate that an orbit lifetime of at

GENOS 26
4 - Mission Analysis 4.4 - Eclipse duration

Phasing error Success Mean accuracy [arcmin]

±5° 100% 0.70
±10° 100% 0.70
±15° 100% 0.70
±20° 100% 0.69
random < 20 100% 0.70

Table 4.7: Achievable accuracy with phasing error

Figure 4.13: Natural decay time in LEO

least 3 years.

4.3.4 Disposal
The space segment design shall be compliant with ESA standard (ESSB-HB-U-002 [?]), according to
which the presence in the LEO protected region is limited to maximum of 25 years from the end of
mission. For GENOS mission an uncontrolled re-entry is selected thanks to the fact that the satellite
mass over area ratio ( 100 kg/m2 ) surely grants a natural decay in less than 25 years, as shown in Fig.
4.13.
Before atmospheric re-entry, total passivation shall be ensured to avoid unexpected break-ups. It
includes:

• Depletion burns

• Pressurant venting

• Battery discharge

The spacecraft operative phase ends with the death of the payload, whatever the reached altitude.
Then passivation is performed to allow a safe natural decay. Replacement can happen during last
phases thanks to different altitudes.

4.4 E CLIPSE DURATION

An important output of mission analysis is the eclipse duration, especially for electrical power and
thermal control subsystems.

GENOS 27
4 - Mission Analysis 4.5 - South Atlantic Anomaly

Figure 4.14: Shadow of the Earth model

Under the hypothesis that the Sun-spacecraft can approximated by the vector Sun-Earth, the Earth’s
shadow has been modeled as in Fig. 4.14. Since the position of the Sun and the position of the space-
craft are known, the software computes the value of x by performing the dot product between the
position vector r and the Sun direction ŝ. If this value is positive it means the spacecraft is between the
Sun and the Earth, while if it is negative, it may be in umbra. In this case, the algorithm computes the
value of h: if it is smaller than the Earth’s radius, it means that the satellite is in eclipse.

The eclipse duration is then computed for a whole year. It is arbitrary chosen 2020 as reference
year, but it must be highlight that the eclipses are periodic on a period of one year. The resulting plot
have been reported in Fig. 4.15. The maximum eclipse duration is approximately 36 minutes and the
minimum is about 22 minutes.
Please note that due to RAAN drifts, the actual orbital planes change. Therefore, as above-mentioned
the 3 planes remains separated by 120° of RAAN, but the RAAN absolute magnitude goes from 0° to
359°. This means that, although the three pictures are different, each orbital plane will encounter all
the three situations depicted in Fig. 4.15.

4.5 S OUTH ATLANTIC A NOMALY

Time spent in South Atlantic Anomaly(SAA) is important to know how long a GENOS payload has to be
switched of because of the too high background noise. (? non sono sicuro di aver capito bene il motivo
dallo scienziato) For preliminary analysis the SAA is considered as a fixed region, Fig. 4.16, and time
spent in it computed for different inclination, Tab. 4.8. The percentage is referred to the total mission
duration, taking in account the perturbation effects. For 45 deg inclined orbit the time spent in SAA is
the 7.3%; therefore, considering 15 satellite, statistically one is always in the SAA region, i.e. switched
off.

4.6 B ACKUP O RBITS

SSO related to launch
Data of the orbits
Accuracy

The Sun Synchronous Orbits(SSO) are the main backup solution, they can represent a replacement
for the whole constellation but also an addition to reduce the time to be operative. The main drawback
is the shorter payload lifetime, see Ch. ??.
Considering SSO orbit and 2 or 4 platform launched as secondary payload, different mixed constel-
lation configurations are evaluated. In order to verify the compliance with the accuracy requirement,
simulations have been performed to estimate the performance in detection achievable with the
proposed solutions.

GENOS 28
4 - Mission Analysis 4.6 - Backup Orbits

(a) First orbit plane: Ω = 0°

(b) Second orbit plane: Ω = 120°

(c) Third orbit plane: Ω = 240°

Figure 4.15: Plots of the eclipses duration for the year 2020

Inclination % of total mission time in SAA

15° 5.72
30° 8.94
45° 7.35
60° 4.84
75° 4.15
SSO 4.00
Figure 4.16: South Atlantic
Anomaly region Table 4.8: Time spent in the SAA

GENOS 29
4 - Mission Analysis 4.6 - Backup Orbits

Tab.4.9 shows the results for different combinations using one or two SSO plane with 2 or 4 satellites
and different planar separation in case of two SSO planes. The mean accuracy value takes into account
the fact that the configurations are not symmetric, so the relative disposition changes under the
perturbations effect. In particular the nodal regression causes a relative drift of 5 deg/day between the
45 deg Walker plane and the SSO orbits.

Success Mean accuracy [arcmin] Worst accuracy [arcmin]

1 plane 45°(5 sat) - 1 plane SSO
2 sat SSO 27.92% 10.08 1220.18
4 sat SSO 57.79% 0.96 1.78
1 plane 45°(5 sat) - 2 plane SSO(2x2 sat)
∆Ω = 90° 63.96% 1.01 3.15
∆Ω = 60° 70.51% 0.99 3.14
∆Ω = 40° 76.94% 0.92 2.65
∆Ω = 20° 74.83% 0.93 2.48
For comparison
Walker 45° 15/3/1 100% 0.56 0.71
5 sat 0° + 4 sat SSO 98.70 0.70 1.08

Table 4.9: Accuracy performance for different constellation configuration

GENOS 30
5 Propulsion susbsytem

In this chapter the propulsion subsystem design process and final architecture will be reported.

5.1 ∆V BUDGET
First of all, the ∆v budget must be analyzed, reported in table 5.1.

Maneuver ∆V [m/s]
Altitude correction 10
Inclination correction 28
Phasing 40
Drag compensation 70
Total 148

Table 5.1: ∆V budget

As it can be seen, the total required ∆v is not very high, and a relevant part of it is given at the
beginning of the mission, as soon as the satellites are deployed by the launcher. In fact, orbit correction
and phasing must be performed as soon as possible.
Moreover, it must be noted that the considered drag compensation ∆v accounts for 4 years of opera-
tions instead of 3, in order to take into account a possible extension of the payload lifetime. Therefore,
no other margin is considered for the ∆v.

5.2 T ECHNOLOGY SELECTION

Various technologies are available nowadays for the propulsion subsystem, and can be divided into
two main categories:

• Chemical propulsion: exploits chemical reactions to heat the propellant gases, and then expand
them through a nozzle;

• Electric propulsion: this technology exploits electric power to heat up or ionize propellant. The
achieved I s is very high, but so is the required power.

The drivers for the selection of the propulsion subsystem architecture are the power demand and
the propellant mass. The power demand is very constraining, since the power budget of the GENOS
satellites is very low. Moreover, the thrust level must be such that the maneuvers can be performed in
a time in the order of 1% of the orbital period. If such condition is respected, it is possible to assume
an impulsive maneuver [?]. This is useful also for the phasing maneuvers, since a low thrust option
could cause some problems in the relative phasing of satellites due to the long time needed for the

GENOS 31
5 - Propulsion susbsytem 5.3 - Thruster selection

maneuver.
By considering a period T = 5676s, a required thrust of roughly 35 N is required. However, this re-
quirement can be relaxed by imposing a high precision for the attitude control subsystem during
the thruster firings. In fact, with a precision of 1°, the gravity losses due to thrust misalignment are
negligible and a longer burning time is acceptable (e.g. in the order of 3 to 4 minutes).
A range for the specific impulse (I s ) must also be set. To obtain a not too high propellant mass, a value
between 200 s and 300 s is considered acceptable.

5.3 T HRUSTER SELECTION

Having defined the thrust level and the I s range, the team carried out a research of the available
thrusters on the market, focusing in particular on mono-propellant solutions.
The result of such research produced two main viable options for the team:

• Bradford ECAPS 22N HPGP: this thruster makes use of the ADN-based LMP-103S green mono-
propellant and has a nominal thrust of 22N;

• Arianegroup 20N hydrazine thruster: this thruster has a very high orbital experience.

The first solution would be the most suitable, because LMP-103S propellant has higher performances
than hydrazine in terms of I s and propellant density. However the TRL of the considered thruster is
too low for the GENOS mission.
Therefore, the selected thruster is the Arianegroup 20N hydrazine thruster, which has the characteristics
reported in table 5.2.

Parameter Value Unit

Thrust range 7.9 to 24.6 N
Specific impulse 222 to 230 s
Mass 0.65 kg

Table 5.2: Thruster specifications [?]

Firing tests will be required in order to fully characterize the actual performances and behaviour.

5.4 P ROPELLANT MASS BUDGET

Having selected the thruster, it is then possible to compute the required propellant mass. The compu-
tation is performed by exploiting the Tsiolkovsky equation:
h ¡ ∆v ¢ i
m p = m d r y exp −1
Is g0
The following margins are then applied:

• 20% for reserves;

• 3% for leftovers;

• 0.5% for loading uncertainties.

After having computed the propellant mass and volume, the mass of pressurizer must be computed.
The propellant mass budget is reported in the following table:

GENOS 32
5 - Propulsion susbsytem 5.5 - Propulsion subsystem architecture

Parameter Value Unit

Propellant mass 3.6 kg
Margined propellant mass 4.4 kg
Propellant volume 4.24 l
Pressurizer mass 0.06 kg
Pressurizer volume 1.76 l

Table 5.3: Propellant mass budget

5.5 P ROPULSION SUBSYSTEM ARCHITECTURE

The propulsion subsystem is composed of a diaphragm tank, the thruster assembly and the feed
line. The pressurization is performed with a blow-down solution, chosen because of its lower mass
and complexity with respect to the other possible solution, the regulated pressure architecture. The
main problem of such a solution is that pressure is allowed to decay with firing time, therefore the
performances of the engine (thrust, I s ) will decrease as well. This is an aspect which must be taken
into account, as the firing time at the end of life will be higher.
In Fig.5.1 the preliminary architecture is reported.

Figure 5.1: Propulsion subsystem architecture

Diaphragm tank
For this reason, a diaphragm tank must be adopted, in order to separate the pressurizer from the
propellant, and to grant a positive expulsion in 0g conditions.
The Rafael PEPT-230 tank is the chosen one, as it satisfies the volume and pressure requirements. It is
a titanium spherical tank with a diameter of 230mm with equatorial mounting and 6 l of total volume,
with a maximum of 4.5 l of propellant.

GENOS 33
5 - Propulsion susbsytem 5.6 - Future developments

Sensors and valves

Several sensors must be placed over all the subsystem parts to monitor pressure and temperature. In
particular, temperature sensors are placed on the tank, on the feed line and on the valves, and they are
coupled with heaters, in order to prevent hydrazine from freezing.
Pressure sensors are needed in order to keep under control the propellant mass available in the tank.

5.6 F UTURE DEVELOPMENTS

As reported above, one criticality of the propulsion subsystem is the titanium tank. However, if alu-
minum tanks are available at the date of construction, they shall be chosen in order to comply with the
ESA guidelines for space debris.
Another big point is the toxicity of Hydrazine. During the design of the subsystem, particular attention
has been given to the green propellant solution. However, no sufficiently developed green mono-
propellant thruster was found on the market. In particular, the Bradford ECAPS could be the reference
option if its TRL increases. Such thruster makes use of LMP-103S, an Ammonium DiNitrimide (ADN)
based propellant.

GENOS 34
6 Telemetry-Tracking & Commands

6.1 O BJECTIVES AND DRIVERS

The main objective for the telecommunication subsystem is to sent an alert to ground of the detected
Gamma Ray Burst in less then 20 minutes. To accomplish this task the subsystem has to ensure a
fast communication and a reliable link. The alert is a small string of data (it amounts to about 1
kbit) containing the position of the spacecraft and the trigger time of the event. On the other hand
the subsystem has to guarantee also the download of a scientific packet of data from each detector,
containing the energy level of the GRB event. To accomplish those tasks two different architectures are
used due to the link characteristics and the type of data to be downloaded. The architecture for the
TT&C subsystem is described in section 6.2, along with its design procedure. Mass and power budget
are reported in the conclusion section 6.3.

6.2 A RCHITECTURE
Two different types of architecture are selected. For GRB alert it was decided to take advantage from
a link with a satellite constellation while for the scientific data a ground station network is used. In
particular, GRB alert will be send to ground through Globalstar which is a constellation of satellites in
Low Earth Orbit. Differently, the science is downloaded with patch antennas to LeafSpace network,
which plans to build 20 ground stations all over the world before the end of 2020.

6.2.1 Globalstar
A ground station network was discarded for the design of the link through which alert is downloaded.
This choice was taken since it is not possible to guarantee 20 minutes between one passage over a
ground station and the next one. Moreover the cost to have stations always available is very high. The
alternative to ground stations is an link with other satellites and two possibilities have been taken into
account: Globalstar and Iridium constellations. They were selected thanks to the fact that they can
ensure full coverage for satellites in LEO (with the exception of latitudes higher than 70° North and
lower than 70° South for Globalstar). However, Iridium constellation was tested on one mission only
and has a very low data rate (max 2.7 kbps). These are the main reasons for which it was discarded.
On the other hand, Globalstar constellation has already been tested on four missions with an on-orbit
success rate of 100% at altitudes between 110km to 700km. It provides 24/7 real time data, has a
Technology Readiness Level of 9 and has a higher data rate (7 kbps). Even if Iridium has lower costs
than Globalstar, the latter is in any case a low cost solution since its prices are not comparable with the
ones for ground stations passages. [?] In order to exploit it, a very light and small device needs to be
mounted on the spacecraft, the Eyestar-D2 device (Fig. 6.1).
The NSL (NearSpace Launch) server communicates via the Globalstar network to send and receive
satellite data. All data is logged and archived on the server. The database performs real-time replication
to a backup server. The typical full path latency from satellite to the NSL server is under 30 seconds.

GENOS 35
6 - Telemetry-Tracking & Commands 6.2 - Architecture

The NSL server web API provides the programming capability to send and receive all data streams over
the Internet, that includes receiving telemetry packets, sending and receiving data files, sending SMS
commands.[?]
Two Eyestar-D2 devices are mounted on each spacecraft, for redundancy reason, to be sure to be
able to communicate the alert also in case of failure. Gobalstar device has two main drawbacks: it does
not have a GPS integrated and it can’t communicate if the spacecraft spins more than 0.25 rpm.

Figure 6.1: Eyestar-D2 device

Parameter Value
TRL 9
Data rate 7000 bits/s
Dimensions 6.1x11.9x2.2 cm
Weight 138 g
Input voltage 7÷20 V (10 V nominal)
Supply power 0.5 W RX - 4.5 W TX
Temperature -50°C ÷ +85°C
TX frequency 1610÷1625 MHz
RX frequency 2484÷2499 MHz
Antenna patch antenna integrated
Channel access CDMA Code division
Link Margin high, no atmosphere

Table 6.1: Globalstar parameters

The backup solution to Globalstar is Iridium constellation, also in case SSO orbits would be
exploited, since Iridium guarantees coverage also for high inclined orbits. IridiumShort Burst Data
(SBD) is a simple and efficient network transport capability for transmitting short data messages
between equipment and centralized host computer systems. Parameters of the Iridium 9603 device to
put on the spacecraft can be found in Tab. 6.2

GENOS 36
6 - Telemetry-Tracking & Commands 6.2 - Architecture

Parameters Values
Dimensions 31.5x29.6x8.1 mm
Weight 11.4 g
Temperature range (-40 ÷ +85)°C
Frequency (1616 ÷ 1626.5) MHz
Data rate up to 2.7 kbps
Input voltage 5 ± 0.5 V in DC

Table 6.2: Iridium 9603 device

6.2.2 LeafSpace
In the TT&C subsystem a second mode is defined due to the fact that the payload data are heavy. They
amount to 10 Mbytes per detector and they contain the energy level of the GRB event. For this reason
a higher data rate is needed and a ground network is selected. S band is chosen thanks to the high
data rate it can provide. Since the GENOS mission is in Low Earth Orbit, small dishes are enough to
receive the data from the micro-satellites. Misalignment losses are negligible and the space one are
contained. For all these reasons LeafSpace network is selected (Fig. 6.2): it can work in S band, has 3m
dish antennas with a gain of 33.7 dBi. [?] Two patch antennas per satellite are used to interface with
ground in order to ensure redundancy and to have more possibilities to communicate (they are not on
the same face, for details see Ch.[rifer. config.]). Patch antennas are selected since they work in S band,
are very small and light, do not need deployment mechanisms and can provide a wide beam width.
Due to their low directionality, these antennas can generally maintain a communication link even
when the spacecraft is tumbling, which is advantageous for small satellites lacking accurate pointing
control.

Figure 6.2: LeafSpace network

A back up solution in case of problems with LeafSpace network has been selected: the RBC Signals
ground station network, in Fig. 6.3. It consists of infrastructures around the globe providing low-
latency, low-cost communication services to spacecraft operators. It provides real-time access to
satellites in Low Earth Orbit, working in UHF, S- and X-band. The network antennas range from
2.4m to 11m in diameter, and can support a wide variety of data rates, polarizations, and modulation
schemes. [?]

GENOS 37
6 - Telemetry-Tracking & Commands 6.2 - Architecture

Figure 6.3: RBC signals network

6.2.2.1 Patch antenna ad transceiver

Typical characteristic of a patch antenna are listed in Tab. 6.3. [?] The patch antenna is linked to the on
board computer through a transceiver, with characteristics like the ones reported in Tab. 6.4. [?]
Each antenna is considered both for transmission and reception. For this reason only one
transceiver is needed (Fig. 6.4). No redundancy is considered since other two antennas (Global-
star ones) are present on each satellite. Two transceivers can be put if more redundancy is needed.
Please note that the two functionalities (transmission and reception) can be splitted between the
antennas but in this case two transceivers and four antennas are needed in order to have the same
contact conditions.
Considering the configuration, the communication subsystem electronics shall be located as close to
the antenna as possible to minimize cable losses. Thanks to sunpointing attitude and antennas on
opposite faces of the satellite, no pointing is needed.

Figure 6.4: Antenna and transceiver

A block scheme of the transceiver linked to the antennas is build, as can be seen in Fig. 6.5.
It is a Software Defined Radio architecture: the broad implication of the term software defined is
that different waveforms can be supported by modifying the software or firmware but not changing
the hardware. SDR is a radio class that could be re-configured or re-programmed so it offers flexibility,
reconfigurability and scalability. SDR architecture is developed based on conventional radio functions
but the difference is that all functions of signal processing on conventional radio are carried out fully
by hardware while the functions of signal processing on SDR are carried out as much as possible
by software. If devices are mostly hardware based, reprogramming or reconfiguration options are
minimal, at least regarding radio functions. This lack of flexibility is disturbing in the sense that if an

GENOS 38
6 - Telemetry-Tracking & Commands 6.2 - Architecture

Parameter Value
TRL 9
Frequency range 2100÷2500 MHz
Gain max 6 dBi
Temperature -30°C ÷ +50°C
Impedance 50 Ohm
Dimensions 70x70 mm2
Weight 49 g

Table 6.3: Patch parameters

Parameter Value
S band operation 2025-2300 MHz
Data rate Sat2Ground up to 20 Mbps
Data rate Ground2Sat up to 256 kbps
Operational mode FDD / full-duplex
Low power consumption 3 - 4.5 W rx and 8 - 12 W tx
DC supply voltage 7 – 18 V
Ultra small volume 50 x 55 x 94 mm3
Low mass < 190 gram
Operational temperature -20 ÷ +50 °C
Switch-on temperature -30 ÷ +60 °C
Non-operating temperature -40 ÷ +65 °C

Table 6.4: Transceiver specifications

Figure 6.5: Transceiver architecture

GENOS 39
6 - Telemetry-Tracking & Commands 6.2 - Architecture

error occurs then generally there is no way to correct the problem.

The major key in building SDR is the placement of ADC and DAC components as a divider between
analog and digital domain, thus the signal processing can be carried out using software. Analog signal
is processed by hardware, while digital signal is processed by software.

6.2.2.2 Contact analysis

For the patch mode the number of contacts and their duration have been analyzed. A simulation was
carried out considering latitude and longitude of the ground stations, both for the nominal and the
back up solution. For the LeafSpace network three hypothesis have been done:

• Number of ground stations: 20.

• Elevation angle: 10°.

• Antenna beam width: 90°.

Exact ground contacts are computed using GMAT software, considering the Leaf Space ground
network, with a minimum elevation angle of 10°. The software individuates all possible contacts, but
not all of them are suitable to the communications in the science phase because of the Sunpointing
constraint on the satellite orientation. Patch antennas on faces 2 and 5 (opposite) are able to com-
municate when they are approximately parallel to the Earth surface. This condition is verified when
the zenith direction of the ground station location is perpendicular to the Earth-Sun vector, which
occurs when the apparent solar time is 6:00 or 18:00. A range of ±15° out of the normal to the surfaces
is assumed valid in order to select the right contact events, corresponding to ±1 hour in the ground
station’s local time.
During the science observation phase the mean number of contacts in one day is 75 and their mean
duration is of 120 seconds but only 14 lasts more than 3 minutes. The average separation between two
passages is in the order of less than 3 hours but single interval with no useful contact can be up to 10
hours. During separation, acquisition and detumbing phase, a simulation was computed considering
the spacecraft spinning at 5 degrees per second. In this case the mean number of daily contacts is
higher than 500 but the mean duration is only of 14 seconds.
For RBC Signals network the mean number of daily contacts is 52 with a mean duration of 132 seconds:
13 of them lasts more than 3 minutes so good in case it is necessary to lean on this solution.

Figure 6.6: Ground track for LeafSpace network

GENOS 40
6 - Telemetry-Tracking & Commands 6.2 - Architecture

6.2.2.3 Link budget

The link budget for the patch mode in the operational phase is reported in Tab. 6.5. During the
operational phase the most important task the patch antennas has to do is to download the scientific
package of data. Considering a beam width of 90 deg and a gain of 2 dB the contact at ground reduces
to 3 minutes each so a data rate of 450 kbps is selected. In this way it is possible to download one
payload package of scientific data per passage so 3 passages are needed to download 30 MBytes of data
per spacecraft. Note that it was assumed that only 3 payloads on one spacecraft see the GRB event.
The coding scheme selected is BPSK because it makes a good use of the spectrum, it is less complex
than for example QPSK, it is more reliable in term of phase errors and it is characterized by a good BER.
In Fig.6.7 is reported the value of the energy per bit over noise density (EbN0) with different data rates
and powers and can be seen that with the selected data rate, a power of 2 W ensures a value for the
EbN0 of 23.4 dB.

Phase Downlink science Unit

Parameter
Freq 2.2 GHz
Range@10° 1695 km
Data
BER 10−5
Cod.Scheme BPSK
Data rate 450 kbps
Receiver
Gain - dBi
Ts y s - dBK
G/T 11.7 dBK
Transmitter
Gain 2 dBi
PT X 2 W
Line Loss -1 dB
EIRP 4.01 dBW
Path Losses
Ls -163.87 dB
La -0.5 dB
Budget
Eb/N0 req 9.6 dB
Eb/N0 23.4 dB
Margin 13.8 dB

Table 6.5: Link budget for the operational phase

GENOS 41
6 - Telemetry-Tracking & Commands 6.2 - Architecture

Figure 6.7: EbN0 [dB] for science data download

The link budget for the patch mode in starting phase and safe mode is reported in Tab. 6.6. When
not used for science observation phase, the two patch antennas can be used for separation, acquisition
and detumbling phases. In those situations the antennas need to download telemetry and upload
commands. The selected data rate are respectively of 250 kbps and 80 kbps.
Considering these data rates, the results in terms of EbN0 are reported in Fig.6.8a for the telemetry
download and in Fig.6.8b for the commands upload.

Patch antennas, along with Globalstar ones, are extremely important also in the safe mode of the
satellite. The TMTC safe mode is defined by the following procedure:

• Use patch antennas during detumbling.

• Use patch antennas during slewing to sun.

• Use Globalstar antennas during pointing.

After sun pointing if there is no confirmation from Globalstar communication the decision is to try
patch antennas. A simulation has been carried out for a random tumbling condition and it was found
out that the mean time for contact in the worst case of 10 deg per second is 7 seconds. Considering a
data rate of 250 kbps in downlink the telemetry that can be downloaded in one passage is of 1.7 Mbit.

GENOS 42
6 - Telemetry-Tracking & Commands 6.2 - Architecture

Phase Uplink commands Downlink telemetry

Parameter
Freq 2.1 2.2 GHz
Range@10° 1695 1695 km
Data
BER 10−7 10−7
Cod.Scheme BPSK BPSK
Data Rate 80 250 kbps
Receiver
Gain 2 - dBi
Ts y s 29 - dBK
G/T -27 11.7 dBK
Transmitter
Gain - 2 dBi
PT X - 1.5 W
Line Loss - -1 dB
EIRP 43 2.76 dBW
Path Losses
Ls -163 -163 dB
La -0.5 -0.5 dB
Budget
Eb/N0 req 10.5 10.5 dB
Eb/N0 31.5 24.7 dB
Margin 21 14.2 dB

Table 6.6: Link budget for starting phase and safe mode

(a) EbN0 (dB) for telemetry download (b) EbN0 for commands upload at EIRP 43 (dB)

GENOS 43
6 - Telemetry-Tracking & Commands 6.3 - Conclusions

6.3 C ONCLUSIONS
The modes for the TT&C subsystem are two: Globalstar mode and patch mode (or combined). For a
detailed description of operations related to telecommunication modes please refer to Ch.[capitolo
fasi e modi]. In conclusion the depicted design is robust enough to guarantee always a connection to
ground. From Globalstar technology characteristics the Gamma Ray Burst alert can be downloaded
in less than 1 minute so accomplish one of the most important objective of the GENOS mission. The
scientific data are send to ground within 1 day so respecting the customer requests.

6.3.1 Mass and power budget

In this sub-section the current mass and power budgets are reported, considering also 5% margin for
the mass and 25% margin for the power. The Tab. 6.7 shows the mass budget while the Tab. 6.8 shows
the power budget. The values are referred to the architecture specified in section 6.2.

Element Value [kg] Amount Total mass [kg]

Eyestar-D2 0.138 1+1 0.276
Transceiver 0.190 1 0.190
Patch antenna 0.048 2 0.096
TOTAL 0.562
TOTAL WITH MARGIN 0.5901

Table 6.7: Mass budget with margin

Element Max value [W] Amount Total max power [W]

Eyestar-D2 4.5 1+1 4.5
Transceiver 12 1 12
Patch antenna 2 2 4
TOTAL 20.5
TOTAL WITH MARGIN 25.62

Table 6.8: Power budget with margin

GENOS 44
7 On Board Data Handling

7.1 I NTRODUCTION
The On Board Data Handling (OBDH) subsystem is in charge of commanding and monitoring all other
spacecraft subsystems, carrying and storing data in the various electronics units and managing the
health data and status of the system which must be kept on track. It is responsible for all on-board
operations and it must take care for a large variety of applications for the correct functioning of the
whole system.
In this chapter a detailed analysis of the OBDH system design is presented, with the objectives of
estimating the main quantities needed to size the system (throughputs and memory size) starting from
data requirements, defining a preliminary architecture, evaluating the mass and power budgets, and
highlighting the principal constraints and inputs for the other subsystems.

7.2 R EQUIREMENTS
Deriving directly from the mission objectives the main requisite for the OBDH s/s is properly handle
the scientific data generated during the mission.
Every GENOS satellite hosts 5 GRB detectors and each of them is provided with a dedicated instrument
data unit, responsible for the science data generation, processing and management. In particular an
algorithm for the prompt burst alert is implemented in order to perform the triangulation method
for the GRB localization. This alert consists in a short packet of data comprehending the state of
the spacecraft and the time trigger of the event occurrence. The data volume related to the alert is
estimated to be about 1 kb [?]
The scientific data produced by a detector for a GRB event is considered 10 MB in average. However
for the sizing of the PL data storage capacity, peak GRBs of 1 Gb are considered and the fact that
multiple events could occur in a brief time interval is also taken into account. On the other hand,
the platform data management requires a much more standard and simple design. In the following
section a complete assessment of the system applications and data rates is reported. In figure 7.2 are
reported the bitrates relative to the sensors present on board. Knowing the total datarate and the time
of no communication for the TM downlink, it is possible to evaluate the minimum size for the mass
memories to put on board.The requirements for the HK data volume necessary to store data during no
connection windows are determined with the following considerations:

• No Globalstar network available (due to service mis-functioning or platform failure)

• Maximum time interval between passages (at least 3 minutes long) over 2 consecutive ground
stations (10 hours) plus margin for 1 missed link opportunity (5 hours)

For a precise list of system requirements refer to the requirements document attached.

GENOS 45
7 - On Board Data Handling 7.3 - Functionalities

7.3 F UNCTIONALITIES
The OBDH performs two major functions:

• it receives, validates, decodes and distributes commands to other s/s

• it gathers, processes and formats housekeeping (HK) and mission data for download or manage-
ment by an On Board Computer (OBC)

Additional functions integrated are: s/c timekeeping, computer health monitoring (watchdog) and
security interfaces.
These are the reference functions used for the definition of a favorable architecture, the functional
blocks used according to the operations required and driving the selection of the components. They
have been selected following the general functional scheme proposed by ESA SAVOIR. 7.1

Figure 7.1: ESA SAVOIR functional architecture

Commands processing Commands for the OBDH subsystem can be provided by uplink from ground
stations or through a relay network, but can also be stored commands. They are received and validated
by a decoder unit, processed and then distributed to the addressed subsystem.

Telemetry processing The system acquires data for spacecraft health and status, feedback for on
board control of spacecraft functions and routing of P/L and subsystems data for communication or
storage in memory units. Data are collected and processed in form of packets and frames using CCSDS
standards.

Security interfaces This function includes security standardized protocols to protect the spacecraft
from receiving unauthorized commands and to protect sensitive information by encryption during
transfer.

GENOS 46
7 - On Board Data Handling 7.4 - Operations breakdown

Autonomy Different applications can be stored inside the OBDH subsystem to reduce the need to
communicate with ground operators. Simple autonomy application is implemented whenever the
satellite can communicate with ground with little issues in terms of link availability and data rates
limitations.

On board time distribution and synchronization To support the AOCS system, manage stored
commands or time-tag data with a time word (essential for prompt burst alerts), an On Board Time
(OBT) function is required. Several systems can provide this time, for example GPS receivers, computer-
maintained counters or atomic clock devices. In GENOS satellites Chip Scaled Atomic Clocks (CSACs)
are used to fulfill this function, while GPS signals are needed to recalibrate the clocks. See section
.....LUCA... for more details regarding the CSAC device.

Fault Detection, Isolation and Recovery (FDIR) The two main approaches to provide software meth-
ods for tolerating faults are redundancy and distributed processing. Whenever internal errors or
environmental effects prevent the OBC to work correctly, it can be automatically restarted thanks to a
watchdog timer. On the other hand an Error Detection and Correction (EDAC) circuitry is included to
clean stored data from a bit error in memory words.

AOCS management This function is considerably mission dependent and it strictly relates to the
actuators and sensors selection. Therefore with respect to the type of ADCS system adopted its level of
complexity will vary accordingly.

Power management It controls battery charge and discharge and monitors the power bus. It checks
peak voltages or currents and commands switches of devices status.

Thermal control It involves monitoring and controlling temperatures throughout the spacecraft. It
guarantees the required thermal conditions and ranges for the equipment on board. In particular,
concerning the detectors, thermal control is required to manage the annealing cycle of the crystals
which is operated through resistors dissipating heat.

Payload management This function can be performed directly by the OBC otherwise it is supported
by a dedicated payload data system. It consists in scientific data collecting, processing and stor-
age, implementing the burst trigger algorithm for GRB detection, instrument controlling and power
distribution.

Operating system functions This category includes a variety of software functions such as the exec-
utive to schedule the application software and other operating system functions, the run-time kernel
software to support higher-order languages, I/O device handlers to deal interfaces between processor
and peripheral devices and other utilities like built-in test and math utilities.

7.4 O PERATIONS BREAKDOWN

In order to carry out a meaningful design process and have a good estimation of the computer system
requirements, it is recommended to define in advance which are the phases characterizing the OBDH
system during the mission and which operations it shall perform.

GENOS 47
7 - On Board Data Handling 7.5 - Sizing

Initialization After the separation of the spaceraft from the launch vehicle, the power application
makes the OBC begin functioning. Considering 2 CPUs (in warm redundancy), one is configured to be
power-on and the second to be power-off.

Check out The bootcode is downloaded to analyze several checks for the initialization success and
status of the electronics on board in order to ensure that the computer can continue to perform as
required once operational .

Nominal operations During the operational life of the system the CPU remains active, managing
TC and TM data stream, application and operation system functions. In particular it shall control the
payload and handle the mission data. Each detector is provided with a dedicated unit which has the
fundamental role of implementing the trigger algorithm and event detection codes.

If the OBC stops executing or it performs instructions in a incorrect sequence then it needs to restart.
This might be caused by a Single Event Latch-up (SEL) or software errors. A watchdog timer allows to
reset it automatically but afterwards it must be reconfigured. The software code is reloaded from the
non-volatile EEPROM memory in the safeguard module.

For the assessment of the OBDH requirements the most critical case in terms of data throughput
and storage is considered, that is the nominal operational phase, in which most of the application
programs are run. In addition to these estimates other functions like security interfaces and FDIR
management are included to contribute to the overall sizing.

7.5 S IZING
The sizing of the OBDH system is reported in table 7.2. Once the initial software size estimation process
is completed the hardware resources can be identified. For each functional group, given its execution
frequency expressed in Hz, the software size is measured by bits of memory and the processing time
by throughput (THR) which is expressed in thousands of instructions per second (KIPS).
For AOCS block functions the size and throughput estimates were based on the method of similarity
proposed in ?? starting from typical values valid for a 16-bit general purpose processor.
In table 7.1 the total required throughput and mass memory size are summarized.

Table 7.1: Throughput and size budget

MINIMUM THROUGHPUT 2412 KIPS

MINIMUM MEMORY SIZE (HK) 243 Mbits
MINIMUM MEMORY SIZE (PL) 6 Gbits

Due to requirements uncertainties and need for on-orbit spare capability a good rule of thumb is
to set the amount of computer memory and THR at 4 times the estimate of what is needed for software
size and throughput. So the estimated values are accordingly margined.

GENOS 48
7 - On Board Data Handling 7.5 - Sizing

Execution Frequency Required Memory Required Throughput

Component # Code Data
(Hz) (KIPS)
(kbits) (kbits)
Application functions
TMTC
Command processing 1 10 16.4 65.5 7
Telemetry processing 1 10 16.4 40.9 3
AOCS
Rate gyro (IMU) 3 10 13 8.2 27
Sun sensor (5 coarse + 1 fine) 6 3 8.2 1.6 18
Magnetometer 1 2 3.3 1.6 1
Kinematic Integration 1 5 32.8 3.3 7.5
Error determination 1 5 16.4 1.6 6
Magnetic torquer control 3 2 16.4 3.3 3
RW control 4 2 16.3 4.9 20
Thruster control 1 5 9.8 6.6 3
GPS 1 10 17.5 2.3 8
Ephemeris propagation 1 1 32.8 4.9 2
Orbit propagation 1 1 213.1 65.5 20
Autonomy functions
Simple auonomy 1 1 32.8 16.4 1
Fault detection
Monitors 1 5 65.5 16.4 15
Fault correction 1 5 32.7 163.8 5
Others
Power management 1 1 19.6 8.2 5
Electrical sensor 80 1 8.2 8.2 160
Temperature sensor 70 1 8.2 8.2 140
Pressure sensor 4 1 4.2 4.2 8
Thermal control 1 0,1 13 24.6 3
SUBTOTAL - AF 596.6 460.2 462.5
Operating system functions
Executive 57.3 32.8 90
Run-time kernel 98.3 65.5 N/A
I/O device handlers 32.8 11.5 50
Built-in test and diagnostic 11.5 6.6 0.5
Math utilities 19.7 3.2 N/A
SUBTOTAL - OSF 219.6 119.6 140.5
TOTAL EST. 816.2 579.8 603
TOTAL (400% MARGINED) 3264.8 2319.2 2412

Table 7.2: Size & throughput requirements refinement

GENOS 49
7 - On Board Data Handling 7.6 - Architecture selection

Figure 7.2: Sensors data rates

7.6 A RCHITECTURE SELECTION

During the design process the s/s drivers lead to the definition of the final architecture. This choice
depends on different trade-offs and is mainly based on mass, power and cost, which shall be reduced as
much as possible. Also the design of the subsystem shall maintain high levels of availability, capability
and reliability which can be in contrast with the previous points. Usually in order to seek low-risk
solutions, complex hardwares and softwares are avoided and in general a favorable OBDH system
design is one which has been proven on another mission and which requires no modification to be
further implemented.
In the following section several types of OBDH system architectures are discussed.

Centralized architecture It uses point to point interfaces that can be used for subsystems and
payload to connect with a single management computer.

PROs

• Works best with few, well-defined subsystems which all interface with the central computer.

• High reliability as failures along one interface do not affect other interfaces.

CONs

• To add a new node requires hardware and software changes in the OBC.

• Wiring harnesses is relevant to ensure duplicate transmissions.

Ring architecture Packets of data containing the same information are passed in a circular pattern
from a single server to multiple components.

GENOS 50
7 - On Board Data Handling 7.6 - Architecture selection

PROs
• Adding new nodes has a limited impact to the central processor.

• Wiring harnesses are small and can be distributed throughout the spacecraft structure.

CONs
• Low reliability due to in-line transmission to next node.

Bus architecture It consists of a common data bus with all subsystems connected to it. This solution
requires the use of well designed standard-protocols and communication schemes for all the nodes.

PROs
• Data transmissions are deterministic raising reliability.

• Wiring harnesses are reduced.

CONs
• All components must be developed with a specific physical and electrical interface.

• Conflicts may arise if many devices need the bus at the same time

Decentralized architecture The aim of this scheme is to provide sufficient computing power and
data storage to the individual subsystems and thus to realize a decentralized data handling function. It
uses remote terminal units (RTU) which interface sensors, actuators and instrumentations to the OBC.

PROs
• Control, monitoring and data processing and management can be dealt locally

• Reduced amount of connection lines between the CPU and the different units

CONs
• Integration of additional units is required which results in increased power demand and cost.

7.6.1 Proposed architecture

After analyzing the different characteristics and peculiarities of these solutions, the most suitable one
to implement for GENOS mission results to be the centralized configuration for the following reasons:
• it works well with few, well-defined subsystems being a highly reliable architecture in case of
standard flight softwares and application functions

• It is beneficial for GENOS microsatellites, which should be configured with standard components
in order to reduce the mission cost in terms of purchasing, verification/validation tests and to
ease the integration procedure

• it represents the principal solution when the connected components do not link to a net of
distributed microprocessors

• it is usually adopted for small class satellites where the number of interfaces is not high since
adding connections would increase wiring harness, hence mass and cost budgets
In figure 7.3 is sketched the centralized architecture with relevant functional blocks.

GENOS 51
7 - On Board Data Handling 7.7 - Redundancy and robustness strategy

Figure 7.3: Architecture scheme for the OBDH subsystem

7.7 R EDUNDANCY AND ROBUSTNESS STRATEGY

In this section the redundancy philosophy adopted to design the OBDH s/s is reported. The throughput
and size requirements are used as inputs to select the components and to choose a good robustness
strategy. One of the most important driver for GENOS mission is to minimize as much as possible the
cost. So, regarding the hardware part, Commercial Off The Shelf (COTS) components are preferred to
be implemented into the system. Also devices with low power consumption are possibly chosen.

The OBDH system is constituted by 2 OBC units. In total there are 2 CPUs in warm redundancy, 3
CSACs in hot redundancy, 2 serial SpW interface links, 2 MMUs in hot redundancy. Every equipment
and sensor in the spacecraft is crosslinked to each unit by means of 2 SpW point-to-point connections
(200 Mbits/s max speed), one main link plus a redundant one. In case of failure of the main OBC, the
second computer is switched on and it can replace all the functionalities of the first one. The bus
selection guarantees a fast exchange of data in compliance with the TMTC s/s requirements.
The OBDH architecture and its redundancy strategy was designed with the objective to be robust to
failures and to keep the satellite responsive in off nominal conditions. Indeed the processing unit is
configured in warm redundancy. That is, only one processor is active but data are stored in both units
and the redundant CPU is always ready to replace the main one. If the main computer is restarted
3 consecutive times for any reason without success, then the system automatically switches to the
secondary unit.
FDIR functionalities are included in the software implementation. Error Detection And Correction
(EDAC) protection embedded in the processor automatically corrects single bit errors in the memory
units and flags double bit errors. Also a watchdog timer is dedicated to monitor the CPU operations
and to reset the OBC when the specified time is expired.
Finally the OBDH is provided with a safeguard memory functionality. This block, implemented in
hot redundancy (1 module for each OBC unit), is constituted by 2 memory banks. One bank is a 512

GENOS 52
7 - On Board Data Handling 7.8 - Components specification

kB volatile memory for dynamic allocation, the other one is a 256 kB non volatile memory for static
context and High Priority Commands (HPCs). The data stored is basically the current configuration
of the s/c, its current mode and phase and the software patches that can be applied in case of failure.
This information is used by the active processor after its boot, either after a processor switch-over or
after a processor reset.
Uncorrectable memory errors in the primary computer or timing issues in a command sequence can
induce the activation of the safe mode. Please refer to chapter ...SAFE MODE.... It is important to note
that some scientific data can be lost in the process, but this procedure is required to guarantee the
satellite security, of course trying to have minimal impact on the mission objectives.

7.8 C OMPONENTS SPECIFICATION

The principal components contained inside the OBC unit are a AT697F Rad-Hard 32 bit SPARC V8
Processor[?], hosted in the central motherboard, a 256 MB SLC NAND flash memories [?] for HK data
storage and a 16 GB MT29F Flash NAND memory [?] for PL data storage. For detailed specifications
check relative data sheets.
Since the design is still at phase A, none of the devices above mentioned are definitive and may
be replaced in the future. Anyway they represent a good option that is compliant with the OBDH
requirements.
In addition to this, to sustain the HW components and connect the s/s with the primary structure a
PEEK support frame and an external case are accounted for in the mass budget. All the electronics is
contained inside a parallelepiped box close to the PCDU. Since for redundancy reasons 2 identical
OBCs were considered in the design, in total 2 chassis are needed to host the computers.

7.9 M ASS AND POWER BUDGET

Finally to compute the mass and power budget, data were gathered from product data sheets when
available. If information was not provided, like for instance the frames and chassis weight, they were
estimated with large margins. For the mass computation 2 units have been considered. These are the
margins adopted: 5% on CPU, clocks and memories mass, 25% on board frame and chassis mass, 20%
on power consumption.

Table 7.3: Components properties

Component Name Quantity Mass [g] Power [W]

CPU board AT697F 2 100 1

CSAC Microsemi 3 35 0.12
Mass memory (HK) 256 MB SLC NAND Flash Memory 2 15 0.03
Mass memory (PL) 16 GB M29B Flash NAND Memory 2 15 0.03
Support structure - 2 500 N/A

Table 7.4: Mass & power budget

Mass [g] Power [W]

TOTAL 1365 1.48
TOTAL (MARGINED) 1633 1.78

GENOS 53
8 Attitude Determination and Control Sub-
system

8.1 D ESIGN PATH

8.1.1 Requirements
ADCS is expected to accomplish the following requirements, coming from other subsystems and by
the mission purposes:

• The Sun shall be pointed with a precision better than 1 degree, to prevent it from detectors FOV
and to enlighten solar panels.

• The antennas shall be pointed towards the ground and Globalstar constellation, for telecommu-
nication.

• The maximum angular velocity allowed is 1.5 deg/s to grant link to Globalstar.

• Thruster shall be pointed in the velocity direction for the whole burning time, which is 3 minutes
at the end of life.

Furthermore, other requirements of the subsystem are:

• Spacecraft shall be stabilized and disturbances counteracted.

• Maneuvers shall be accomplished when necessary.

Finally, the selected devices shall be the cheapest ones (in terms of money, weight and power demand)
which fulfills the requirements.

According to the literature [?], 3 axes stabilization is the unique method which accomplishes
every requirement: gravity gradient, momentum bias, spin, dual spin and passive magnetism are dis-
carded mainly for the low maneuverability and the coarse pointing precision.Since the most expensive
stabilization method is selected, the criterion of having low cost devices is even more stringent.

8.1.2 Actuators
Thrusters are discarded as actuator option for the power and mass demand, despite of the possibility
of integration with propulsion subsystem. Magnetotorquers are selected to accomplish detumbling (in
fact their authority is enough to overcome disturbances), but they are not suitable for maneuvers. Thus,
momentum exchange devices are chosen as main device; in particular, reaction wheels are selected,
because they are cheaper than CMG in terms of cost, mass and power demand, even if they grant
slower maneuvers. Their desaturation is accomplished by the magnetotorquers, since they are lighter,
cheaper and less power demanding than thrusters and they are already selected for detumbling.

GENOS 54
8 - Attitude Determination and Control Subsystem 8.1 - Design path

The equations to size the reaction wheels and the magnetotorquers are taken from the literature
[?]. The disturbances kept into account are: gravity gradient, solar radiation pressure, magnetic torque
and aerodynamic drag.
The results of this preliminary size (for each axis, with the assumption of a cubic spacecraft shape) are:

• Reaction wheel momentum to counteract disturbances: h=4.98e-02 Nms.

• Reaction wheel torque to accomplish slew maneuvers: T=2.30e-04 Nm.

• Magnetotorquer dipole moment to counteract disturbances:T=1.00 Am2 .

• Magnetotorquer dipole moment for desaturation: 2.83 Am2 .

From these outcomes, COTS are selected as baseline, following the criteria of low mass, low power
demand and low budget (Tab. 8.1). Since the dipole moment of the magetotorquer required for
desaturation is more constraining than the one needed for disturbances counteracting, the former
is taken as reference in the selection; furthermore, in order to reduce weight and dimension, the
constrain is relaxed and a device with a dipole moment of 2.00 Am2 is chosen.

8.1.3 Sensors
Since the satellite is expected to fly in LEO, orbit determination can be acquired through GPS receiver,
which is required for the atomic clocks too.
Instead, in order to determine the attitude:

• The selected sensors shall grant a precision one order of magnitude lower than the required
pointing precision, i.e. 0.1 deg (6 arcmin).

• The position of the Sun shall be known time by time, for science and power supply purposes.

To accomplish all the requirements in sunlit, Sun sensor is chosen as the most suitable device, based
on the characteristics reported in the literature [?]: fine Sun sensor is placed on the face nominally
looking at the Sun (number 1) and coarse Sun sensor (passive device) on any other surface. To
completely determine the attitude, Sun sensor is coupled with magnetometer (suitable for the low
altitude orbit and already on-board to work magnetotorquers), composing a TRIAD: the values acquired
by the sensors in body frame (the magnetic field Bb from the magnetometer and the Sun position Sb
from the Sun sensors) and those in the inertial frame (Bn and Sn ) are compared and the attitude matrix
AB /N is acquired:
h Bb ∧ Sb Bb ∧ Sb i
VB = B b BB ∧ (8.1)
|B b ∧ S b | |B b ∧ S b |
h Bn ∧ Sn Bn ∧ Sn i
VN = B n Bn ∧ (8.2)
|B n ∧ S n | |B n ∧ S n |
VB = A B /N VN (8.3)
During the eclipse Sun sensor does not work and a different determination strategy is necessary:
thus, an optimization tool is selected, based on magnetometer and IMU gyros (used to measure
the satellite angular velocities too). From a computational point of view, the attitude matrix AB /N is
obtained by minimizing the cost function J:

J (A B /N ) = |B b − A B /N B n | (8.4)

and by integrating the dynamic equation through the measurement of the gyros (represented by the
skew symmetric matrix [ωB /N ]∧ ):
Ȧ B /N = −[ωB /N ]∧ A B /N (8.5)

GENOS 55
8 - Attitude Determination and Control Subsystem 8.2 - Architecture

Figure 8.1: ADCS architecture

It is important to notice that this latter determination strategy leads to pointing precision divergence,
because of the IMU gyros propagation error. Since the pointing precision is required to prevent the
Sun from the FOV of the detectors, the divergence is not a problem in eclipse; anyway Sunpointing
shall be maintained to minimize the time to reach the required precision as soon as the satellite comes
back in sunlit.

8.2 A RCHITECTURE
In order to guarantee the correct work of the subsystem in case of devices failure, cold redundancy
is enhanced for what regards the sensors (whose number is doubled) while it is hot concerning the
reaction wheels (four in a pyramidal disposition); the magnetotorquers are not redundant. All the
devices are linked to both of the two on-board computers, in order to overcome the failure of one of
them and of the connections.
Tab. 8.1 reports the number of the devices and the selected baseline.

Number Device Company

Reaction wheel 4 RWp050 [?] Blue Canyon Technology
Fine Sun sensor 2 nanoSSOC-A60 [?] SOLARMEMS
Coarse Sun sensor 10 CSS-01,02 [?] SpaceMicro
Magnetometer 2 Space MAG-3 [?] SpaceQuest
Magnetotorquer 3 MT2-1 [?] ZARM Technik
GPS receiver 2 Venus 838FLP [?] SkyTraq
IMU 2 STIM 300 [?] Sensonor

Table 8.1: ADCS number and baseline

8.3 M ODES
The ADCS modes are defined according to the different performances required. To study the behavior
of the attitude during each mode, a Simulink model is implemented, based on the actual inertia
properties of the satellite.
The distinction between sunlit (considered lasting 59 minutes) and eclipse (35 minutes) is done for

GENOS 56
8 - Attitude Determination and Control Subsystem 8.3 - Modes

any mode, because of the different determination algorithm used, with the exception of detumbling:
in fact it needs just the measure of gyros (for the rotation rate) and of magnetometer (to work the
magnetotorquers), which operate both in sunlit and in eclipse.
Tab. 8.2 indicates the working devices for each mode and the related power demand. It is important
to highlight that for science and safe modes the power demands reported are related to the necessity
respectively during desaturation (magnetotorquers powered, as discussed below) and during maneuver
to point solar panels towards the Sun.

Detumbling Maneuvering Science Safe

p p p
Reaction wheel
p p p
Fine Sun sensor
p p p
Coarse Sun sensor
p p p p
Magnetometer
p p p
Megnetotorquer
p p p p
GPS receiver
p p p p
IMU

Power demand [W] 3.33 5.83 5.33 5.83

Table 8.2: ADCS modes

8.3.1 Detumbling mode

The spacecraft angular velocity ωB /N is slowed to zero, by using the following control law:

u i d eal = −k I ωB /N (8.6)

u i d eal ∧ B b
u r eal = ∧ Bb = m ∧ Bb (8.7)
Bb · Bb

Where:

• u i d eal and u r eal are the ideal and real control momentum [Nms].

• k is an arbitrary constant.

• I [kgm2 ] is the inertia matrix related to the configuration with solar panels not yet deployed. Bas-
ing on the configuration (Ch. 11.1), there is just a slight misalignment between the geometrical
and the principal inertial reference frame (0.1 deg), which are both centered in the center of
mass. Thus the principal inertial one is used in the simulation and it is:

2.17 0 0
 

I = 0 4.34 0 
0 0 4.60

• B b is the magnetic field in body frame.

• m is the magnetic dipole provided by the magnetotorquer (it depends on the device selected).

Regarding the very first detumbling, the simulation starts from an initial random angular velocity
(consequence of the injection in orbit) of 10 deg/s, considering the spacecraft dimensions. After 5.14 h
(about 3 orbits and a quarter) the angular velocity values achieved are so small (less than 1.7 e-03 rad/s,

GENOS 57
8 - Attitude Determination and Control Subsystem 8.3 - Modes

Figure 8.2: Angular velocity trend during the detumbling

i.e. 0.1 deg/s) that the spacecraft can be considered still: this time is selected as detumbling duration.
It is quite a long time, but the power demand in this mode is low, as shown in Tab. 8.2.
Fig. 8.2 reports the trend of the angular velocity, while Fig. 8.3a and 8.3b show the magnetic dipole
behavior; it can be noticed that an effort larger than the maximum one is required along the main part
of detumbling.

(a) The magnetic dipole required (b) The magnetic dipole physically provided

Figure 8.3: Magnetic dipole during the detumbling

8.3.2 Maneuvering mode

It is related to the slew motion necessary to point the thrust towards a specific direction, superimposing
the attitude matrix AB /N with the reference one AL/N . It is the most demanding mode (as shown in Tab.
8.2), since all the sensors and actuators are switched on and the reaction wheels work at the power
peak.
The control law is:

u i d eal = −k 1 ωB /L − k 2 A ∧
B /L (8.8)

A ḣ r = −ωB /N ∧ Ah r − u i d eal (8.9)

u r eal = −A ḣ r − ωB /N ∧ Ah r (8.10)

Where:

GENOS 58
8 - Attitude Determination and Control Subsystem 8.3 - Modes

• ωB /L is the relative motion between the body and the reference frame [rad/s]:

ωB /L = ωB /N − A L/N ωL/N (8.11)

• A∧
B /L is the vector representing the difference between the body frame and the reference one; it
comes from the matrix A B /L :

A B /N = A B /L A L/N (8.12)

• h r is the angular momentum of the reaction wheels [Nms].

• A is the reaction wheels matrix, representing the pyramidal disposition of the wheels.
At the beginning, the reference frames were chosen to have two surfaces always looking at the deep
space, in order to grant an easy integration with radiators, if they had been necessary: they would
have set on surfaces 3 and 4, along orbital momentum direction. Even if, at the time being, the design
discards the option of having radiators (??), the reference frame has not been changed: it is compliant
with all ADCS requirements and allows further integration with radiators, if necessary.

8.3.2.1 Sunpointing

Sunpointing is required to align solar panels towards the Sun and to prevent it from the detectors FOV.
As reported in ADCS requirements, in sunlit the precision shall be better than 1 deg, while in eclipse it
can be relaxed.
Sunpoi nt i ng
The goal is to superimpose the attitude matrix AB /N with the AL/N , which is:
x Sun
 
 x Sun ∧ h or b 
x Sun ∧ (x Sun ∧ h or b )
Where:
• x Sun is the direction from the spacecraft to the Sun.

• h or b is the orbit angular momentum.

The strategy to point the Sun by the first time is:
1. Pointing the Sun as soon as satellite is in sunlit; the simulation starts from the final conditions of
the detumbling.

2. Reaching a precision of 1 deg (after 22 minutes) and deploy solar panels (Fig. 8.4a). The inertia
properties change (Ch. 11.1) and the matrix [kgm2 ] used from now on is:

2.68 0 0
 

I = 0 4.76 0 
0 0 5.52

It is related to the principal inertial reference frame, slightly misaligned from the geometrical
one (even lower than 0.1 deg); the center of mass (on which they are both centered) is moved
from the one of the not deployed configuration.

3. Improving precision for the rest of sunlit (Fig. 8.4b).

4. Maintaining pointing in eclipse, during which a divergence up to 3 deg occurs (Fig. 8.4c).

5. Recovering precision better than 1 deg, just after 33 seconds, thus this operation can be per-
formed in any orbit (Fig. 8.4d).

GENOS 59
8 - Attitude Determination and Control Subsystem 8.3 - Modes

(a) In the first sunlit, before solar panels deployment (b) In the first sunlit, after solar panels deployment

(c) In eclipse (d) In the second sunlit

Figure 8.4: Sunpointing precision

(a) In sunlit (b) In eclipse

Figure 8.5: Thrustpointing precision

GENOS 60
8 - Attitude Determination and Control Subsystem 8.3 - Modes

8.3.2.2 Thrustpointing

Thrustpointing is performed any time that an orbital maneuver is required: the thruster (on the surface
number 1) is aligned with the direction of the velocity vector; the versus (towards the velocity or
opposite to it) depends on the type of the maneuver which shall be done. The goal is to superimpose
T hr ust poi nt i ng
the attitude matrix AB /N with the AL/N , which is:
 
±v or b
 ±v or b ∧ h or b 
±v or b ∧ (±v or b ∧ h or b )
Where:

• v or b is the orbital velocity

• h or b is the orbit angular momentum

The simulation for sunlit starts from the science mode conditions (in which Sun is tracked) at the end
of eclipse; vice versa for the simulation in eclipse.
Fig. 8.5a and Fig. 8.5b show that a precision lower than 1 deg is reached, so that losses due to
misalignment can be neglected. It is worth to notice that the convergence in eclipse is faster than
in sunlit, because of the the optimization tool velocity. The precision lower than 1 deg is granted for
enough time (the thrusting lasts 3 minutes at the end of life, i.e. in the worst conditions), even in
eclipse, in which the precision diverges for the propagation of the gyros error.
To sum up, both of sunlit and eclipse conditions are suitable to perform thrusting, enhancing elasticity
in the orbital maneuvering.
The effort required to the reaction wheels is maximum at the beginning (when the peak of the
momentum is needed), than decreases. It is worth to note that the momentum required during the
eclipse is larger than the one provided physically by the wheels (Fig. 8.6b), to grant the very fast
convergence discussed above; this does not happen in sunlit, in which the momentum required is
always lower than the reaction wheels highest performance (Fig. 8.6a).

(a) In sunlit (b) In eclipse

Figure 8.6: Reaction wheels momentum during the thrustpointing

Finally, it is interesting to report the angular velocity trend during the thrustpointing, in Fig.
8.7a and Fig. 8.7b: the components are null, but one. This grants a such angular motion that the
thrustpointing can be maintained while the spacecraft orbits.
In particular, the angular velocity peak in eclipse (up to 1.8 deg/s) (Fig. 8.7b) overcomes the limit
imposed by the requirements (1.5 deg/s), but Globalstar was tested to grant communication up to 12
deg/s; furthermore, the overcoming occurs for few minutes. Thus, the trend is acceptable.

GENOS 61
8 - Attitude Determination and Control Subsystem 8.3 - Modes

(a) In sunlit (b) In eclipse

Figure 8.7: Angular velocity trend during the thrustpointing

8.3.3 Science mode

During science mode the Sun is tracked and all the devices work (Tab. 8.1); in particular, reaction
wheels work at the nominal power to counteract the disturbances (spacecraft kept still) and to recover
the precision required in sunlit, at the end of eclipse.
Since the design gives priority to mass and power demand saving, the reaction wheels are as small as
possible and the saturated conditions are reached in just 7 orbits and half (basing on simulations).
Then, the magnetotorquers are switched on to desaturate the wheels, causing an increase power
demand. The control law is:

u i d eal = −kh r (8.13)

After one orbit and half, momentum components are almost equal to the ones at the end of Sunpointing
and desaturation can be considered accomplished.
This operation is needed quite often, but it is not a problem: in fact the required pointing precision is
never lost during desaturation.

8.3.4 Safe mode

During safe mode, the spacecraft shall be kept pointed towards the Sun, in order to absorb energy and
recharge the batteries, starting from any initial condition: thus, both of detumbling and pointing shall
be guaranteed.

• Detumbling is still performed through magnetotorquers, but its trend is different from the one
of detumbling mode, for the different inertial properties, since solar panels are already deployed
(Fig. 8.8).

• Sunpointing cannot be performed through magnetotorquers, for the too low authority, as
reported in Fig. 8.9a; the use of reaction wheels is mandatory and a precision better than 1
degree is achieved (Fig. 8.9b).

Then, Sunpointing shall be maintained and desaturation shall be accomplished when necessary,
similarly to science mode.
The power required by safe mode is quite high, as reported in 8.1; since ADCS subsystem is crucial for
the mission, it is considered a reasonable demand.

GENOS 62
8 - Attitude Determination and Control Subsystem 8.3 - Modes

Figure 8.8: Detumbling during safe mode

(a) Using magnetotorquers (b) Using reaction wheels

Figure 8.9: Safe mode precision

GENOS 63
9 Electrical power subsystem

9.1 I NTRODUCTION
The electrical power subsystem of GENOS satellite is designed to be reliable and efficient. The main
drivers for the design are: mass, volume and cost. These drivers leads to choose high efficient, TRL 9
and space qualified technologies.

The selected architecture is the classic solar panel plus battery couple. This essentially for the
following reasons:

1. This architecture is the most suited for a LEO satellite.

2. Other technologies for power generation and energy storage are not fully developed for mi-
crosatellites.

3. The Sun pointing makes solar technologies very attractive.

Finally, it needs to be mentioned that the nominal duration of 1 orbit is 94.61 min and the maximum
eclipse duration (used for the sizing) is of 36 min. It is worth to remember that the satellite lifetime is
of 3 years.

9.1.1 Installed power

In Tab. 9.1 is reported the total installed power on GENOS satellite. Each value is margined by the 25%,
except the payload that has a margin of 45%. The values of the margins are chosen according to the
AIAA recommendation [?].

Subsystem Margin [%] Power [W] Percentage [%]

ADCS 25% 6.7 5%
EPS 25% 5.0 4%
Mechanism 25% 4.5 4%
PS 25% 38.3 31%
TCS 25% 10.0 8%
TT&C 25% 20.6 17%
OBDH 25% 1.8 1%
Total bus - 86.9 71%
Payload 45% 36.3 29%
Total - 123.2 100%

Table 9.1: Installed power on GENOS satellite.

GENOS 64
9 - Electrical power subsystem 9.2 - Modes and sub-modes

9.2 M ODES AND SUB - MODES

In Tab. 9.2 are listed the four modes and ten sub-modes for the EPS. Please note that the mode uses
the corresponding sub-modes according to the phases or condition of the platform.
Each mode and sub-mode reports a mean power margined by the 25%. The power demand of the
mode is averaged according to the duration of the relative sub-modes.
Fig. 9.1 presents the values of Tab. 9.2 empathizing the portion of power absorbed by each subsystem.

Note: the way to compute the mean duration is explained for each mode.

9.2.1 Starting mode

The starting mode is the mode utilized to start (or re-start) the satellite. Obviously this mode is used
to switch on the satellite after the release from the launcher. Moreover, it is also used to re-start the
system after passing through the South Atlantic Anomaly. Finally, this mode is characterized by not
using the payload nor the thruster.
The duration are computed from the results of the ADCS, just after the launcher release (see chapter 8.

Detach This sub-mode is used only once just after the detach. It lasts 30 minutes and consists in
transmitting to ground through the patch antennas the telemetry of the satellite.

Detumbling The duration of the detumbling comes from the ADCS subsystem. In this sub-mode the
communication leans always on Leaf Space because the spin rate may be too high for Globalstar.

Slew This sub-mode is dedicated to slew maneuvers. Its duration is estimated using the worst case
for Sun acquisition coming from ADCS. Now Globalstar is used since the rotation rate is decreased.

Stand-by As the name explains, this sub-modes is used when no operation has to be performed. For
example, it can be used to recharge the batteries after a non-nominal discharge or simply to wait on
commands from ground. TT&C uses Globalstar to communicate.
The duration of the stand-by mode is virtually infinite and for this reason it is not considered in the
average staring mode power demand.

9.2.2 Science mode

The science mode is the operative mode where the payload is working. As reported in Tab. 9.2, it is the
most power consuming, therefore it is the design point for the solar panels and batteries.
The duration is computed from the results of mission analysis and TT&C and scaled on one orbital
period.

Science This sub-mode consists in observing the full celestial sphere with the payload and transmit-
ting telemetry and alerts through Globalstar.

Science + telecom The only difference with respect to the previous sub-mode is that now scientific
data has to be downloaded with Leaf Space.

GENOS 65
9 - Electrical power subsystem 9.3 - Solar panels

Figure 9.1: Power breakdown (25% margin) per subsystem for each mode.

9.2.3 Maneuvering mode

The maneuvering mode is used for phasing maneuvers or drag compensation maneuvers. Since the
payload requires a precise pointing for the functioning, in this mode it is turned off. Therefore, the
payload power is deviated to engine. Finally, since no scientific data is supposed to be downloaded,
the communication passes through Globalstar.
The duration of the firing sub-modes considers 2 burns of 5 minutes each, during 1 orbit. The rest of
the orbital period is used for the heat up.

Heat up In this sub-mode 30 W are used to heat up the catalyst bed or to keep it in operative
temperature.

Firing As before, the engine absorbs power, but now the thrust pointing requires a higher effort, i.e.
power, from the ADCS.

9.2.4 Safe mode

The safe mode has been designed to allow the satellite to survive as long as possible and to try to
communicate with Earth. For this reason, all the non essential loads are switched off. Please note that
the sub-modes are activated according to the condition of the satellite while entering the safe mode.
The duration of the safe mode will be explained at the end of the chapter.

Note: detumbling, slew and stand-by sub-modes are described in starting mode.

Telecom ground In this sub-mode, the spacecraft tries to contact the ground by means of the patch
antennas.

9.3 S OLAR PANELS

9.3.1 Solar cell
As it can be easily understand, the need for microsatellites to generate the maximum power from small
solar panels leads to choose high efficiency (but reliable) cells, like triple junctions GaAs [?]. Three cells
with approximately the same efficiency (29.5%) are present on the market:

GENOS 66
9 - Electrical power subsystem 9.3 - Solar panels

Total bus with 25% margin [W]

Modes and sub-modes Mean duration
Sunlit Eclipse
Starting mode 27 36 -
Detach 24 33 8%
Detumbling 28 37 82%
Slew 22 31 8%
Deployment 24 33 3%
Stand-by 19 28 ∞
Science mode 58 69 -
Science 55 64 88%
Science + telecom 70 79 12%
Maneuvering mode 57 66 -
Heat up 57 66 89%
Firing 59 68 11%
Safe mode 27 36 -
Detumbling 28 37 56%
Slew 22 31 6%
Stand-by 19 28 11%
Telecom ground 28 37 28%

Table 9.2: Power breakdown for modes and sub-modes.

1. 3G30A of AZUR SPACE Solar Power GmbH [?]

2. CTJ30 of Cesi SpA [?]

3. XTJ of Spectrolab, Inc. [?]

To estimate the degradation of the cells due to radiation, contacts with Cesi SpA have been kept.
This information can be combined with the equivalent fluence resulting from Spenvis. In particular,
for 1 year on GENOS orbit, the estimated fluence is reported in Fig. 9.2a.
It has been considered 100 µm of coverglass thickness, typical for space applications. With such
a coverglass, the equivalent 1 MeV fluence is of 4.780·1011 (e/cm2 ). As it has been reported by Dr.
Campesato (Cesi’s Head of Solar Cells Lab.), the first degradation datum is appreciable for a fluence
in the order of 5·1013 (e/cm2 ). Therefore, the radiation degradation can be considered negligible for
GENOS mission. A similar result can be deduced from the datasheets of the other companies.

Finally, in order to be conservative, 1% of degradation per year has been taken into account.
This value seems sensible to have a margin on the radiation degradation, but also to consider other
degradation factors, like atomic oxygen and debris impacts.

9.3.2 Solar panels configuration

Usually for microsatellites the solar panels are body mounted or deployed as petals. A body mounted
configuration is preferable for its simplicity, but it needs enough area on the Sun oriented face.
From the beginning of the design, it has been clear that the face pointed toward the Sun would be too
small to accommodate the required solar panel area. For this reason, 2 deployable identical petals
have been preferred. In fact, a mixed configuration (body + petals) is thought to be more expensive

GENOS 67
9 - Electrical power subsystem 9.3 - Solar panels

(a) Equivalent fluence computed with Spenvis for 1 year. (b) Planar view of the payloads FOVs: brown and purple
100 µm coverglass thickness in red. represent the superposition of FOVs.

Figure 9.2: Solar panels

than an uniform configuration.

It is worth to note that the petals have to be mounted in a sensible way, in order to not compromise
the detectors field of view. For this reason, the petals are mounted on the intersection between faces
6-3 and 6-4. Moreover, the petals have to be inclined by 15°, introducing a loss due to the non null Sun
aspect angle (SAA).
For simplicity, Fig. 9.2b shows a 2D view of the satellite. As it can be noted, the panels restrict the green
and the blue field of view, but overall the satellite can see the full circle thanks to the superposition of
the red field of view.

From the available data, the detector should have a FOV larger than 160°. In this situation, depicted
in Fig. 9.2b, the margin angle between the petal and the boundary of the "red" FOV is of 5°. Please
note that the petals have to stay within the superposed FOV areas, i.e. in the brown and purple areas.
If the P/L FOV shrinks, the petal Sun aspect angle increases and consequently the required petal area.

9.3.3 Sizing
The sizing of the solar panels follows the procedure illustrated in Ref. [?, chpt. 11], considering a direct
energy transfer (DET), a degradation coefficient of 1 %/year and an inherent degradation of 0.77.
The required generated power is approximately 135 W that, under the above-mentioned hypotheses,
corresponds to a total array area of ≈ 0.46 m2 .

Number Dimension [mm] SAA [deg] Mass [kg]

2 450 x 510 15 1.00

Table 9.3: Summary of the panel feature. Note, the mass value is not margined.

In Tab. 9.3 are reported the main characteristics of the solar panel. The mass is estimated using
71.43 W/kg of specific power, coming from SPVSTM by Leonardo SpA [?].

GENOS 68
9 - Electrical power subsystem 9.4 - Batteries

9.4 B ATTERIES
Batteries are used to store energy in order to give it back to the system during peak power demands and
eclipses. Many kinds of cell exist, but for microsatellites the state of the art are lithium ions batteries
[?]. In fact, Li-ion cells have high specific energy and energy density, they do not need reconditioning
and they retain their charge for long time. All these features can be translated in saving mass, volume
and cost.

9.4.1 Li-ion cell

To design the batteries, it has been decided to select as reference a Li-ion cell on the market. The cells
of MP 176065 family by Saft are very promising for GENOS mission because they are under space
qualification and have wide operative temperature ranges.
Among the 176065 family, the MP 176065 xtd cell is used for the sizing [?].

9.4.2 Sizing
The procedure illustrated in Ref. [?, chpt. 11] is used also for the battery sizing. The design considers a
battery efficiency of 90% and a depth of discharge (DOD) of 20%.

Please note that the DOD depends on the cell property and on the number of cycles, that for
GENOS mission are approximately 17500 cycles in 3 years. From what reported by Eng. Lagattu
(Saft’s Sr. Quality Engineer), the suggested DOD for the MP 176065 family is 30% for 17500÷30000 cy-
cles. To be conservative and independent from the selected cell, it has been decided to use 20% of DOD.

The required energy for the design point is 231.70 W·h. Since the batteries will be used also for
peak power demands and for non nominal situation a margin of 30% is applied, so the required energy
is approximately 300 W·h.

For reliability reasons, 2 battery packs are designed. To reach the nominal bus voltage of 28 V (as it
will be shown in the next section) and have the correct capacity, each pack needs 8s1p configuration.
The pack performances are reported in Tab. 9.4 and the total energy stored on-board is of 326.4 W·h.

The mass and dimensions of Tab. 9.4 has been computed using the data of the cell, but also the
structure to build the battery as been taken into account. In fact, to all the dimensions 20 mm of
structure have been added and the battery mass has been increased by 10%.
Without any data on the battery assembly these values seem to be reasonable in order to estimate the
dimensions and mass of the battery packs.

Number of packs Cell configuration Dimensions [mm] Mass [kg] Energy [W·h]
2 8s1p 95 x 141 x 89 1.3 163.2

Table 9.4: Battery pack data. Note, the values in this table are not margined.

9.5 B US ARCHITECTURE AND PMDU

Regarding the bus architecture, a direct energy transfer (DET) at 28 V unregulated is used. DET is
chosen for its higher efficiency and the bus voltage is standard on the market.
A power management and distribution unit (PMDU) is chosen on the market as reference device. The

GENOS 69
9 - Electrical power subsystem 9.6 - Off-design

System power (average) 80 W

System power (peak) 120 W
Power consumption 4 W
Primary bus voltage (unregulated) 28 V
Secondary bus voltage (regulated) 5 V
Length 267 mm
Width 167 mm
Height 89 mm
Mass 2.45 kg
Temperature range [-30 +60] °C

Table 9.5: Summary of PS-MS01 datasheet [?].

selected device is the PS-MS01 by ÅAC Mircotec [?]. This PMDU is tailored on the microsatellite class,
its main features are reported in the Tab. 9.5.
With this PMDU, the bus will have 2 lines: the main line is an unregulated line at 28 V, the secondary
line is on the contrary regulated at 5 V for the electronic devices. As it can be noted, the average system
power respects the maxima per each mode.
GENOS has contacted the supplier in order to inquire after the price. Unfortunately, ÅAC Mircotec
is not able to provide a quotation, because the cost largely depends on the device setup.

9.5.1 DC/DC converters

Since some loads need a stable or different voltage, DC/DC converters are needed. At this level of
design only their mass might be estimated. To proceed, information on the main components and their
voltage are collected from the other subsystem. It results that 8 lines needs a voltage down-conversion
and/or stabilization. Applying 20% of margin, 10 DC/DC converters has to be equipped.
To estimate the mass, space qualified DC/DC converters by VPT Inc. are taken as reference [?]. Each
device weight 27 g, therefore the estimated mass for the DC/DC converters is of 0.27 kg (not margined).

9.6 O FF - DESIGN
9.6.1 Numerical model
To validate the design, a numerical model is developed to simulated peak power demands and to check
the correct battery charging on many orbits. The model is implemented in Simulink and it is based on
a power balance:

P solar array ± P battery − P loads − P shunt = 0 (9.1)

The position of the spacecraft is propagated along the orbit and P solar array 6= 0 if the satellite is in
sunlit. Peaks power demands of 1 minute are simulated considering 110% the nominal power demand
every 20 minutes.
The batteries have to provide the lacking power in case of peaks and are recharged if there is an excess
of power. To be more realistic the maximum charging rate is fixed at C/3 (typical of a LEO mission [?]).
Finally, if the batteries are full or the charging rate is already maximum, the power is deviated to the
shunts, so P shunt > 0.

GENOS 70
9 - Electrical power subsystem 9.6 - Off-design

Figure 9.3: Example of battery charging from 250 Wh of capacity. The power demand of the loads are that of the
science mode.

In Fig. 9.3 is reported an example of battery charging starting from a non nominal capacity. In
some orbital revolutions the capacity cycle returns in the nominal range. Please note that the time can
be shortened by switching from science mode to starting stand-by mode, i.e. reducing the requested
power.

9.6.2 Orbit injection phase

A very critical mode may be the starting, because the first time it is activated, i.e. after the launcher
release, solar panels are not deployed nor pointed toward the Sun. Hence, all the power consumption
leans on the batteries.
To analyze this case, the powers from Tab. 9.2 are multiplied by the duration of the starting mode. In
this way, the amount of energy required for the starting mode is computed and it is approximately 190
W·h, that is below the available 326.4 W·h. Therefore, the satellite is able to survive with the batteries
only until the deployment of the solar panels.

9.6.3 Safe mode

Another important mode that has to be analyzed is the safe mode. Under the hypotheses of:

1. Enter the safe mode just after the eclipse.

2. The solar panels do not produce power.

3. The communication is always on.

It is useful to compute the expected duration of the safe mode until the battery death per each
combination of sub-modes. In Fig. 9.4 is reported the expected lifetime.

Please note that relative durations of the sub-modes in Tab. 9.2 are referred to the "complete safe
mode" case, i.e. detumbling, slew, stand-by and telecom ground submodes. Of course, the activated
sub-modes depend on the state of the satellite while entering the safe mode. In the worst case the

GENOS 71
9 - Electrical power subsystem 9.6 - Off-design

Figure 9.4: Expected lifetime of the satellite in safe mode until the battery death.

spacecraft is tumbling, hence the safe mode pass through all the sub-modes (see timeline in Fig.9.4). A
part from stand-by, the sub-modes duration are computed from the output of the ADCS. The stand-by
duration is arbitrary set at 1 hours before switch to telecom ground.

Finally, the most interesting result is that expected lifetime (with only the batteries) is approximately
more than 9 hours, while the maximum time between two consecutive ground station is about 1 hour.

GENOS 72
10 Thermal control subsystem

10.1 R EQUIREMENTS AND D RIVERS

10.1.1 Requirements
The TCS shall provide the thermal environment (temperature ranges, gradients, and stability) required
to ensure full performance during each mission phase and mode as well as for the complete duration
of the mission.
The thermal control design shall be compatible with the in-orbit environment expected for all nominal
variations of the solar aspect angle, Earth albedo and infrared radiation.
Worst-case hot and cold conditions have been preliminarily identified and analyzed. Using the
outputs of the other subsystems, the required units operating and non-operating temperature limits
are presented in Tab.[10.1].

10.1.2 Drivers
The drivers fot the thermal control subsystem are:

• Passive hardware preferred;

• Low cost hardware;

• High TRL hardware;

• EPS direct energy tansfer needs to dissipate the excesses of the energy production via Shunt
resistors disspation.

10.2 M ODEL , ASSUMPTIONS AND PRELIMINARY DESIGN

At this stage of the design, a preliminary sizing was performed. The main goal was to asses whether it
was possible to satisfy the TCS requirements by using mostly passive hardware such as painting and
coatings, limiting the active hardware to few heaters straps.
For the preliminary design hot and cold cases conditions have been assessed for the LEO orbit of
GENOS satellites and are reported in Tab.[10.2]

10.2.1 Model and assumptions

To asses the preliminary design a 9 nodes model has been developed Fig.[10.1] with the following
assumptions:

• The nodes are coupled only through radiation, thus assuming perfect insulation between the
nodes;

GENOS 73
10 - Thermal control subsystem 10.2 - Model, assumptions and preliminary design

Tmin operative[°C] Tmax operative[°C] Tmin safe[°C] Tmax safe[°C]

ADCS
Reaction wheels - - - -
Magnetotorquers - - - -
Magnetometers -55 85 - -
Fine Sunsensors -30 85 - -
IMU - - - -
Coarse Sunsensors -40 83 - -
GPS -40 85 - -
PROPULSION
Tank 2 60 - -
Feedline 2 60 - -
Thruster 2 90 -20 90
Pressure Sensors -20 70 -40 75
Temperature sensors -60 160 - -
Pyro valve -90 100 - -
Fill and drain valves -30 80 - -
TMTC
Transceiver -20 50 -40 65
Patch antenna -30 50 - -
EyestarD2 -40 60 -60 100
Globalstar antenna -50 85 -60 100
EPS
Batteries 0 60 -30 85
Solar cells -100 100 - -
PMDU -30 60 - -
OBDH
Memories -40 85 - -
Processors -55 125 - -
P/L
INAF detector -20 -10 -30 50

Table 10.1: Temperature limits

Worst Hot Worst Cold Units

Sun heat flux Gs 1414 1309 W/m2
Earth albedo factor a 0.4 0.2
Earth IR heat flux qI R 261 189 W/m2

Table 10.2: Worst hot and cold case environmental values [?]

GENOS 74
10 - Thermal control subsystem 10.2 - Model, assumptions and preliminary design

• The components associated with the respective node are assumed to be isothermal with the
node, thus assuming perfect conduction between them;

• The internal view factors are assumed to be equal to the one of the case of a cubic box inside a
cubic box as reported in [?];

• The view factors for the Earth albedo and Earth IR emission are assumed to be equal to those
reported in the STK user guide [?];

• The shunt resistors are placed on the back of the solar panels (i.e. node 1 and 2 in Fig.[10.1]);

• The node temperature range is equal to the most stringent temperature range among the units
associated with the node.

Figure 10.1: 9 nodes model

GENOS 75
10 - Thermal control subsystem 10.3 - Results

The masses of each node have been computed according to the structure and configuration out-
puts, as reported in Tab.[10.3].

Node # Mass [kg] Units included in the node

1 1.1 Solar panel
2 1.1 Solar panel
3 4.8 Thruster, adapter, structural panel
4 6.7 Solar panel mechanism, PDMU, detector, structural panel
5 4 Computer, detector, structural panel
6 5.5 Solar panel mechanism, Battery, detector, structural panel
7 4 Computer, detector, structural panel
8 6.3 Battery, detector, structural panel
9 34.6 Tank, cables and all the remaining units

Table 10.3: Masses computed according to structure and configuration output

In order to choose the values of the optical properties of the surfaces, a sensitivity analysis has
been computed in order to keep all the nodes in the respective temperature boundaries. Comparing
the results of such analysis with the optical properties values reported in the AZ technology datasheet
[?] and in the NASA paintings and coatings database [?] possible choice of the optical properties, able
to keep all the nodes in the respective temperature ranges, is reported in Tab.[10.4].

Node # α ² αback/inside ²back/inside T_min [°C] T_max [°C]

1 0,8 0,82 0,15 0,9 -100 100
2 0,8 0,82 0,15 0,9 -100 100
3 0,25 0,33 - 0,15 2 50
4 0,15 0,21 - 0,64 -20 -10
5 0,15 0,21 - 0,64 -20 -10
6 0,15 0,21 - 0,64 -20 -10
7 0,15 0,21 - 0,64 -20 -10
8 0,15 0,33 - 0,64 -20 -10
9 - - - 0,54 2 45

Table 10.4: Optical properties computed using sensitivity analysis

10.3 R ESULTS
Following the procedure reported in [?] results of the preliminary analysis are shown in Fig.[10.2] for
the worst hot case and in Fig.[10.3] for the worst cold case. As it can be seen for both cases the nodes
temperature oscillations stays within the respective boundaries.

10.4 C ONCLUSIONS
In conclusion, it has been decided to preliminary investigate the conduction effects that might be
present on GENOS satellite. Using OpenFOAM a model with the same geometry and mass subdivision

GENOS 76
10 - Thermal control subsystem 10.4 - Conclusions

Figure 10.2: Worst hot case

Figure 10.3: Worst cold case

GENOS 77
10 - Thermal control subsystem 10.5 - Future developments

of the multi node model has been developed. To set the comparison between the two model, the
multi node model was fixed in time with no power generation nor electrical power dissipation until
equilibrium was reached. Then the OpenFOAM simulation started close to the equilibrium values
showed by the multi node model until equilibrium was reached. In Fig.[10.4] it is reported the trend of
the mean of the nodes temperature computed in OpenFOAM and in Fig.[10.5] the rendering of the
OpenFOAM results.

Figure 10.4: Comparison between OpenFOAM and MatLab results

As it can be seen from the graph, it is clear that the trend presents a big divergence with respect to
the multi-node model except for the electronic box. Please note that this is still a preliminary analysis
with the main goal to highlight the problematic that might arise from the conduction, thus for the
future of the design it is important to better asses such problems, considering the restricted detector
temperature range.
To conclude, it must be stressed out that the multi-node model is a good qualitative model and it
shows us that the GENOS satellite thermal control problem can be assessed by means of paintings
and coatings but the quantitative results needs better refinement, considering the detector limited
temperature range and looking forward to the phase B of the design.

10.5 F UTURE DEVELOPMENTS

The future developments involve:

• Refinement of the multi node model using the results from finite volumes analysis;

• Use the refined model to check the thermal behaviour of GENOS satellite for all nominal varia-
tions of the solar aspect angle;

GENOS 78
10 - Thermal control subsystem 10.5 - Future developments

Figure 10.5: OpenFOAM results

• Use the refined model to check the thermal behaviour of GENOS satellite for all the nominal
attitude positions between sunpointing and thrust pointing as well as testing the behaviour in
case of loss of attitude.

• Use the refined model to check the thermal behaviour of GENOS satellite during the firing of the
thruster;

• Detailing of the TCS at unit level;

• Drawing a test plan.

GENOS 79
11 Configuration

11.1 D RIVERS AND MOST IMPORTANT REQUIREMENTS

The first driver is the volume available in the launcher envelope. As mentioned in ch.4, the baseline for
the launch is SSMS with Vega, which has an allowed volume of 1100 x 700 x 600 mm 3 . The proposed
configuration shall also be adapted to the chosen back-up solution, a rideshare on VESPA with VEGA
or Soyuz, which has an available volume of 1050 x 800 x 680 mm 3 . GENOS shall fit in both of those
spaces.
Other important drivers for the configuration design are the payload requirements, in terms of
field of view and position. More precisely, the five detectors shall be each on a different face, excluding
the one pointing the Sun. As for the field of view, no object shall reduce it. For this reason, a study
has been conducted about the inclination of the solar panels: they are inclined of 15° with respect to
the normal of the face in order to respect the field of view of the antenna, while avoiding to lower the
performance of the solar panels.
Each component has its own requirements, but the more meaningful are here listed:

• Detector field of view and position: while not very stringent, this requirement has been given
priority over the others.

• Sun pointing: it gives the position of the solar panels and some thermal constraints.

• Antennas position: given the importance of the communication requirement for GENOS, this
requirement has also been given priority.

• Thruster alignment with the center of mass: this requirement, along with the necessity to put
the thruster in the general vicinity of the tank, constraints its position.

• Tank position: for structural reasons, it is required to place the tank as close as possible to the
adapter.

• Electronics position: some electronics require a specific placement (near the center of mass) or
have specific needs (interference-free close environment).

• Cables reduction

• Accessibility

11.2 D ESIGN PROCESS

11.2.1 Definition
The general shape of the spacecraft is a parallelepiped. Thus, the different faces have been numbered,
as it is explained in Fig. 11.1.

GENOS 80
11 - Configuration 11.2 - Design process

Figure 11.1: Definition of the different faces and reference system for the configuration subsystem

11.2.2 General design flow

The design has been made using the software Catia©. Satisfying the requirements of every components
have already defined in details the solution. Criticalities have been dealt with: they are presented in
the next paragraphs.
An important idea that has to be underlined is the will to divide evenly the masses between the
different faces, except for face 6, which is the farthest away from the adapter, and must be as light as
possible.
Very early in the design, it was thought to divide the satellite in two parts, one for the propulsion
components and one for the electrical components. This decision has been made based on usual
configuration design for satellites. Another upside of this design choice is the addition of a middle
plate, in accordance with the structure subsystem (see ch.12). This middle plate shall not receive too
much weight either.
An other idea has been to try and have components that can be produced in series. For example, it
has been decided to make the solar panels identical.

11.2.3 Criticalities
Thruster on adapter face It has been decided to put the thruster on the face number 1, the sunlit
face. This choice has been made because it best answered the different requirements. However, two
problems have arisen following this choice.
The first one is the temperature of the thruster. Being in the Sun all the time (except during eclipse),
it reaches important values. However, this is not a problem for the correct functioning of the propulsion
system.
The second one, that has more impact on the configuration subsystem, is the fact that the nozzle
length (outside the spacecraft) is bigger than the adapter ring. In other words, a collision has been
observed between the thruster and the launcher. To solve this problem, a spacer is added between
the adapter ring and the microsatellite face. This spacer is a ring, whose exterior diameter is the
largest exterior diameter between the SSMS adapter ring and the VESPA adapter ring, while the interior
diameter is equal to the minimum interior diameter between the SSMS adapter ring and the VESPA
adapter ring. As for the height of the spacer, it is equal to the length of the thruster outside the
spacecraft.

GENOS 81
11 - Configuration 11.3 - Presentation of the design

Figure 11.2: View of the deployed satellite

Accessibility This requirement is clashing with the low volume allocation that comes with a mi-
crosatellite. In fact, the chosen accessibility strategy is to have some faces that can be opened. To make
sure this can be done, some margins are necessary between the components and the structure parts.
This margins increase the overall volume.
However, even though the density has been increased because of this issue, the overall volume of
the satellite fits inside the minimum volume chosen and defined in the first paragraph of this section.

Interferences of electronics The last criticality to be dealt with is the requirement for some devices
to avoid the interferences in the proximity of other electronics. To fulfill this requirement, it has been
decided to put those specific devices in the propulsion part of the spacecraft. This isolates them from
the other electronic devices thanks to the middle plate.

11.3 P RESENTATION OF THE DESIGN

The following images give an overview of the final configuration design. The dimensions of the stowed
configuration are: 883 x 484 x 504mm, which fits in the available volume for both SSMS and VESPA,
with some space left (Fig. 11.5).
As it can be seen in Fig. 11.2, two wing solar panels of equal dimensions are used. The Sun, directed
towards face 1, with the adapter, spacer and thruster, also illuminates the solar panels. The faces 2 and
5 are used by the Globalstar and patch antennas.
In Fig. 11.3, the 6 faces are shown, in a stowed configuration and in an exploded view. This allows
to show the position of 3 of the detectors, 6 coarse Sun sensors (the rest of the detectors and of the
sensors are hidden by the solar panels), the 2 fine Sun Sensors and the antennas.
Fig. 11.4 provides a view of the inside of the satellite. The two parts (electronic and propulsion) are
visible. The different magnetic devices (reaction wheels, magnetotorquers, magnetometers) are all
present in the propulsion part.

GENOS 82
11 - Configuration 11.3 - Presentation of the design

Figure 11.3: View of the different faces

Figure 11.4: View of the satellite without faces 2, 3 , 4, 5 and without antennas and solar panels for more visibility

GENOS 83
11 - Configuration 11.3 - Presentation of the design

Figure 11.5: Stowed configuration

Figure 11.6: View of the spacecraft while being assembled and tested

The accessibility issue has been solved using the solution presented in Fig. 11.6.

GENOS 84
12 Structural subsystem

12.1 R EQUIREMENTS AND DESIGN DRIVERS

To find launches opportunity is critical for GENOS mission, therefore the structure is designed to meet
requirements for both SSMS dispenser and Arianespace auxiliary passengers. The most stringent
requirements for the microsatellite class are reported in Tab. 12.1, considering the worst situation
possible from the user manuals [?] and [?].
The main design driver is mass saving.

Requirement Reference value

Lateral frequencies > 60 Hz
Longitudinal frequencies > 90 Hz

Table 12.1: Design requirements from the launcher

12.2 L IST OF STRUCTURAL COMPONENTS

GENOS structure comprises sandwich panels, ribs, stringers and a trussed support for the tank. With
reference to Fig. 12.1, the items composing the structure are:

• Lower panel P1. The ID is coherent with the FRAME.

• Upper panel P6. The ID is coherent with the FRAME.

• Middle panel P7. The ID is coherent with the FRAME.

• Lateral panels P2, P3, P4, P5. The ID is coherent with the FRAME.

• Stringers S1 along the x dimension of the lateral panels according to FRAME (4 items).

• Stringers S2, forming a cross on each lateral panel (8 items).

• Stringers S3, on the edges of lower, middle and upper panels (12 items).

• Lower panel ribs R1 (8 items).

• Upper panel ribs R2 (2 items).

GENOS 85
12 - Structural subsystem 12.3 - Baseline design and mass budget

Figure 12.1: GENOS structural items

12.3 B ASELINE DESIGN AND MASS BUDGET

The panels and beams data are reported respectively in Tab. 12.2 and in Tab. 12.3, with reference to Fig.
12.2 and 12.1. The materials properties can be found in [?] and [?].
The ribs R1, R2 and the stringers S2 and S3 have a rectangular section, with one dimension equal
to the thickness of the core in which they are mounted. The stringers S1 have an L section because
of their position at the corners. The trusses of the tank support have an hollow circular section, to
maximize the inertia and keep the mass contained.
The choice of the materials is made keeping in mind mass saving and electrical compatibility of
the structure.

Face ID t cor e [mm] t ski n [mm] M at er i al cor e M at er i al ski n Mass [k g ]

P1 20 3 Al honeycomb Al 7075-T73 3.55
P2 10 1 Al honeycomb Al 7075-T73 2.05
P3 10 1 Al honeycomb Al 7075-T73 2.20
P4 10 1 Al honeycomb Al 7075-T73 2.20
P5 10 1 Al honeycomb Al 7075-T73 2.05
P6 30 3 Al honeycomb Al 7075-T73 3.74
P7 10 1 Al honeycomb Al 7075-T73 1.25

Table 12.2: Panels characteristics

12.4 M ECHANISMS
In order to deploy solar panels, mechanisms are needed. A simple deployment mechanism is pre-
ferred and the panels are kept in position once deployed, therefore a root hinge, spring-driven and
non-reversible deployment mechanism is considered. Please note that the solar array mass is of only

GENOS 86
12 - Structural subsystem 12.4 - Mechanisms

Beams ID S1 S2 S3 R1 R2 TS
Items 4 8 12 8 2 12
Section L rectangle rectangle rectangle rectangle hollow circle
t 1 [mm] 3 - - - - -
t 2 [mm] 3 - - - - -
H [mm] 10 10 10 20 30 -
W [mm] 10 3 2 5 5 -
R 1 [mm] - - - - - 3.5
R 2 [mm] - - - - - 3
Material Al7075-T73 Al7075-T73 Al7075-T73 Al7075-T73 Al7075-T73 Al7075-T73
Tot. mass [kg] 0.20 0.29 0.32 0.37 0.43 0.11

Table 12.3: Reinforcements and tank support characteristics

Figure 12.2: Beams sections

1.7 kg and deployment mechanisms for such small panels aren’t currently available on the market.

For a preliminary mechanism sizing, one solar array is modeled as a hinged rigid bar on which a
rotational spring and damper torque are acting. The deployment profiles in Fig. 12.4a and Fig. 12.4b
are designed to respect the following requirements:

• Deployment angle of 105 deg, as required from configuration in Ch. 11.1.

• Deployment time of the order of 30 s, as typical.

• Slow rotation rate, less than 20 deg/s, to avoid shocks.

The desired profiles are obtained with a pre-load of 120 deg and tuning the rotational spring and the
damping one, with a result of 2 Nm/rad for the former and 60 Nms/rad for the latter. The torque
provided by the mechanism ranges between 4 and 0.1 Nm, as shown in 12.4c.

The most similar technology available on the market is produced by RUAG Space. The 1.5 kg
mechanism in Fig. 12.3a is spring-driven and non reversible, with a high deployment accuracy and
stiffness. It is fitted with the 285 g damper in Fig. 12.3b to reduce the position latching shock. The
provided torque is in the range of 4-10 Nm and the damping constant can vary between 1200 and 200
Nms/rad, [?] [?].

The mass m of GENOS mechanism is linearly scaled with the computed torque T and damping c,
as follows:

GENOS 87
12 - Structural subsystem 12.4 - Mechanisms

(a) Mechanism (b) Damper

Figure 12.3: Ruag Space deployment mechanism and damper

T c
m = m RM + m RD (12.1)
TRM c RD

where m R M is RUAG mechanism mass, m RD is RUAG damper mass, TRM is RUAG torque and c RD
RUAG damping. The maximum value of the torque range and the minimum for the damping are
considered, as they are believed to be the most relevant data for the sizing. The mass of one mechanism
comprising also the damper is estimated to be 1.02 kg, with a 50% margin.

The technology TRL is assumed to be 5, since studies and tests in non-relevant environment
have been done in the past years [?]. Small mechanisms with an higher TRL exist: the TRL of Maeva
mechanism is equal to 8, but this device is not suited for GENOS mission as it can not provide the
needed deployment angle [?]. GENOS team might want to take care of the technology development in
the future phases of the project. This technology is believed to be critical for the mission also because
of the high number of failures that usually affect the deployment devices [?].

(a) Deployment angle profile (b) Deployment velocity profile (c) Mechanism torque profile

Figure 12.4: Solar arrays deployment profiles

GENOS 88
12 - Structural subsystem 12.5 - FEM model

12.5 FEM MODEL

A FEM model has been implemented using Patran as pre-processor and post-processor and Nastran as
solver software.

The mesh is a paver mesh of triangular elements with an aspect ratio always lower than 3.25. The
FEM comprises 2919 elements and 1484 nodes. The choice of this mesh size is mainly due to the
limitations of the software license, but for future studies a convergence analysis is suggested.

All the non-structural masses are considered in the worst possible case, accounting for subsystem,
system and launch margins, as in ??. The components ranging between 7 and 1 kg constitute the 90%
of non-structural mass and have been modeled as lumped masses. They are here listed:

• Tank, PMDU, payloads, batteries and computers are connected to the structure with RBE3 MPCs,
considering their center of mass position and dimensions as an input from configuration.

• The solar panels in the stowed configuration are linked to the mechanisms via RBE2 MPCs.

• Thruster and mechanisms are lumped masses directly attached to the structure.

• The feed line mass is equally split between tank and thruster, being the feed line a flexible item.

Please note that all the lumped masses are of the same order of magnitude of the largest one, i.e.
the wet tank. All the other components, comprising also cables and paints, have been modeled as
uniformly distributed on the related panels.

12.6 M ODAL ANALYSIS

To grant a sufficient separation from the launcher frequencies is the main challenge for GENOS struc-
tural design.

The thickness of the lower and upper panels has been increased for stiffening reasons.
The elements that are fundamental for increasing the natural frequencies are:

• The ribs of the lower panel. During the design it has been observed that the first axial mode is
related to the deformation of the lower panel, that has the adapter displacement constraint.

• The ribs of the upper panel, that carries considerable masses.

• The reinforcements of the lateral panels, in correspondence of the electronic bay.

Also the tank support plays an important role in stiffening the whole structure and contributes to raise
the lateral frequency.
On the other hand, the vertical stringers and the horizontal rods on the edges of the lower, middle
and upper panel are not so relevant. They have been introduced at the beginning of the design, but
changing their section no significant changes are observed: the panels stiffness is what plays the main
role. Anyway, such reinforcements find a reason of existence during the assembly and integration
phase.
The results of the modal analysis are a first lateral frequency of 95 Hz and a first axial frequency of
about 130 Hz, as shown in Fig. 12.5.
The payload survival to launch is a critical aspect to be accounted for. Future design developments
shall check the local modes to which the payloads are subjected: the vibrations shall not damage the
instrument crystals.

GENOS 89
12 - Structural subsystem 12.7 - Static and buckling analysis

(a) First lateral mode (b) First axial mode

Figure 12.5: Modal analysis results

12.7 S TATIC AND BUCKLING ANALYSIS

The requirement for the structure is to be enough strong to avoid stresses near to the material yield,
that is 380 MPa from ??.

12.7.1 Loads definition

The typical transportation loads detailed in [?] are lower than the launch loads, therefore only the latter
are considered to verify the structural strength.

As indicated in the launcher manuals [?] and [?], the factor of safety for static and sine loads is equal
to 1.25 (in compliance with ECSS typical margins [?]) and equal to 2.25 for random loads. Acoustic
loads are covered by random loads ([?], [?]). Shock loads are not considered in the present analysis, as
typically done [?].

Random loads are computed starting from the modal analysis results. In particular, the first 144
modes are considered, as in this way the 90% of the effective modal mass is reached for each translation
direction. The load factors are derived from the PSD, exploiting Miles equation. Then the RMS of the
load factors weighted with the modal participation fraction is computed, as in [?].

The static, sine and random load factors are combined together, according to the procedure in
[?]. To define the load cases, all the possible sign combinations are considered. The selection of the
worst loading condition is not trivial, being the structure not symmetric. Therefore, 48 load cases are
implemented: 24 for the SSMS dispenser and 24 for the ASAP/VESPA solution.

12.7.2 Static analysis results

The result of the static analysis is that the strength requirements are satisfied by the design with large
margins, as the maximum Von Mises stress is of 29,6 MPa. It corresponds to the loading condition in
Tab. 12.4 and is located in the adapter panel, as shown in Fig. 12.6.

GENOS 90
12 - Structural subsystem 12.7 - Static and buckling analysis

Direction X Direction Y Direction Z

-63 -9 -13

Table 12.4: Worst load case [g]

Figure 12.6: Lower panel Von Mises stress

12.7.3 Buckling analysis results

The same load cases defined for the static analysis are used for the buckling one, as the FOS are the
same [?]. The lowest margin of safety for buckling is 2.94, therefore no local instabilities are present.

For future design developments, it should be noted that the tank support is the most critical
element from the bucking point of view, even if its design has been driven by stiffness reasons. The
effect of thermal loads on the trussed structure should also be checked in further analyses.

GENOS 91
13 Modes

13.1 P HASES
The section analyses the phases of the mission starting from the separation, with a description of the
operations and the related subsystems modes. More details are reported along the whole report.

1. Separation: the satellite is detached from the adapter and initialized; the sequence is the
following:

(a) Power unit is switched on using batteries.

(b) Satellite power lines alimented.
(c) On board computer initialized.
(d) Telecommunication subsystem switched on.
(e) Telecommunication subsystem initialized.
(f) GPS receiver switched on.

The subsytems are in the following modes:

• EPS: starting mode.

• TMTC: patch mode.
• OBDH: starting mode.
• PROP: launch mode.

2. Aquisition: the satellite starts communicating with ground.

(a) Test signal sent from ground to the satellite through patch antennas.
(b) Test signal sent from satellite to ground through patch antennas.
(c) Test signal received and analyzed in terms of power and noise.
(d) Satellite location acquired through GPS receiver.
(e) Satellite location sent on ground through patch antennas.
(f) Satellite telemetry sent on ground through patch antennas.
(g) Telemetry is analyzed.
(h) Satellite Globalstar modem initialized.
(i) Satellite to Globalstar test communication initialized.
(j) Satellite to Globalstar test communication analyzed.
(k) Satellite sends telemetry through Globalstar.
(l) Telemetry is compared with the one sent by the patch antennas.

GENOS 92
13 - Modes 13.1 - Phases

The subsytems are in the following modes:

• EPS: starting mode.

• TMTC: patch mode.
• OBDH: starting mode.
• PROP: launch mode.

3. Detumble: the tumbling of the satellite is stopped (up to a threshold of 0.1 deg/s).

(a) Command for detumbling initialization sent from ground and received through patch
antennas.
(b) Magnetometer, magnetotorquers and IMU activated.
(c) Telemetry check sent on ground through patch antennas.
(d) Command for detumbling control law actuation sent from ground and received through
patch antennas.
(e) Command receipt of detumble control law actuation sent to ground.
(f) Satellite detumbling.
(g) Telemetry and attitude sent to ground at every ground station passage through patch
antennas.
(h) Satellite reaches rotation of 0.1 deg/s.
(i) Message of completed detumble sent on ground through patch antennas.
(j) Telemetry and location sent on ground through patch antennas.
(k) Telemetry and location sent on ground through Globalstar.

The subsytems are in the following modes:

• EPS: starting mode.

• TMTC: patch mode.
• OBDH: starting mode.
• PROP: launch mode.
• ADCS: detumbling mode.

4. Commissioning: the satellite points the Sun, deploys solar panels, checks the subsystems and
reports to ground. The sequence is the following:

(a) Sun-pointing:
• Telemetry and location acquired and sent through Globalstar.
• Command for Sunpointing control law actuation sent from ground and received
through patch Globalstar.
• Command receipt of Sunpointing control law actuation sent through Globalstar.
• Satellite points the Sun with a precision of 1 deg.
• Solar panels are deployed.
• Telemetry sent down to confirm that solar panels are deployed.
• Pointing precision improves up to 0.1 deg.
• Attitude sent through Globalstar and checked if the satellite actually points the Sun.
• Telemetry and location sent through Globalstar.

GENOS 93
13 - Modes 13.1 - Phases

• Solar panels start recharging batteries.

• Telemetry sent to ground to confirm that batteries are recharging.
(b) Functionality check:
• All subsytems and payload interrogated by on board computer.
• Telemetry sent through Globalstar.
(c) Automatic clock calibration.

The subsytems are in the following modes:

• EPS: starting mode.

• TMTC: Globalstar mode.
• OBDH: starting mode.
• PROP: launch mode.
• ADCS: maneuvering mode.

5. Phasing: maneuvers to achieve the aimed orbital shape; the sequence is the following:

(a) Thruster warm up, alignment and firing.

• Telemetry and location sent through Globalstar.
• Command to enter maneuvering mode to all subsystems (but TMTC) sent through
Globalstar.
• Command receipt through Globalstar.
• Confirm that subsystems have entered maneuvering mode sent through Globalstar.
• Command to start propulsion submode warm-up to heat the catalyst bed sent through
Globalstar.
• Command receipt sent through Globalstar.
• Confirm heating has started sent through Globalstar.
• Catalytic bed warms up.
• Telemetry, attitude and location sent through Globalstar.
• Command to perform thruster alignment sent through Globalstar from the ground.
• Command receipt through Globalstar.
• Satellite thruster aligns.
• Telemetry, attitude and location sent through Globalstar.
• Command to ignite thruster sent through Globalstar.
• Command receipt.
• Confirmation of firing started sent through Globalstar.
• Firing ends.
• Telemetry, attitude and location sent through Globalstar.
• Command to propulsion subsystem to enter submodes cool-down.
• Command receipt.
• Command to exit maneuvering mode.
• Command receipt.
(b) Support orbit travel.
• Repeat Sun pointing sequence 4a but with solar panels already deployed.
• Telemetry, attitude and location sent through Globalstar continuously.

GENOS 94
13 - Modes 13.1 - Phases

(c) Nominal position injection.

• Telemetry, attitude and location sent through Globalstar.
• Repeat firing sequence 5a.
• Telemetry, attitude and location sent through Globalstar.
• Repeat Sun pointing sequence 4a but with solar panels already deployed.
• Telemetry, attitude and location sent through Globalstar.

The subsytems are in the following modes:

• EPS: maneuvering mode.

• TMTC: Globalstar mode.
• OBDH: maneuvering mode.
• PROP: maneuvering mode.
• ADCS: maneuvering mode.

6. Payload activation and calibration the payload is calibrated in orbit during the first year and
status is checked.

• Telemetry, attitude and location sent through Globalstar.

• Command to power the payload control board sent through Globalstar.
• Command receipt and confirmation of command execution.
• Command to interrogate payload control board.
• Command receipt and confirmation of command execution.
• Payload control board interrogated on status.
• Payload status sent through Globalstar.
• Payload calibration.

The subsytems are in the following modes:

• EPS: starting mode.

• TMTC: patch mode, Globalstar mode.
• OBDH: starting mode.
• PROP: dormant mode.
• ADCS: science mode.

7. Science observation: the satellite waits for GRB and it is ready to record data to be sent on
ground.

(a) Command all subsystems to enter science mode.

(b) Command receipt and confirmation of execution.
(c) Waiting time.
• Telemetry, attitude and location sent through Globalstar continuously.
(d) GRB detected:
• Detectors are triggered by GRBs.
• Energy levels go above thresholds.

GENOS 95
13 - Modes 13.1 - Phases

• Time is noted and written in a string, in parallel message to start sampling location
and attitude is sent to on board computer.
• Payload board starts recording.
• Location and attitude sampled.
(e) Alert string download:
• Time string, location and attitude sent through Globalstar.
(f) P/L data acquisition and processesing (data volume from 3 p/l).
• Payload recorded data is sent down at each passage through patch antennas.
(g) Payload death.
• If life status warning message is received the payload is declared dead and satellite left
to decay.

The subsytems are in the following modes:

• EPS: science mode.

• TMTC: patch mode, Globastar mode.
• OBDH: science mode.
• PROP: dormant mode.
• ADCS: science mode.

8. Decay The satellite goes down to 150 km altitude.

(a) Telemetry, attitude and location sent through Globalstar continuously.

(b) Monitoring till 150 km altitude.
(c) Ground informed through Globalstar that satellite has reached 150 km altitude.

The subsytems are in the following modes:

• EPS: safe mode.

• TMTC: Globalstar mode.
• OBDH: safe mode.
• PROP: dormant mode.
• ADCS: maneuvering mode.

9. Passivation:

(a) Ground operation center starts passivation procedure and communicates it through Glob-
alstar.
(b) Satellite thruster is pointed, fired and pressurizing gas is vented.
• Repeat firing sequence 5a.
• Command to vent the pressurizing gas sent through Globalstar.
• Command receipt and confirmation of execution.

The subsytems are in the following modes:

• EPS: safe mode.

• TMTC: Globalstar mode.

GENOS 96
13 - Modes 13.1 - Phases

• OBDH: safe mode.

• PROP: dormant mode.
• ADCS: maneuvering mode.

10. End of life:

(a) Command to discharge the batteries sent through Globalstar.

(b) Command receipt and confirmation of execution.
(c) Satellite keeps sending location through Globalstar.
(d) No more messages from the satellite are received.

The subsytems are in the following modes:

• EPS: safe mode.

• TMTC: Globalstar mode.
• OBDH: safe mode.
• PROP: dormant mode.

Nominal asset It is worth to detail more the work of the subsystems during the science mode.

• ADCS Sunpointing is performed, with a precision between 1 and 3 deg in eclipse (35 minutes)
and better than 1 deg in sunlit (59 minutes), achieved just after 33 s in Sun side. Any 7 orbits (10
hours), desaturation is needed, but the required pointing precision is never lost.

• TMTC The satellite communicates the telemetry through Globalstar constellation. When a GRB
event is detected, the alert is sent in less than 1 minute using Globalstar and, as a Leaf Space
ground station is in visibility, the scientific data is downloaded through patch antennas.

• EPS During the sunlit the solar panels supply the power to the satellite and recharge the batteries,
which are used in eclipse.

• OBDH The OBDH manages commands to other subsystems, housekeeping and mission data
for download or storage, provides FDIR and time keeping functions.

GENOS 97
14 Mass Budget

The Tab.14.1 reports the mass budget for one GENOS satellite while the Fig.14.1 reports the percentage
of the launch mass allocated for each subsystem, please note that in this figure the propellant and
pressurizer mass is included in the propulsion slice.

Subsystem Mass w/o Margin Margin Total

Margin [kg] % [kg] Mass [kg]
Payload 5 20 1 6
Structure 18.75 5 0.94 19.69
Thermal Control 0.32 5 0.02 0.34
Communication 0.57 5 0.03 0.60
OBDH 1.35 19.58 0.26 1.61
Propulsion 2.56 7.22 0.19 2.75
EPS 7.33 6.38 0.47 7.80
ADCS 1.98 5 0.10 2.08
Mechanism 1.37 50 0.69 2.06
Harness 3.22 10 0.32 3.54
Dry Mass (excluding adapter) 42.45 8.62 4 46.46
Dry Mass with margin (excluding adapter) 20 5.35 51.81
Propellant & Pressurizer 4.407
Adapter (including separation mechanism) 2.27
Wet Mass (excluding adapter) 56.21
Launch Mass (including adapter) 58.48
Launch Mass with margin 20 7.76 66.24

Table 14.1: Mass breakdown update

The margins have been set in the following way:

• at subsystem level, the margin have been evaluated through the margins for each components
according to their TRL. In the Fig.14.2 are reported the margins for each components and the
resulting overall margins for the subsystems.

GENOS 98
14 - Mass Budget

• at dry system level a 20% mass margin has been considered.

• at launch level a 20% margin has been set.

The propellant and oxidizer mass reported in Tab.14.1 are already margined as described in Ch.5.
The adapter have been considered given by the launch suppliers. The margin for the structural
components reported in Fig.14.2 are set as 5 because their design have been done considering al‘l the
other subsystems margined until the launch mass, so with twice the 20% margin as stated in Ch.12 The
margins at subsystem level have generally been set according to the maturity level of the subsystem’s
components as follows1 :

• 5% for the components that are fully developed.

• 10% for the components that need to be modified.

• 20% for the components that need to be developed.

• 25% for the components that are just sized by the team at the time being.

Figure 14.1: Mass Budget

The estimated mass at launch is 66 kg, which means 330 kg for launcher’s payload if five satellites
are considered. The total mass is compliant with the microsatellite requirement mainly due to the
usage of low mass and high TRL components, which demand low margin.
The criticalities in terms of TRL come just from the mechanism that has low TRL due to the scaling
process that it is undergoing while for all the other components the options available show a TRL
above 7 in all cases.

1 It should be reminded that the selection of the component throughout this report is made just to show that the options

on the market allow viable solutions for the mission.

GENOS 99
14 - Mass Budget

FUNCTIONAL SUBSYSTEM # Mass [kg] per unit Total Mass [kg] Margin [%] Margin [kg] Mass [kg] with Margin
Payload 5 20 1 6
Detector 5 1 5 20 1 6
’ ADCS 1.978 5 0.099 2.077
Reaction Wheel 4 0.24 0.96 5 0.048 1.008
Fine Sun Sensor 2 0.004 0.007 5 0.001 0.008
Coarse Sun Sensor 10 0.010 0.100 5 0.005 0.105
Magnetometer 2 0.100 0.2 5 0.010 0.210
Magnetic Torquer 3 0.200 0.600 5 0.030 0.630
GPS 2 0.0003 0.0006 5 0.00003 0.001
IMU 2 0.055 0.110 5 0.006 0.116
Communication 0.574 5 0.029 0.603
Patch Antenna 2 0.049 0.098 5 0.005 0.103
Globalstar Antenna 2 0.143 0.286 5 0.014 0.300
Transciever 1 0.190 0.190 5 0.010 0.200
Propulsion 2.564 7.22 0.185 2.750
20N Thruster 1 0.65 0.65 5 0.033 0.683
Tank 1 1.300 1.300 5 0.065 1.365
Feeding Lines - 0.284 0.284 25 0.071 0.356
Pyrotechnical Valve 1 0.150 0.150 5 0.0008 0.158
Fill & Drain Valve 2 0.090 0.180 5 0.009 0.189
OBDH 1.346 19.58 0.264 1.610
Processor 2 0.100 0.200 5 0.010 0.210
HK Memory 2 0.015 0.030 5 0.002 0.032
P/L Memory 2 0.015 0.03 5 0.002 0.032
Board Frame & Chassis 2 0.491 0.981 25 0.245 1.226
Atomic Clock 3 0.035 0.105 5 0.005 0.110
EPS 7.332 6.38 0.468 7.800
Battery Pack 2 1.296 2.592 5 1.296 2.722
PMDU 1 2.450 2.450 5 0.123 2.573
Wing Solar Array 2 1.010 2.020 10 0.202 2.222
DC/DC converter 10 0.0270 0.270 5 0.014 0.284
Structure 18.75 5 0.94 19.69
Panel 1 1 3.550 3.550 5 0.178 3.728
Panel 2 1 2.050 2.050 5 0.103 2.153
Panel 3 1 2.200 2.200 5 0.110 2.310
Panel 4 1 2.200 2.200 5 0.110 2.310
Panel 5 1 2.050 2.050 5 0.103 2.153
Panel 6 1 3.744 3.744 5 0.187 3.931
Panel 7 1 1.250 1.250 5 0.063 1.313
Stringer 1 4 0.051 0.203 5 0.010 0.213
Stringer 2 8 0.037 0.292 5 0.015 0.307
Stringer 3 12 0.026 0.317 5 0.016 0.333
Tank Support 12 0.009 0.109 5 0.005 0.114
Rib 1 8 0.046 0.365 5 0.018 0.383
Rib 2 2 0.214 0.428 5 0.021 0.449
Thermal Control 0.32 5 0.02 0.34
TE thermocouples 40 0.001 0.046 5 0.002 0.048
Az Technology Paint 1 0.276 0.276 5 0.014 0.289
Mechanism 1.37 50 0.69 2.06
Solar Array Mechanism 2 0.686 1.371 50 0.686 2.057
System 3.22 3.22 10 0.322 3.54
Harness - 3.215 3.215 10 0.322 3.537
Total 42.45 8.62 4 46.46

Table 14.2: List of equipment

GENOS 100
15 Programmatics / AIV

This chapter presents the program for the AIV activities and the schedule of the GENOS mission. The
main requirements and drivers coming from the customer are those regarding the launch date, that
should be before 2020 and the lifetime of the mission that should be of 5 to 8 years.

The mission is programmed so that in the first three years the three orbital planes of the constellation
are filled with five satellites each and in the three years coming after they will be replaced with new
satellites. This choice is made considering that the payload lifetime in the mission environment can
be of maximum three years, after this the payload degrade so much that it is not possible to perform
the activities.

The satellites to be produced are identical: this allows the qualification with only the first model. The
only case in which this is not true is if in the technology verification on orbit (check below) some
criticalities are found and will require the recurring spacecraft to be modified.

The satellites shall be built, as far as possible, in parallel in order to be able to launch five satellite at
every launch date.

15.1 M ODEL P HILOSOPHY

A Protoflight approach is proposed as baseline approach for the GENOS project. This is considered
feasible because a simple design from thermal and structural point of view and large use of qualified
hardware have been selected, so no critical technology is employed in the design. The approach will
be based on four model philosophy:

• Structural Thermal Model (STM) For structural and thermal qualification of the satellite main
structural design the built of a STM which is representative of the flight HW (including interfaces)
is required. Most of the equipment will be represented by structural dummies however the
equipment that are at TRL 6 or below before phase C will be represented by QM(Qualified Model)
or EQM(Engineering Qualified Model).

• Avionic Model (AVM) It will ensure the verification and testing of the avionics architecture
and software in support of the PFM. It will be a build as a test bench with BB(Breadboard) or
EM(Engineering Model) units, representative cables, connector and harness. For the payloads
an Interface Simulator can be used.

• Protoflight Model (PFM) The PFM will complete the satellite qualification and acceptance
campaign at system level and it will be flown as first unit.

• Flight Model (FM) The recurring and following satellites will be FM if no or minor modification
(like delta qualification) have been carried out, otherwise they will be PFM. The FM will be built
to full flight standards and will be subjected to acceptance test.

GENOS 101
15 - Programmatics / AIV 15.2 - AIV Plan

It should be noted that the payloads are supposed to be delivered fully qualified by the customer at the
moment of the verification level. Also EQM are used at equipment level for pre-qualification tests only
in few cases in which significant design modifications would occur (e.g. solar array drive mechanism).

15.2 AIV P LAN

The Tab.15.1 reports the test matrix for the models analyzed above.

The tests occurring on the STM and AVM are mainly for qualification and verification of the structural
and avionic of the satellite, while the test performed on the FM are just for acceptance. The test
occurring on the PFM are both of qualification and acceptance.

Test Description STM AVM PFM FM

Handling/Integration X X
Mechanical Interface X X X
Mass Property X X X
Electrical Performance X X X
Functional Test X X X
Deployment Test X X
Telecommunication Link X X X
Alignment X X X
Static Load X
Shock/Separation X
Sine Vibration X X X
Model Survey
Acoustic Noise X X X
Outgassing X X
Thermal balance X X
Thermal vacuum X X
Grounding / Bonding X X
EMC Test X X X
RF Test

Table 15.1: Test Matrix

15.3 S CHEDULE
The schedule of the GENOS mission is set to have started on the 26/02/2018 with a first launch calcu-
lated to occur on the 25/08/2021.

The deployment strategy for the satellites takes into account the minimal number of satellites needed
for the localization of the GRB and the estimated lifetime of the payload of three years. The deployment
is organized in two sections of three launch, each of which occur once a year. The first three launches
will set respectively five satellite in one of the three planes, while the latter three will replace the firsts
after three year (that is the estimated time after which the payload will degrade). Since two filled planes
are needed to make the constellation operative with the technical requirements set by the customer,
the operative time of the mission is of a total of 6 years.

GENOS 102
15 - Programmatics / AIV 15.3 - Schedule

The size of the satellite gives the opportunity to modify the statistical evaluations on satellite typical
planning to a reduced schedule illustrated in Fig.15.1 and detailed below:

• Phase A duration (that includes the Pre-Phase A) is reduced from 12 to 6 months and Phase B1
duration from 9 to 6 months due to the already relatively detailed concept. The two phases will
end respectively with the delivery of the Preliminary Requirement Review (PRR) and the System
Requirement Review (SRR).

• The statistical duration of 9 months for the Phase B2 is retained and it ends with the delivery of
the Preliminary Design Review (PDR).

• The duration of Phase C is of 12 months while the validation and qualification period lasts 9
months. This choice is justified by the high TRL of the components used on board and from the
already relative detailed design.

• Phase D is set to last 65 months with a division in six stages in which five satellites are produced
per time. This choice is based on the simple design and small size of the spacecraft and in the
possibility to produce in parallel five spacecraft during a period of circa 12 months. The recurring
work for the production of the spacecrafts allows to reduce the time assigned for the production
of the spacecrafts after the first one.

• Phase E is also divided in six stages coherently with the production’ stages. The first launch
is set to be just after the production of the first five satellites. After a period of three months
for commissioning the first five satellite can’t perform the localization by themselves so until
the satellites on the second plane have completed their commissioning phase, a technology
verification on orbit will occur. Each launch will occur with a frequency of one for year.

• Following the division of the Phase E also the Phase F is set in six stages. Each stage is represen-
tative of the disposal of five spacecraft on one of the constellation plane. The disposal of a single
spacecraft lasts three months.

The production of the satellite, in particular those replacing the firsts, ends before the before the date
set for their launch so they require to be stored in the waiting time, this fact allows the possibility of
having a not planned launch in the waiting time: in fact the mission is designed to be considerably
flexible with respect to the time at which the spacecrafts are launched but with the constriction of
having two filled orbital plane to achieve the mission requirements.
Moreover since the production time of the satellites is considerably low and since having more satellites
in orbit enhances the localization’s performances, the more launches possible the more the mission
objectives will benefit.
The possible backup launches will be evaluated by the team as they arise, however they would require
to deploy the satellites in a certain range of orbits as described before

It should be noted that the schedule of the mission considers the critical path represented in red in
Fig.15.1: for the phases before the operations that are critical for the success of the schedule, a margin
of time has been applied in order to consider possible delays.

GENOS 103
15 - Programmatics / AIV 15.3 - Schedule

Figure 15.1: GENOS Schedule

GENOS 104
16 Risk Assessment

In this chapter the risk management policy is established and an overview of the main risks and their
influence on the mission are described.

16.1 GENOS RISK MANAGEMENT POLICY

The risk management policy for the mission aims at handling risks which may cause serious impact on
the project and at preparing the project risk management plan. The success criteria defined by the
team are reported and the severity and likelihood categorizations with respect to them are established,
together with the action to be taken according to index of each risk.

16.1.1 Success Criteria

The success criteria are reported in Tab.16.1 with respect to the science, technical, schedule, and cost
objectives.

Domain Success criteria

S1. The mission increases the number of GRBs detected by the science community.
Science S2. The mission contributes to the study of gravitational waves.
T1. The constellation operates successfully over the designated mission lifetime of 5 to 8 years.
Technical T2. The 90% of the detected GRBs shall be localized with an accuracy of 1 arcmin.
T3. The 90% of GRB alerts shall be communicated in less than 20 minutes.
T4. European Space Debris mitigation requirements shall be fulfilled.
P1. The first launch shall be before the end of 2021.
Schedule P2. The TRLÊ5 at phase B for GENOS satellite
P3. GENOS constellation shall be operative within 1 and half year from the first launch.
Cost C1. Costs of the GENOS mission shall be contained.

Table 16.1: GENOS mission success criteria

16.1.2 Severity and Likelihood Categorizations

The risk scenarios are classified according to their domains of impact on success criteria. The con-
sequential severity level of the risks scenarios is defined according to the worst case potential effect
with respect to science objectives, technical performance objectives, schedule objectives and/or cost
objectives[?]. The risks that may jeopardise and/or compromise the GENOS mission will be ranked in
terms of likelihood of occurrence and severity of consequence. The scoring scheme with respect to the
severity on a scale of 1 to 5 is established in Fig.16.2, and the likelihood of occurrence is normalised on
a scale of A to E in Fig.16.1.

GENOS 105
16 - Risk Assessment 16.1 - GENOS risk management policy

Figure 16.1: Likelihood Categorization

Figure 16.2: Severity Categorization

GENOS 106
16 - Risk Assessment 16.2 - Risk Drivers

16.1.3 Risk index and acceptance policy

The Fig.16.3 reports the risk matrix that helps to decide when to act against risks. The risk index is
defined as the product between the severity and likelihood value.

The risks that will need to be mitigated are those that have a value higher than those of the green
zone; in particular risks with risk index:

• Very High / High will be categorized as unacceptable risks. The main path to follow in dealing
with this kind of risks is the change of the baseline.

• Medium are still not acceptable risks but will not require in all cases a change in the baseline, in
some cases in fact they could be aggressively mitigated.

• Low / Very Low will be categorized as acceptable risks. The main precaution to follow is the
constant monitor and control.

Figure 16.3: Risk Matrix

16.2 R ISK D RIVERS

The risks drivers that have been considered in the identification of specific risks items are reported
below:

• New technology.

• Environmental conditions.

• Reliability issues, single point failures (SPFs).

• Major mission events.

GENOS 107
16 - Risk Assessment 16.3 - Top Risk Log

16.3 T OP R ISK L OG
da aggiustare la tabella
# RI Class Risk Name Cause Mitigation
1 4D Technical Radiation degradation 1. Electronic devices don’t resist 1. Qualification and test for electronic system.
environment
2. Poor information on payload
2 5B Technical Propellant leakage 1. Connections not tightly sealed 1. Water loading test
3 5A Technical Propellant tank explosion 1. Overpressure 1. Safety factor
4 2A Technical Delay in communication 1. Ground station failure 1. Use only the other stations
2. Use a backup ground station
5 4A Technical No communication 1. Ground network failure 1.Use a backup ground station
6 1C Technical Possible communication loss 1. Globalstar antenna failure 1. Redundant antenna
7 4B Technical No communication 1. Globalstar service failure 1. Use Iridium as backup
8 4B Technical No communication with two patch 1. Failure of the transceiver 1. Redundant transceiver
2. Failure of the patch 2.Redundant patch
9 2C Technical Delay in communication and longer transmission time 1. Failure of one patch 1. Redundant antenna
2. Failure in ADCS 2. Use flight proven components
10 4B Technical No communication 1. Failure in EPS 1. Use flight proven components
11 2A Technical Damage of transceiver 1. Overheating of transceiver 1. TCS action
12 4D Technical No communication due to lack of data 1. Failure in OBDH 1. Use flight proven components
13 1C Technical No communication with globalstar 1. Spinning rate higher than 1/4rpm Use antenna capable of transmitting
in spinning condition
14 4B Technical Required pointing precision not fulfilled 1. Sensor failure Redundancy
15 2B Technical Control authority reduction 1. RW failure Redundancy
16 3A Technical Desaturation failure 1. MT failure none
17 4A Technical Tumbling spacecraft 1. RW and MT failure RWs redundancy
18 5A Technical Spacecraft loss 1. CPU failure redundancy
19 Technical Data corruption 1. SEE affecting memories or processor FDIR functions
20 2B Technical Debris impact 1. Collision with a space debris Collision avoidance maneuvre
2. Redundancy number of satellite
in the constellation
21 2C Technical Solar arrays deployment 1. Missed deployment of the solar arrays 1. tests on ground
because of failure of the mechanism 2. Robust constellation in terms of localization
22 1A Technical Electrical discharge 1. Differential accumulation of electrons Tests on ground
on the surface of the external structure
with payload or instrumentation damage
23 Science Earth background 1. Payloads with Earth in their fov 1. Secondary obective: study of lightening
can’t work properly because of photon
scattering and background noise
24 Science Payload damage 1. High energy particles of the SAA 1. Exploit the annealing technique
2. Galactic cosmic rays
25 4B Technical Propellant freezing 1. Failure of the heaters strap 1. Redundancy
2. Failure of the heaters control
3. Failure of tank temperature sensors
26 4A Technical Surfaces optical values changes 1. Impact damage 1. Protective layers on top of the paintings
2. Proton flux above the allowed limt
3. Aging
27 5C Schedule Solar arrays mechanism low TRL 1. Design problems during the 1. To be directly involved in the development
development phase
2. Delays during the development
3. Stop of the developmeny
28 5D Technical CSAC not updated 1. Geomagnetic storm 1. Update clock from ground
(only in case of GPS closed)
2. Clock failure
3. GPS receiver failure
4. GPS service closed for GENOS
29 5C Technical Uplink/Downlink problems 1. Geomagnetic storm
30 2E Technical Position determination problems 1. Geomagnetic storm 1. Propagate the satellites dynamics on-ground
2. GPS receiver failure 2. Tracking (only in case of GPS closed)
3. GPS service closed for GENOS

Table 16.2: Risk Log

GENOS 108
17 Costs

This chapter presents the cost estimate of the GENOS mission. The main driver is to design GENOS
mission as a low cost mission.

17.1 C OST E STIMATE M ETHODOLOGY

The cost analysis is carried on two levels:

• A parametric approach is used due to lack of data during the earliest stages of the design.

• Consequentially to the choice of possible equipment for the satellite, the ground and launch
services, a bottom up approach is started, with some limitations on the unavailable informations.

The approaches are combined in order to obtain a cost as accurate as possible: all the data that are
available at the time of the study are considered in the cost budget, while for the unavailable ones the
parametric approach is used to predict the values. The parametric cost analysis is based mainly on
cost relationships (CERs) that are built on historical data and trends. The ones used for this analysis
are based on Earth-orbiting Small Satellite Cost Models[?].

17.2 C OST A NALYSIS

17.2.1 Space Segment Costs
The space segment costs are reported in Tab. and they include the costs for the spacecraft bus and
payload, cost for the flight software1 , costs for the assembly, integration, verification and test (AIVT) at
subsystem, system and launch level and the costs at program level that are composed mainly of the so
called wrap components[?](that are the costs associated with labor-intensive activities where a level of
manpower is allocated over some period of performance).

The payload cost has been given by the customer while the others are predicted through the use of
the parametric approach for several reasons: lack of data on the components’ cost, some components
have not yet been selected yet, lack of data on program level and AIVT activities.

The costs are reported in terms of RDTE (Research Development Test and Evaluation) and theo-
retical first unit costs. Since many entries of the space segment costs are recurring more than once,
learning curves have been used to determine the recurring costs: a learning curve slope of 95% has
been used for less than 10 units, of 90% between 10 and 50 units and 85% for over 50 units.

The cost of the flight software is determined through the lines of codes associated with it[?], that
have been evaluated to be 17KLOC(thousand lines of code).
1 Only the On-Board software is considered

GENOS 109
17 - Costs 17.2 - Cost Analysis

Cost Component RTD&E Cost [M€] First Unit Cost [M€] Total Cost [M€] Number of units Cost for all units [M€]
Spacecraft Bus 3.379 2.543 5.922 30 46.444
Structure 0.959 0.411 1.370 \ \
Thermal 0.149 0.149 0.298 \ \
EPS 0.609 0.373 0.982 \ \
Communications 0.324 0.132 0.457 \ \
OBDH 0.506 0.207 0.712 \ \
ADCS 0.625 1.064 1.688 \ \
Propulsion 0.207 0.207 0.415 \ \
Payload 0.4 0.25 0.65 150 8.967
Integration Assembly and Test \ 1.035 1.035 30 17.533
Program Level 0.853 0.853 1.705 30 15.300
Program Management 0.171 0.256 0.426 \ \
System Engineering 0.341 0.171 0.512 \ \
Product Assurance 0.171 0.256 0.426 \ \
System Evaluation 0.171 0.171 0.341 \ \
Ground Support Equipment 0.492 \ 0.492 \ 0.492
On-Board Software \ \ 3.698 1 3.698
Total 93.210

Table 17.1: Space Segment Costs

Fig.17.1reports how the space segment costs are divided in, while Fig.17.2 reports how the space-
craft costs are divided within the subsystems.

Figure 17.1: Division of Space Segment Costs Figure 17.2: Division of Subsystem Costs

17.2.2 Launch Segment Costs

The launch segment costs during the early stage of the design where determined by the density costs
of Vega launcher. With the help of Arianespace Group the costs where updated to their actual value:
the density cost of the Vega launcher is of 0.043 M€/kg and it included the launch and the operations
during launch and early orbit. Tab.17.2 reports the total cost of the launch segment, it should be
remember that the total number of launches is six and the weight of the payload for the launcher is
that of five satellites so 331 kg.

Cost Component RTD&E Cost [M€] First Unit Cost [M€] Total Cost [M€] Number of units Cost for all units [M€]
Launch Segment \ 14.34 14.34 6 86.09

Table 17.2: Launch Segment Cost

GENOS 110
17 - Costs 17.2 - Cost Analysis

17.2.3 Operations Costs

The operations costs are composed of those referred to the communications and of those for the
personnel, that is composed of 10 people for which 170K€/year/person are allocated. The years of
operations are set as eight.

The communication costs are those related to:

• Globalstar - for which the plan Flight Plan F1[?] has been selected. The plan comprises a cost
of 185$/month/device so almost 158.7€/month/satellite, because on each spacecraft only one
device is on during nominal operations.

• LeafSpace - the cost of which is determined thanks to Leaf Space company[?]. The cost of the
communication for one passage of a satellite over the ground station is of 20€ and for each
spacecraft the team have determined that three passages are required to download all the
informations about the GRB. Since the average number of GRB detected by one satellite is 20,
the cost allocated for LeafSpace communication is of 1200€/month/satellite.

Fig.17.3 shows the costs for the communications for the years of operations, the trend is due to the
number of satellite on orbit in each year. Tab.17.3 reports the cost for the eight years of operations.

Figure 17.3: Communication Costs

Cost Component RTD&E Cost [M€] First Unit Cost [M€] Total Cost [M€] Number of units Cost for all units [M€]
Operation Costs \ \ 14.78 \ 14.78
Globalstar \ \ 0.14 \ 0.14
LeafSpace \ \ 1.08 \ 1.08
Personnel \ \ 13.55 \ 13.55

Table 17.3: Operations Segment Cost

GENOS 111
17 - Costs 17.2 - Cost Analysis

17.2.4 Results and Conclusion

Tab.17.4 reports the cost budget for the Life-Cycle of the mission.

Cost Component Cost [M€]

Space Segment Cost 93.21
Launch Segment Cost 86.06
Operations Cost for 8 years 14.78
Total Cost for Life Cycle 194.05
Total Cost for Life Cycle with 15% margin 223.16

Table 17.4: Cost Budget for Life Cycle

The total cost of the mission is of 220M€ with a 15% margin considered. This margin has been set
according to the fact that the operations and launch segment costs have been determined with the
help of the companies involved while the space segment is still determined via a parametric analysis.

The criticality of this analysis are on the space segment costs: in fact even though the CERs give
a qualitative value of the costs, they are not always representative of the real ones. To overcome this
limitation, a bottom-up analysis should be started soon in order to evaluate the costs of the space
segment costs.

The Tab.17.5 reports the real costs that are actually available for some of the spacecraft bus’
components . These costs are related to the components selected as reference for the baseline design
so they can be used as reference for the cost of the component with the same TRL2 .

Cost Component # TRL Single Unit Cost [€] Total Cost [€]
Sun Sensor 2 9 SP 2200 4400
Coarse Sun Sensor 10 9 SP 10000 100000
Magnetometer 2 9 SP 12500 25000
Magnetic Torquer 3 9 SP 10000 30000
GPS device 2 9 SP 40 80
IMU 2 9 6800 13600
Patch Antenna 2 9 1200 2400
Globalstar Antenna 2 9 6000 12000
Transceiver 1 9 SP 10000 10000
Atomic Clock 3 9 SP 7000 21000

Table 17.5: Available Costs for some Components of the Spacecraft Bus

2 SP = Space Qualified

GENOS 112